Clash 自訂規則語法詳解：匹配類型、排列順序與優先順序

Clash 規則匹配模型

Clash 的規則系統用來回答一個具體問題：目前連線應交由哪個策略群組、代理節點或內建動作處理。連線進入核心後，規則會按照設定檔中的出現順序由上而下檢查；第一條符合條件的規則立即生效，後續規則不再參與本次連線。它不是彙整所有匹配結果後再比較「精確度」，也不會自動讓網域規則優先於 IP 規則。

一條常見規則由規則類型、匹配內容與目標策略三部分組成，各欄位以英文逗號分隔。例如：

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,Proxy
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,Final

DOMAIN、DOMAIN-SUFFIX 和 IP-CIDR 是規則類型；網域或網段是匹配內容；DIRECT、Proxy 與 Final 是處理目標。目標名稱必須與設定中的代理群組名稱完全一致，包括大小寫、空格與符號。DIRECT 表示直接連線，REJECT 表示拒絕連線，代理群組名稱則表示交由該群組決定最終使用的節點。

規則通常處理連線的中繼資料，例如目標網域、目標 IP、連接埠、網路類型與發起程序。它不會讀取網頁正文來判斷網站類別。若某個應用程式在同一頁面中存取多個網域，主頁面、圖片、影片、API 與統計請求可能分別匹配不同規則，因此判斷規則是否生效時，應查看具體連線，而不能只看網址列中的主網域。

網域匹配語法：精確、後綴與關鍵字

DOMAIN：只匹配完整網域

DOMAIN 適合處理明確的主機名稱。以下規則會匹配 api.example.com，但不會匹配 www.example.com、v2.api.example.com 或其他子網域：

- DOMAIN,api.example.com,Proxy

當某個 API 必須單獨分流，而同一主網域下的其他服務需要維持原有策略時，精確網域規則最合適。實際連線中的網域比較通常不區分字母大小寫，但建議統一使用小寫，方便檢閱、搜尋與去重。

DOMAIN-SUFFIX：匹配主網域及其子網域

DOMAIN-SUFFIX 是自訂規則中使用頻率較高的類型。以下規則可以涵蓋 example.com、www.example.com 與 cdn.media.example.com：

- DOMAIN-SUFFIX,example.com,Proxy

後綴值通常直接填寫網域，不必在前面加上句點或萬用字元。寫成 *.example.com 可能無法得到預期結果，因為規則類型本身已表達後綴匹配邏輯。需要排除某個子網域時，應將例外規則放在通用後綴規則之前：

- DOMAIN,internal.example.com,DIRECT
- DOMAIN-SUFFIX,example.com,Proxy

DOMAIN-KEYWORD：匹配網域中的片段

DOMAIN-KEYWORD 會檢查網域是否包含指定文字。例如 DOMAIN-KEYWORD,example,Proxy 不僅可能匹配 example.com，也可能匹配 example-cdn.net 與 notexample.org。它的涵蓋範圍較廣，適合網域結構經常變動但具有穩定命名片段的服務，不適合用來取代所有後綴規則。

關鍵字越短，誤匹配的機率越高。除錯時若發現無關網站走了代理，應優先檢查較前面的 DOMAIN-KEYWORD 規則。對於已知完整主網域的情況，應優先使用 DOMAIN 或 DOMAIN-SUFFIX。

GEOSITE：依網域分類集合匹配

Clash Meta，也就是目前常見的 mihomo 核心，支援透過 GEOSITE 使用預先整理的網域分類資料。例如：

- GEOSITE,category-ads-all,REJECT
- GEOSITE,cn,DIRECT

GEOSITE 可用的分類取決於用戶端隨附或下載的 GeoSite 資料檔。若分類名稱不存在、資料庫尚未更新，或用戶端使用的核心不支援該規則，設定可能報錯或無法按預期匹配。因此，從其他設定檔複製規則前，應先確認目前用戶端的核心類型與資料檔來源。

IP、連接埠與網路類型規則

IP-CIDR 與 IP-CIDR6

IP-CIDR 使用 CIDR 網段匹配 IPv4 目標位址，IP-CIDR6 用於 IPv6。斜線後的數字表示網路前綴長度。單一 IPv4 位址可寫成 /32，單一 IPv6 位址可寫成 /128：

- IP-CIDR,203.0.113.8/32,Proxy,no-resolve
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- IP-CIDR6,2001:db8::/32,Proxy,no-resolve

當連線最初提供的是網域時，部分 IP 類規則可能會觸發網域解析，以取得目標 IP 後繼續判斷。規則末尾的 no-resolve 表示不要為了檢查這條 IP 規則而額外解析網域。區域網路保留位址、已知伺服器位址等不需要網域補充解析的規則，通常可以加上此參數，以減少不必要的 DNS 查詢。

no-resolve 不代表關閉整個 Clash 的 DNS 功能，也不會阻止應用程式自行發出 DNS 請求。它只影響目前規則在匹配過程中是否主動將網域解析為 IP。若規則依賴解析後的位址範圍，就不應機械式地加上此參數。

