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

PROOF / 01

規則匹配模型：由上而下，首次命中即停止

Clash 的 rules 是一份按行排列的流量分流表。每條規則通常由「類型、匹配內容、目標策略」組成，部分類型還可附加參數。核心處理連線時會從清單頂端開始檢查，遇到第一條符合條件的規則後立即採用該行指定的策略，不再繼續檢查後續內容。

這裡的「優先順序」不是由規則類型自動決定。DOMAIN 並不會天然優先於 DOMAIN-SUFFIX，IP-CIDR 也不會自動覆蓋前面的網域規則。真正決定優先順序的是所在行的位置。因此，範圍較廣的規則若放得太前面，可能遮蔽後面更精確的例外規則。

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,節點選擇
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

以上順序會先讓 api.example.com 直連，再把該網域下的其他子網域交給「節點選擇」。如果交換前兩行，精確網域也會先被後綴規則捕捉，第一行的直連例外便會失效。最後的 MATCH 是兜底規則，用來接收先前未命中的連線，通常只放一條並置於末尾。

PROOF / 02

網域規則：精確主機、後綴與關鍵字

網域規則適合處理目標主機名稱明確的請求，也是自訂分流中最常用的一組類型。連線保留網域資訊時，核心可以直接進行匹配，不必先將目標解析成 IP。常見類型如下。

rules:
  - DOMAIN,login.example.net,DIRECT
  - DOMAIN-SUFFIX,example.net,工作服務
  - DOMAIN-KEYWORD,streaming,媒體節點
  - GEOSITE,cn,DIRECT
  - MATCH,節點選擇

DOMAIN,login.example.net 只會匹配這個完整主機，不會匹配 static.login.example.net。DOMAIN-SUFFIX,example.net 通常會同時涵蓋 example.net 及其各級子網域，適合作為網站層級規則。DOMAIN-KEYWORD 的範圍最難控制，只要目標網域包含指定片段就可能命中，因此應使用足夠明確的關鍵字，並放在精確規則之後。

GEOSITE 屬於資料集驅動的匹配方式。是否可用以及分類名稱的寫法，取決於所使用的核心、客戶端與地理資料檔案。移轉設定時，不應將某個客戶端可識別的分類直接視為所有 Clash 衍生核心都支援；應先檢查核心類型以及資料檔案是否已正確載入。

PROOF / 03

IP、來源位址與網路協定規則

當服務只能透過位址區段識別，或需要依區域網路來源、目標區域進行控制時，可以使用 IP 類規則。IPv4 位址區段通常使用 IP-CIDR，IPv6 位址區段使用 IP-CIDR6；GEOIP 則依據地理資料庫判斷目標 IP 所屬分類。

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR6,fd00::/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

no-resolve 的作用是阻止這條 IP 規則為了匹配而主動觸發網域解析。連線本身已提供目標 IP 時，規則仍可檢查該位址；目標只有網域名稱且核心尚未取得實際位址時，這條規則不會強制補做 DNS 查詢。區域網路保留位址規則常會加入此參數，因為它們不需要為一般網域額外解析。

是否加入 no-resolve 要依目標情況判斷。若希望 GEOIP 根據解析結果決定直連或代理，阻止解析可能使該規則無法取得所需位址。反過來，如果網域規則已涵蓋主要服務，IP 規則只是處理直接存取位址的連線，加入此參數便可避免不必要的解析動作。

在 Fake-IP 模式下，應用程式可能先看到核心分配的保留位址，Clash 則維護網域與實際目標之間的對應關係。網域規則通常仍可依據原始主機名稱運作，但排查 IP 規則時需要區分「應用程式看到的 Fake-IP」、「核心保存的網域對應」與「上游解析出的實際 IP」。只盯著瀏覽器或應用程式顯示的目標位址，容易誤判規則是否命中。

來源位址與網路類型

SRC-IP-CIDR 會依發起連線的裝置位址進行匹配，常用於路由器或區域網路閘道情境。例如，可以讓某台測試裝置使用獨立策略。NETWORK 則依 TCP 或 UDP 區分連線，適合與更具體的連接埠條件組合；如果單獨把所有 UDP 流量提前交給某個策略，影響範圍通常會過大。

