2026-07-02 進階設定 預計閱讀 9 分鐘

Clash 自訂規則怎麼寫:比對類型、語法格式與優先級詳解

從 DOMAIN-SUFFIX、IP-CIDR 到 GEOSITE,逐類講解規則的書寫格式與適用場景,並說明規則自上而下逐條比對的優先級邏輯,以及自訂規則該插在訂閱規則之前或之後。

SEC-01

規則的基本結構與書寫位置

Clash 與 mihomo 核心的分流能力全部建立在設定檔的 rules 欄位之上。一條規則本質是一行文字,格式統一為「比對類型,比對內容,目標策略」三段式,以英文逗號分隔。以下是最常見的規則範例:

rules:
  - DOMAIN-SUFFIX,google.com,PROXY
  - DOMAIN-SUFFIX,cn,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

第一段是比對類型,決定用什麼維度判斷流量;第二段是具體比對值,例如網域後綴或 IP 段;第三段是命中後交給哪個策略群組或策略處理,常見取值有 DIRECT(直連)、PROXY(走某個策略群組)、REJECT(攔截)。部分比對類型還支援第四個可選參數,例如 IP-CIDR 後面的 no-resolve 表示跳過 DNS 解析、直接依目標 IP 判斷,常用來避免不必要的網域解析請求。

規則欄位整體位於設定檔末端,通常緊接在 proxy-groups 之後。自訂規則與訂閱拉取下來的規則會合併成同一份清單,合併後的順序直接決定分流結果,第三節將詳細說明。

SEC-02

常用比對類型逐一說明

網域類比對

DOMAIN 精準比對完整網域,只對完全相同的網域生效,例如 DOMAIN,api.example.com,PROXY 只攔截這一個子網域,不影響 www.example.com。

DOMAIN-SUFFIX 比對網域後綴,是最常用的一類。DOMAIN-SUFFIX,google.com,PROXY 會同時命中 google.com、www.google.com、mail.google.com 等所有以該後綴結尾的網域,適合以整個站點劃分策略。

DOMAIN-KEYWORD 比對網域中包含的關鍵字,不要求位置,寫法是 DOMAIN-KEYWORD,youtube,PROXY。這種比對範圍較寬,容易誤傷無關網域,建議只在關鍵字足夠獨特時使用。

DOMAIN-REGEX 支援以正規表達式比對網域,適合處理有規律但無法用後綴或關鍵字覆蓋的網域集合,書寫與偵錯成本較高,一般設定裡出現頻率不高。

IP 與網段類比對

IP-CIDR 依 IPv4 網段比對,格式為 IP-CIDR,起始位址/遮罩位數,策略,常用於放行區域網路位址段,例如 IP-CIDR,10.0.0.0/8,DIRECT,no-resolve。IP-CIDR6 是對應的 IPv6 版本,寫法結構一致。

GEOIP 依目標 IP 所屬國家或地區判斷,核心內建了 IP 地理資料庫,寫法是 GEOIP,CN,DIRECT,表示只要連線目標 IP 屬於中國大陸就直連,不必逐條列出網段,維護成本遠低於手寫 IP-CIDR 清單。

地理與規則集類比對

GEOSITE 是 mihomo 核心對 v2ray 規則集生態的相容支援,依網域所屬分類判斷,例如 GEOSITE,cn,DIRECT 一條規則即可覆蓋成百上千個中國大陸常用網域,是目前維護成本最低的網域分流方式之一。使用前需確認設定檔裡已宣告對應的 rule-providers,否則核心會在啟動時報錯找不到規則集。

RULE-SET 引用自訂或訂閱方提供的規則集檔案,格式為 RULE-SET,集合名稱,策略,規則集本身是一份包含大量 DOMAIN-SUFFIX/IP-CIDR 等條目的獨立檔案,透過 rule-providers 欄位宣告來源位址與更新週期,好處是規則內容可以獨立於主設定檔更新,不需要每次都重新編輯規則清單。

行程與埠號類比對

PROCESS-NAME 依發起連線的本機行程名稱比對,適合為某個特定用戶端單獨指定出口,例如只讓某個下載工具走直連。DST-PORT 依目標埠號比對,常用於將常見的郵件、遊戲埠號單獨摘出來處理。這兩類規則依賴平台層行程識別能力,在部分行動端或沙盒環境下可能失效,建議先在桌面端驗證生效後再依賴。

兜底比對

MATCH 是通配規則,不帶比對值,必須放在規則清單最後一行,表示前面所有規則都未命中時的預設去向。絕大多數設定會把 MATCH 的目標設為某個策略群組而非直接寫死單一節點,方便隨時在用戶端介面切換出口而不用改設定檔。

NOTE

規則類型對大小寫的敏感度不高,但社群慣例統一使用大寫書寫,建議保持這個習慣,便於團隊協作與後續檢索。

SEC-03

優先級邏輯:自上而下,命中即止

Clash 與 mihomo 核心處理規則清單時,遵循嚴格的順序比對原則:從 rules 清單第一行開始逐條比對目前連線,一旦某一行比對成功,立即採用該行指定的策略,並停止繼續往下比對。後面即便還有更精確或更合適的規則,也不會再被檢查。這意味著規則的先後順序本身就是優先級,而不是看比對類型誰更「精確」。

舉一個容易踩坑的例子:

rules:
  - DOMAIN-KEYWORD,google,DIRECT
  - DOMAIN-SUFFIX,google.com,PROXY
  - MATCH,PROXY