GEOIP：依 IP 資料庫分類

GEOIP 會根據目標 IP 在地理資料庫中的分類進行匹配，常見寫法如下：

- GEOIP,CN,DIRECT,no-resolve

這類規則的結果取決於 GeoIP 或 GeoData 資料庫內容。IP 位址的歸屬可能變動，雲端服務與內容傳遞網路也可能跨地區調度，因此 GEOIP 更適合作為接近末尾的範圍規則，而不是覆蓋所有精確網域例外。需要固定處理方式的服務，應將明確的網域或 IP 規則放在它前面。

連接埠與協定

mihomo 支援透過 DST-PORT、SRC-PORT 與 NETWORK 等類型進一步限制連線。目標連接埠規則適合處理伺服器端連接埠，來源連接埠則針對本機連線使用的連接埠。網路類型通常寫成 tcp 或 udp：

- DST-PORT,22,SSH
- DST-PORT,3478-3481,Realtime
- NETWORK,udp,UDP-Policy

只依連接埠分流，容易影響其他使用相同連接埠的程式。例如 HTTPS 普遍使用 443 連接埠，將所有 443 流量交給某個固定策略通常過於寬泛。更穩妥的做法是結合網域、程序或邏輯規則縮小範圍，並在修改後觀察連線清單。

程序規則與邏輯組合

PROCESS-NAME 與 PROCESS-PATH

PROCESS-NAME 依發起連線的可執行檔名稱匹配，適合讓某個應用程式整體使用特定策略。例如 Windows 程式名稱通常包含副檔名：

- PROCESS-NAME,example.exe,Application-Proxy
- PROCESS-NAME,curl,DIRECT

PROCESS-PATH 可以匹配完整程式路徑，在同名可執行檔較多時更加精確。不過，路徑寫法受作業系統與核心實作影響，Windows 路徑中的反斜線、空格與 YAML 引號都需要正確處理。應用程式升級後安裝目錄改變，也可能導致舊路徑規則失效。

程序識別能力與平台、執行權限及流量接管方式有關。某些系統只能在特定權限下取得程序資訊，部分轉發鏈路也可能無法還原原始程序。遇到程序規則不生效時，應先在用戶端連線詳細資料中確認是否顯示程序名稱，而不是反覆調整規則文字。

AND、OR 與 NOT

mihomo 支援邏輯規則，可組合多個條件。例如只讓某個應用程式存取特定網域時使用代理：

- AND,((PROCESS-NAME,example.exe),(DOMAIN-SUFFIX,example.com)),Proxy
- OR,((DST-PORT,80),(DST-PORT,443)),Web
- NOT,((NETWORK,udp)),TCP-Policy

邏輯規則適合表達明確的交集、聯集與排除條件，但巢狀括號過多時，維護成本會迅速上升。不同核心版本對邏輯規則及子規則類型的支援範圍可能不同。儲存後若用戶端提示解析失敗，應對照目前的 mihomo 文件檢查括號、逗號與支援的規則類型。

排列順序與規則優先順序

Clash 的核心優先順序原則是「先匹配、先停止」。規則類型本身沒有統一的隱藏權重。即使後面存在更精確的 DOMAIN，只要前面的 DOMAIN-SUFFIX、GEOSITE 或其他廣泛規則已經匹配，後面的精確規則就不會執行。

實用的排列方式是將例外放在前面、範圍規則放在中間、兜底規則放在最後：

1. 區域網路位址、內部網域與必須直連的例外。
2. 需要固定代理或固定拒絕的精確網域。
3. 特定應用程式、連接埠及邏輯組合規則。
4. 網域後綴、規則集、GEOSITE 與 GEOIP 等範圍規則。
5. MATCH 兜底規則。

rules:
  - DOMAIN,login.internal.example,DIRECT
  - DOMAIN,api.example.com,Service-Proxy
  - PROCESS-NAME,example.exe,Application-Proxy
  - DOMAIN-SUFFIX,example.com,Proxy
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,Final

在這段設定中，api.example.com 會先匹配精確網域規則，不會落入後面的 example.com 後綴規則。其他屬於該後綴的網域會交由 Proxy 處理。未被前面任何規則處理的連線，最終交給 Final。

MATCH 是無條件兜底規則，應放在規則清單最後。部分舊設定會使用 FINAL 表達類似目的，但實際支援情況取決於核心。對於 mihomo 設定，優先依照目前核心文件使用 MATCH。如果將兜底規則放在中間，其後的規則將永遠沒有匹配機會。

當規則目標指向代理群組時，規則只決定「進入哪個群組」，節點選擇仍由代理群組類型決定。例如手動選擇群組會採用使用者目前選定的節點，自動測速群組則會根據群組內的測試結果選擇。排查線路時，需要區分「規則匹配到錯誤的群組」與「群組內選到不合適的節點」這兩個問題。

訂閱規則覆寫與持久化修改

