Clash 自訂規則怎麼寫:DOMAIN、IP-CIDR 語法與比對優先順序詳解

一、規則條目的基本結構

Clash 的分流能力建立在一條條規則之上,設定檔中 rules: 欄位下的每一行都是一條獨立規則。規則的通用格式是三段式,以英文逗號分隔:

TYPE,ARGUMENT,POLICY

TYPE 表示比對依據的類型,例如網域、IP 位址段或程序名稱;ARGUMENT 是具體的比對值;POLICY 是命中後要套用的策略,可以是某個節點名稱、某個策略群組名稱,也可以是內建的 DIRECT(直連)或 REJECT(拒絕)。部分規則類型還支援第四段選填參數,最常見的是 no-resolve,用於告知核心在比對 IP 類規則時不要先進行 DNS 解析,避免不必要的查詢延遲或隱私外洩。一條完整的規則範例如下:

DOMAIN-SUFFIX,example.com,Proxy
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

理解這套三段式(加選填第四段)結構,是看懂後面所有規則類型的前提。

二、常見規則類型逐一拆解

Clash 核心(包含 Clash Meta / mihomo 分支)支援的規則類型不少,但日常設定中高頻出現的其實集中在以下幾類,依比對對象可分成網域類、IP 類、地理位置類與程序/連接埠類四組。

1. 網域類規則

• DOMAIN:精確比對完整網域,例如 DOMAIN,www.example.com,Proxy 只對這一個網域生效,子網域或其他前綴不會被命中。
• DOMAIN-SUFFIX:比對網域後綴,寫法為 DOMAIN-SUFFIX,example.com,Proxy,會同時命中 example.com 本身以及 www.example.com、api.example.com 等任意子網域,是最常用的一類網域規則。
• DOMAIN-KEYWORD:只要網域中包含指定關鍵字就命中,例如 DOMAIN-KEYWORD,google,Proxy 會比對任何含有「google」字樣的網域,比對範圍較廣,使用時要留意誤觸同名字串的其他網域。
• DOMAIN-REGEX:用正規表達式比對網域,適合需要精細控制、又不想逐條列出的情境,但書寫與偵錯成本較高,建議只在前三種類型無法滿足需求時才使用。

2. IP 與網段類規則

• IP-CIDR:依 IPv4 CIDR 網段比對,例如 IP-CIDR,10.0.0.0/8,DIRECT 表示整個私有網段都走直連。
• IP-CIDR6:語法與 IP-CIDR 一致,專用於 IPv6 網段。
• IP-SUFFIX:依 IP 位址後綴片段比對,使用情境相對小眾,多見於特定內網劃分。
• SRC-IP-CIDR:依發起連線的來源 IP 網段比對,常用於為區域網路內某些裝置單獨指定策略,而非依目標位址區分。

IP 類規則通常會搭配 no-resolve 參數使用,尤其是直連規則,因為直連流量本身不需要額外的解析開銷。

3. 地理位置類規則

• GEOIP:依目標 IP 所屬國家或地區判斷,例如 GEOIP,CN,DIRECT 表示識別為中國大陸 IP 的流量走直連。這類規則依賴一份 IP 地理資料庫,判斷精準度會受資料庫更新程度影響。
• SRC-GEOIP:與 GEOIP 類似,但判斷依據是請求發起端的地理位置,而非目標位址。

4. 程序與連接埠類規則

• PROCESS-NAME:依發起連線的程序名稱比對,例如 PROCESS-NAME,com.example.app,Proxy,適合為單一應用程式單獨制定策略,常見於行動裝置設定。
• PROCESS-PATH:依程序的完整執行檔路徑比對,精準度比 PROCESS-NAME 更高,但設定也更繁瑣。
• DST-PORT / SRC-PORT:依目標連接埠或來源連接埠比對,常用於將特定連接埠(如郵件、遊戲專用連接埠)固定走某條線路。

5. 規則集與兜底規則

• RULE-SET:引用一份外部規則集檔案,將一大批同類規則打包管理,方便以訂閱方式更新,避免手動維護成千上百條明細規則。
• MATCH:兜底規則,不需要參數,任何未被前面規則命中的流量最終都會落在這一條上,格式為 MATCH,POLICY。

三、比對優先順序:自上而下,一擊即中

理解 Clash 規則最關鍵的一點是:規則比對嚴格依照 rules: 清單中從上到下的順序逐條判斷,一旦某條規則命中,立即依該規則的策略處理,後面的規則不再繼續檢查。這意味著規則的先後位置本身就是一種優先順序設定,與規則類型本身並沒有天生的高低之分——寫在前面的類型,不管是 DOMAIN 還是 GEOIP,只要先被檢查到並命中,就會先生效。