這份設定裡,第一行的關鍵字比對會先命中所有包含 google 字串的網域並直連,導致第二行本該走代理的 DOMAIN-SUFFIX,google.com,PROXY 永遠得不到執行機會——因為連線在到達第二行之前已經被第一行攔下並處理完畢。規則順序寫反,效果就會與預期完全相反,而用戶端介面通常不會對這類邏輯衝突給出提示,需要使用者自行核對。

基於這個機制,書寫規則時建議遵循從精確到寬泛的排列原則:先放 DOMAIN、DOMAIN-SUFFIX 這類精確比對,再放 DOMAIN-KEYWORD、GEOSITE、GEOIP 這類範圍較寬的比對,最後以 MATCH 兜底。範圍寬的規則一旦放在前面,會提前「截獲」本該交給後面精確規則處理的流量。

SEC-04

自訂規則該插在訂閱規則之前還是之後

大多數使用者的設定檔並非從零手寫,而是訂閱節點提供方生成的完整設定,其中已經包含一份規則清單。此時新增自訂規則,插入位置直接決定它是否真的生效。

結論是:自訂規則應插入到訂閱自帶規則清單的最前面,而不是附加在末尾。原因正是上一節說的「命中即止」機制——訂閱提供的規則清單往往已經覆蓋了大量常見網域和 IP 段,若把自訂規則加在最後,連線大概率會先被訂閱規則比對掉,自訂規則永遠排不上號。只有把自訂規則放在最前面,才能確保它們擁有比訂閱規則更高的實際優先級。

常見做法是在規則清單頂部單獨開一段註解分隔,方便下次更新訂閱時快速定位並保留這部分內容:

rules:
  # ↓↓↓ 自訂規則,訂閱更新時需手動保留 ↓↓↓
  - DOMAIN-SUFFIX,internal.mycompany.com,DIRECT
  - DOMAIN-KEYWORD,ads,REJECT
  # ↑↑↑ 自訂規則結束 ↑↑↑
  - DOMAIN-SUFFIX,google.com,PROXY
  - GEOSITE,cn,DIRECT
  - MATCH,PROXY

需要特別注意的是,若用戶端設定了訂閱自動更新,而用戶端本身不支援「自訂規則單獨保存、合併時自動前置」這類進階功能,那麼每次訂閱刷新都會用遠端檔案整體覆蓋本地設定,手動加在頂部的規則會被一併沖掉。使用 Clash Verge Rev、FlClash 等支援「設定合併」或「覆寫(override)」功能的用戶端時,建議把自訂規則寫在獨立的覆寫檔案裡,而不是直接改訂閱生成的主設定,這樣訂閱更新時自訂部分不會遺失。

WARN

直接編輯訂閱生成的設定檔屬於臨時修改,大多數用戶端在下一次拉取訂閱時會整體覆蓋該檔案。若需要長期保留自訂規則,請優先使用用戶端的覆寫、合併或本地規則功能,而不是每次訂閱更新後手動重複新增。

SEC-05

典型場景與規則組合範例

以下幾組組合覆蓋了日常設定裡最常遇到的需求,可以直接參考並調整策略群組名稱後使用。

區域網路與台灣本地直連,其餘走代理

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

這組規則先排除區域網路與本機位址,避免內網存取被錯誤地丟進代理鏈路;再用 GEOSITE 覆蓋中國大陸網域,用 GEOIP 兜底覆蓋屬於中國大陸的 IP 但網域分類未收錄的情況;最後 MATCH 把剩餘流量統一交給代理策略群組。

廣告與追蹤網域攔截

rules:
  - DOMAIN-KEYWORD,doubleclick,REJECT
  - DOMAIN-SUFFIX,adservice.google.com,REJECT

REJECT 會直接丟棄比對到的連線請求,用戶端表現為該資源載入失敗或逾時。這類規則同樣必須放在其他允許該網域通過的規則之前,否則會被更寬泛的允許規則先行處理而失效。

指定應用程式強制直連

rules:
  - PROCESS-NAME,WeChat.exe,DIRECT
  - PROCESS-NAME,com.tencent.mm,DIRECT

部分即時通訊或本地網路應用程式對延遲和線路穩定性要求較高,單獨摘出來直連往往比強行套代理體驗更好。桌面端行程名稱通常帶副檔名,行動端 Android 應用程式則填寫應用程式套件名稱。

SEC-06

排查規則未生效的思路

規則寫完之後若分流結果不對,優先依下列順序檢查,而不是直接懷疑節點本身出了問題:

  1. 確認規則順序

    回看是否有一條範圍更寬的規則被寫在了目標規則之前,提前截獲了流量。這是最常見的原因。

  2. 確認 rule-providers 是否正確載入

    使用 GEOSITE 或 RULE-SET 時,若對應的規則集位址失效或格式不符,核心可能啟動失敗或該規則被靜默忽略,需要查看用戶端日誌確認載入狀態。

  3. 確認策略群組名稱拼寫一致

    規則第三段填的策略名稱必須與 proxy-groups 裡定義的名稱完全一致,大小寫和空格都要對齊,拼錯會導致該規則整體失效或報錯。

  4. 確認是否命中了更早的兜底規則

    若設定裡存在多條 MATCH 或過早出現的寬泛 GEOIP/GEOSITE 規則,新增的精確規則很可能被擠在了後面,永遠得不到執行。

規則系統一旦理清「自上而下、命中即止」這條主線邏輯,後續無論是接手陌生的訂閱設定,還是自己從零搭建分流策略,排查思路都會清晰許多。建議把自訂規則集中管理、加註解標記邊界,長期維護起來會更省心。

下載用戶端