訂閱設定通常由伺服器產生。直接在用戶端編輯展開訂閱後的 YAML，短時間內可以生效，但下次更新訂閱時，這些修改可能會被新設定取代。需要長期保留的自訂規則，應使用用戶端提供的覆寫、設定合併、擴充指令碼或本機設定功能。

不同用戶端對合併功能的命名各異，但目標通常分為三類：

• 前置規則：插入訂閱規則清單開頭，適合新增高優先順序例外。
• 後置規則：追加到清單末尾，但如果訂閱已包含 MATCH，追加內容可能永遠無法匹配。
• 整體替換：以自訂清單取代訂閱中的全部規則，需要自行保留必要的區域網路、DNS、直連與兜底邏輯。

因此，「追加一條規則」不一定等於「提高優先順序」。如果目標是覆寫訂閱已有的結果，新規則必須出現在相關廣泛規則與最終兜底規則之前。使用圖形化用戶端時，應查看合併後的實際設定或執行中的設定，而不只看覆寫編輯框中的順序。

RULE-SET 與 rule-providers

當規則數量較多時，可以透過 rule-providers 引用規則集，再在主規則清單中使用 RULE-SET。規則提供者負責載入規則內容，RULE-SET 在主清單中的位置仍決定其優先順序：

rule-providers:
  private-services:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/private-services.yaml
    url: https://rules.example.com/private-services.yaml
    interval: 86400

rules:
  - DOMAIN,exception.example.com,DIRECT
  - RULE-SET,private-services,Proxy
  - MATCH,Final

behavior 應與規則集內容一致。常見行為包括 domain、ipcidr 與 classical。網域行為適合網域集合，IP 行為適合網段集合，經典行為可以容納帶有類型的完整規則內容。規則檔案的具體格式還與 format 及核心版本有關，不能將完整主設定中的 rules 區段直接當作任意格式的規則提供者檔案。

遠端規則集載入失敗時，應確認 URL 可存取、檔案格式正確、儲存路徑可寫入，並檢查用戶端日誌。若關鍵分流依賴遠端規則集，建議保留合理的最終兜底，避免規則集暫時無法使用時，連線沒有明確去向。

規則不生效的排查順序

規則問題適合從執行結果反向推查，而不是一次修改大量內容。以下順序可以區分語法、順序、解析與用戶端能力問題。

1. 確認目前設定已啟用。用戶端可能同時儲存多個設定檔。修改後要執行儲存、重新載入或切換設定，並確認目前執行中的設定就是剛才編輯的版本。
2. 查看連線詳細資料。記錄目標網域、目標 IP、網路類型、程序名稱、匹配到的規則與最終策略群組。連線清單顯示的是核心實際判斷結果，比根據網頁網域猜測更可靠。
3. 檢查更前面的廣泛規則。重點搜尋 DOMAIN-KEYWORD、DOMAIN-SUFFIX、GEOSITE、GEOIP、RULE-SET 與 MATCH。
4. 檢查策略名稱。規則末尾的目標必須存在。群組重新命名後，舊規則可能仍指向已刪除的名稱。
5. 確認 DNS 觀察結果。應用程式可能直接連線至 IP，也可能使用快取、加密 DNS 或自身的解析機制。未取得網域資訊時，網域規則可能無法參與匹配。
6. 確認核心支援。程序、邏輯、GEOSITE 與部分連接埠規則依賴核心及平台能力。查看啟動日誌中的未知規則或設定解析提示。
7. 清除舊連線後重試。已建立的長連線通常不會因規則修改而立即重新匹配。關閉對應應用程式的連線、清除用戶端連線記錄或重新啟動應用程式後再測試。

為什麼精確網域仍然沒有匹配

常見原因包括實際請求存取了其他子網域、連線詳細資料只有 IP、精確規則位於廣泛規則之後，或修改被訂閱更新覆蓋。現代網站經常將登入、API、靜態資源與影片分配到不同網域。可以先在連線清單中篩選應用程式程序，再逐一確認目標主機。

為什麼規則顯示已匹配，但存取結果沒有變化

匹配正確只代表連線進入了指定策略。還要檢查策略群組目前的選擇、節點連線能力、DNS 回應、應用程式快取，以及是否存在獨立的 IPv6 連線。如果策略群組是自動選擇類型，群組內節點可能在測試後變更；如果網域同時回傳 IPv4 與 IPv6，兩條連線也可能匹配不同類型的規則。

最小化測試設定

複雜設定難以判斷衝突來源時，可以暫時新增一條足夠精確的規則並放在清單最前面，再將它指向容易識別的策略群組。測試成功後，逐步恢復規則順序。不要同時修改 DNS、TUN、代理群組與大量規則，否則出現變化時很難確定真正原因。

如果用戶端需要透過 TUN 模式接管不遵循系統代理的應用程式，還應先確認 TUN 已正常啟動，且路由與 DNS 劫持設定符合目前平台要求。TUN 負責將流量送入核心，規則負責決定流量進入核心後的處理方式，兩者處於不同環節。未被 TUN 接管的連線，自然不會出現在規則匹配記錄中。