rules:
  - SRC-IP-CIDR,192.168.50.25/32,測試策略
  - NETWORK,UDP,節點選擇
  - MATCH,DIRECT

桌面客戶端只代理本機流量時，來源位址資訊可能不像路由器透明代理情境那麼有區分度。使用前應先確認客戶端工作模式、TUN 接管範圍以及核心實際取得的連線中繼資料。

PROOF / 04

程序、路徑與連接埠匹配

程序規則可以依發起連線的應用程式進行分流。PROCESS-NAME 通常匹配可執行檔名稱，PROCESS-PATH 匹配完整路徑。它們適合處理同一網域被多個應用程式共用、只希望某個程式採用特定策略的情況。

rules:
  - PROCESS-NAME,example-client.exe,工作服務
  - PROCESS-PATH,C:\Apps\Example\example-client.exe,工作服務
  - DST-PORT,22,開發節點
  - DST-PORT,123,DIRECT
  - MATCH,節點選擇

程序識別能力會受到作業系統權限、客戶端實作、核心版本與接管模式影響。Windows、macOS 與 Linux 對程序名稱和路徑的表示方式不同，行動作業系統通常也不能直接套用桌面端的可執行檔規則。若記錄中只有目標位址而沒有程序欄位，繼續調整程序名稱通常無法解決問題，應先確認目前平台能否提供程序中繼資料。

DST-PORT 依目標連接埠匹配，SRC-PORT 依本機來源連接埠匹配。目標連接埠比來源連接埠更穩定，但也不能單獨代表某項業務：例如 TCP 443 被大量 HTTPS 服務共用，若提前將它設定為單一代理策略，便會覆蓋絕大多數網頁連線。連接埠規則更適合處理用途明確的協定，或在 mihomo 的邏輯組合規則中與網域、網路類型共同限定。

PROOF / 05

規則順序與優先順序的實用安排

便於維護的規則表通常遵循「例外在前、常規居中、兜底在後」的結構。可以先放必須直連或必須拒絕的精確主機，再放業務網域與程序規則，接著處理位址區段和地理分類，最後用 MATCH 收尾。具體順序仍應依實際目標調整，而不是機械套用固定範本。

1. 本機與管理位址：路由器後台、區域網路網段和本機服務通常優先直連，避免被廣泛代理規則攔截。
2. 精確例外：使用 DOMAIN、單一位址 CIDR 或明確程序名稱處理特殊需求。
3. 業務規則：依網域後綴、規則集合或應用程式程序分配至對應策略群組。
4. 廣泛分類：地理資料庫、關鍵字和大型規則集合放在更精確的規則之後。
5. 最終兜底：以 MATCH 指向預期的預設策略。

rules:
  # 區域網路
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve

  # 精確例外
  - DOMAIN,update.example.org,DIRECT
  - DOMAIN,blocked.example.org,REJECT

  # 一般業務
  - DOMAIN-SUFFIX,example.org,工作服務
  - PROCESS-NAME,media-player.exe,媒體節點

  # 區域與兜底
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

註解不會改變規則行為，但能顯著降低後續校對成本。建議為每組規則寫明用途，而不只是標記來源。訂閱更新或手動合併設定後，可以快速確認自訂段落是否仍位於預期位置。尤其要檢查客戶端的覆寫功能：有些客戶端會將自訂規則插入頂部，有些會追加到底部，還有些會在更新訂閱時重新產生完整設定。

PROOF / 06

規則集合與 mihomo 邏輯規則

規則數量較多時，可以透過 rule-providers 將規則內容拆分至獨立檔案，再在主規則表中使用 RULE-SET 引用。集合負責保存匹配項，主設定中的引用位置仍決定其整體優先順序。將集合定義在設定頂部，並不會讓它自動早於其他規則執行。

rule-providers:
  service-domains:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/service-domains.yaml
    url: https://rules.example.net/service-domains.yaml
    interval: 86400