舉一個容易踩雷的例子:

GEOIP,CN,DIRECT
DOMAIN-SUFFIX,example.com,Proxy

如果 example.com 所在伺服器的 IP 恰好被地理資料庫識別為中國大陸 IP,上面這份設定會在第一條 GEOIP 規則處就把流量導向直連,第二條針對該網域的代理規則永遠不會被執行到。想讓某個特定網域始終走代理,就必須把這條網域規則放在 GEOIP 之前:

DOMAIN-SUFFIX,example.com,Proxy
GEOIP,CN,DIRECT

這個順序問題在規則條目較多的設定中非常常見,排查「某個網站明明設了代理卻沒走代理」的問題時,第一件事就該去檢查有沒有更靠前的寬泛規則把它攔截了。

四、GEOIP 與 MATCH 的擺放要點

GEOIP 規則與 MATCH 兜底規則的擺放位置,是整份規則清單裡最值得單獨強調的兩處。

GEOIP 應該放在細分規則之後

GEOIP 判斷的是目標 IP 所屬的國家或地區,涵蓋範圍很大,一條 GEOIP,CN,DIRECT 可能會涵蓋成千上萬個具體網域。如果放在規則清單靠前的位置,很容易把本該走代理的特定服務也一併直連掉。穩妥的做法是先把需要精確控制的網域、應用程式、連接埠規則寫在前面,再把 GEOIP 類規則放在這些細分規則之後、兜底規則之前,讓它負責「大多數未特別標註的本地流量直連」這個角色。

MATCH 必須放在整份清單的最後一行

MATCH 是兜底規則,顧名思義要接住所有前面規則都沒處理到的流量。它不需要參數,格式固定為 MATCH,POLICY,常見寫法是 MATCH,Proxy 或 MATCH,DIRECT,取決於站台的分流策略偏好。這條規則若不放在最後,會導致它前面本該由具體規則處理的流量提前被兜底策略接管,後面寫的所有細分規則形同虛設。可以理解為:MATCH 一旦出現,它之後的規則永遠不會被執行到,所以它只能、也必須是最後一條。

五、可直接套用的排序建議

結合上面的機制,一份結構清晰的規則清單通常遵循「先精確、後寬泛,最後兜底」的排列思路,大致分五層:

1. 區域網路與私有位址直連:如 IP-CIDR,192.168.0.0/16,DIRECT,no-resolve,避免內網流量繞道走代理。
2. 特殊應用程式與連接埠的定向規則:如需要單獨控制的 PROCESS-NAME、DST-PORT 規則。
3. 需要重點關注的網域規則:常用服務的 DOMAIN-SUFFIX、DOMAIN 規則,明確指向代理或直連。
4. 規則集與地理位置規則:RULE-SET 引用的大批量規則,以及 GEOIP 兜底本地流量。
5. 最終兜底:一行 MATCH,決定所有未命中流量的預設去向。

一份精簡範例大致如下:

IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
PROCESS-NAME,com.example.updater,DIRECT
DOMAIN-SUFFIX,example.com,Proxy
DOMAIN-KEYWORD,ads,REJECT
RULE-SET,proxy-list,Proxy
GEOIP,CN,DIRECT
MATCH,Proxy

需要說明的是,規則集(RULE-SET)本身也是依其內部條目順序參與整體比對的,將它插入清單中的位置同樣遵循「前面已有更精確規則攔截,後面才輪到它」的原則。若同時引用多個規則集,也建議把範圍更窄、更需要優先生效的規則集放在範圍更廣的規則集前面。

六、常見排序失誤自查

實際使用中,規則不生效的原因絕大多數不是語法寫錯,而是順序問題。整理幾個最容易出現的情況:

• 把 GEOIP,CN,DIRECT 寫在所有網域規則之前,導致落在中國大陸 IP 段上的目標服務全部被直連攔截。
• DOMAIN-KEYWORD 關鍵字過於寬泛且排在前面,誤觸了原本應該走代理的其他網域。
• MATCH 之後又追加了幾條規則,這些規則永遠不會被執行,屬於無效設定。
• 把本該直連的區域網路網段規則放在最後,導致這部分流量先被前面某條寬泛的代理規則接管,存取內網裝置變慢。

排查這類問題時,與其反覆檢查單條規則的語法是否正確,更有效的方式是把整份 rules: 清單印出來,依順序在心裡模擬一遍比對過程,通常很快就能定位到是哪一條位置靠前的規則搶先命中了。