rules:
  - DOMAIN,internal.example.net,DIRECT
  - RULE-SET,service-domains,工作服務
  - MATCH,節點選擇

behavior 必須與規則檔案內容相符。網域類集合可使用 domain 行為，IP 區段集合可使用 ipcidr，包含多種經典規則類型的集合通常使用 classical。不同核心版本對 format、支援的行為和資料檔案格式可能存在差異，匯入現成規則集前應核對客戶端實際使用的核心，而不能只看客戶端介面名稱。

mihomo 還提供邏輯組合能力，可用 AND、OR、NOT 將多個條件組合成一條規則。例如，僅處理 UDP 443 的條件可以寫成：

rules:
  - AND,((NETWORK,UDP),(DST-PORT,443)),REJECT
  - MATCH,節點選擇

邏輯規則適合表達「同時符合」或「符合其中一項」的複雜條件，但括號、逗號和巢狀層級更容易寫錯。它們屬於 mihomo 等相容核心的擴充能力，移轉至較早期的原版 Clash 核心時可能無法識別。為了維持設定可讀性，若用兩三條清晰的一般規則即可解決，就不必強行改成深層巢狀運算式。

PROOF / 07

規則未生效的排查順序

規則失效通常不只是單一語法問題。更有效的檢查方式，是沿著「設定是否載入、連線是否進入核心、中繼資料是否符合預期、是否被前序規則攔截」逐項確認。

1. 確認目前使用的 Profile：編輯檔案後重新載入設定，並核對客戶端目前啟用的設定名稱。修改未啟用的副本不會改變執行結果。
2. 查看連線或記錄中的命中規則：記錄目標網域、目標 IP、程序、網路類型和最終策略。若顯示命中了更前面的規則，應調整順序或縮小該規則範圍。
3. 檢查 YAML 層級：rules 必須位於正確的頂層位置，清單項目需要使用連字號。全形逗號、錯誤縮排和不可見字元都可能導致解析失敗。
4. 核對策略群組名稱：規則引用的名稱必須確實存在。重新命名代理群組後，舊規則中的目標名稱也要同步修改。
5. 區分網域與 IP：應用程式直接存取 IP 時，網域規則沒有可匹配的主機名稱；啟用加密 DNS、TUN 或 Fake-IP 後，也應結合核心記錄判斷實際中繼資料。
6. 檢查客戶端覆寫：訂閱更新、腳本合併和圖形介面的規則覆寫可能改變最終順序，應以執行時設定為準。
7. 確認核心支援：GEOSITE、邏輯規則、部分程序欄位和規則集格式並非所有核心版本都一致支援。

使用最小規則集重現問題

當原始設定包含數千條規則時，可以暫時建立一份只含測試規則和 MATCH 的最小設定。先驗證目標網域能否被精確規則命中，再逐步加入後綴、規則集合、GEOIP 與程序條件。每次只增加一組內容，便於定位是哪一行改變了結果。

rules:
  - DOMAIN,test.example.com,DIRECT
  - MATCH,節點選擇

如果最小設定能夠命中，而完整設定不能，問題通常出在前序規則、覆寫順序或規則集範圍；如果最小設定也無法命中，則應檢查流量是否進入 Clash、目標是否確實帶有該網域，以及客戶端目前是否載入了測試設定。

提交前校對清單

• 精確例外是否位於寬泛的後綴、關鍵字和規則集合之前。
• 所有策略名稱是否與代理群組名稱一致。
• IPv4、IPv6 與區域網路位址區段是否分別使用適合的規則類型。
• no-resolve 是否只用於不需要主動解析的 IP 規則。
• 程序規則是否符合目前作業系統與核心的識別方式。
• 規則集合的行為類型是否與內容格式一致。
• 清單末尾是否保留且只保留預期的兜底邏輯。

一份穩定的 Clash 自訂規則並不取決於規則數量，而取決於邊界清楚、順序可解釋，以及執行結果可複查。先用精確規則表達例外，再逐層擴大匹配範圍，最後透過記錄核對首次命中的規則，通常比不斷追加關鍵字更可靠。