Clash 自訂規則怎麼寫？規則類型、比對順序與 MATCH 預設規則

規則生效的前提：規則模式、流量接管與設定持久化

Clash 自訂規則的用途，是為已進入核心的連線選擇出口。規則寫對了，不代表所有軟體的流量都會經過它：系統代理通常只影響遵循代理設定的應用程式；TUN 能接管更多流量，但仍會受到路由、權限與排除項目的限制。排查時，先到用戶端的「連線」頁面確認看得到目標請求，再檢查命中的規則。

本文以 Clash 常見規則語法為基礎，涉及程序識別時主要參考 Clash Meta（mihomo）。不同核心與作業系統的支援範圍各異，不能把特定用戶端提供的編輯介面當成核心功能清單。請先從用戶端的核心資訊或啟動記錄確認實際執行的核心，再使用相應功能。

將執行模式切換為「規則」，並在設定檔中設為 mode: rule。全域模式不會依照這裡的分流規則選擇出口。
確認目前啟用的是正在編輯的設定檔，而不是另一份同名訂閱。
先備份原設定檔，再用用戶端提供的設定檢查功能驗證 YAML，然後重新載入。
關閉目標應用程式的舊連線，再重新發出請求。規則更新後，已建立的連線通常不會自動切換出口。

規則基本語法：類型、比對內容與策略名稱

多數規則的格式為 類型,比對內容,策略。策略可以是內建的 DIRECT、REJECT，也可以是設定檔中已定義的代理節點或代理群組名稱。MATCH 不需要比對內容，寫成 MATCH,策略 即可。規則欄位以英文逗號分隔，每條規則在 YAML 清單中都是一個字串。

規則類型	範例	比對範圍
`DOMAIN`	`DOMAIN,api.example.com,DIRECT`	完全符合此網域
`DOMAIN-SUFFIX`	`DOMAIN-SUFFIX,example.com,DIRECT`	根網域及其子網域
`DOMAIN-KEYWORD`	`DOMAIN-KEYWORD,example,REJECT`	網域包含指定字串
`IP-CIDR`	`IP-CIDR,192.168.0.0/16,DIRECT,no-resolve`	目標 IPv4 位址位於此網段
`IP-CIDR6`	`IP-CIDR6,fc00::/7,DIRECT,no-resolve`	目標 IPv6 位址位於此網段
`PROCESS-NAME`	`PROCESS-NAME,curl.exe,DIRECT`	符合識別到的程序名稱
`MATCH`	`MATCH,DIRECT`	接管前面規則都未命中的連線

代理群組名稱必須確實存在

PROXY 並不是自動存在的「代理總開關」。如果設定檔中沒有名為 PROXY 的節點或群組，引用它時可能會在載入設定時出現找不到代理的錯誤。同樣地，節點選擇 和 節點選擇 2 是不同名稱，不能只看畫面顯示就猜測名稱。

以下範例只示範規則清單，並假設原設定檔已定義名為「節點選擇」的代理群組。如果不符合這個條件，請改用現有的策略名稱，不要直接貼上後期待系統自動建立。

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

規則中的網域不需加上 https://，也不包含路徑或連接埠。若只想處理 https://example.com/docs 中的 /docs 路徑，不能靠 DOMAIN 達成：這裡設定的是連線層級的分流，不是 HTTP 路徑路由。

由上而下比對：明確例外放前面，廣泛規則放後面

一般規則會依清單順序逐條檢查，第一條命中後就會決定策略，不會繼續往下找「更精確」的規則。系統不會自動把 DOMAIN 排在 DOMAIN-SUFFIX 前面，也不會依網段長度自動重新排序。因此，規則順序本身就是設定邏輯的一部分。

rules:
  - "DOMAIN,api.example.com,DIRECT"
  - "DOMAIN-SUFFIX,example.com,REJECT"
  - "MATCH,DIRECT"

api.example.com：命中第一條，使用 DIRECT，不會再被第二條拒絕。
www.example.com：不符合第一條，命中第二條，使用 REJECT。
example.com：同樣會命中第二條，後綴規則也包含根網域本身。
notexample.com：不屬於 example.com 的網域階層，最後會套用第三條。

如果把前兩條對調，api.example.com 也會被拒絕。修正時不必新增重複規則，只要把例外移到廣泛規則之前即可。常見的排列方式是：明確的業務例外、視需求設定的區域網路直連、分類規則集、地區 IP 規則，最後才是預設規則。不過這不是硬性順序；業務例外是否優先於區域網路策略，應依實際需求決定。

關鍵字規則容易擴大比對範圍

DOMAIN-KEYWORD,example 會比對網域中的字串，而非網域階層，因此可能連 notexample.com 也一起命中。若要替特定網站及其子網域分流，通常可優先考慮 DOMAIN-SUFFIX。別為了少寫幾行，就把短關鍵字規則放在清單最前面，否則可能連不相關的服務也一併套用。

IP-CIDR 與 no-resolve：限制主動解析，不是關閉 DNS

IP-CIDR 用來檢查目標位址是否屬於特定網段。請求帶有網域名稱時，核心可能需要先取得目標 IP，才能判斷是否符合 IP 規則。在規則中加入 no-resolve，代表不要為了評估這條規則而主動觸發網域解析；這不是「略過 IP 比對」，更不表示「這條連線永遠不會使用 DNS」。

rules:
  - "IP-CIDR,10.0.0.0/8,DIRECT,no-resolve"
  - "IP-CIDR,172.16.0.0/12,DIRECT,no-resolve"
  - "IP-CIDR,192.168.0.0/16,DIRECT,no-resolve"
  - "IP-CIDR6,fc00::/7,DIRECT,no-resolve"
  - "MATCH,DIRECT"

上面列出三個常用的 IPv4 私有網段，以及 IPv6 唯一本地位址範圍，作為區域網路規則範例；這不是完整的特殊用途位址清單。如果連線本來就是前往 192.168.1.1，目標 IP 已經明確，含有 no-resolve 的規則仍然可以命中。

分別驗證網域連線與 IP 連線

能直連 192.168.1.1，不代表連線到解析為該位址的網域時，也一定會命中同一條規則。如果核心尚未取得實際目標位址，no-resolve 會影響是否為 IP 規則主動解析。已取得的目標 IP、DNS 快取及 Fake-IP 對應等狀態，也會影響實際判斷，請以連線詳細資訊為準。

PROCESS-NAME：程序規則的權限與平台限制

程序規則適用於「讓特定程式固定使用某個出口」的需求。例如在 Windows 上，PROCESS-NAME,curl.exe,DIRECT 可套用到核心識別為 curl.exe 的連線。名稱應以連線詳細資訊中實際顯示的程序名稱為準，不要用桌面捷徑名稱或視窗標題代替。

確認系統支援：程序偵測取決於核心、作業系統及執行權限。mihomo 的 find-process-mode 會影響程序搜尋方式；若設為 off，就不能期待程序規則正常識別。
確認流量來源：路由器轉送的其他裝置流量，通常無法在路由器上取得遠端應用程式的本機程序名稱。這種情況可考慮使用來源位址規則，而不是勉強套用程序名稱。
確認規則順序：若要讓程序規則優先於一般網站分流，應將它放在相關網域規則之前；若只作為補充，則放在這些規則之後、MATCH 之前。
確認相關程序：同一個應用程式可能由多個程序連線。瀏覽器核心、更新程式與主程式顯示的名稱不一定相同，請逐一查看實際連線。

Android 用戶端中的依應用程式代理或應用程式排除清單，通常屬於 VPN 流量接管範圍設定，不能直接視同桌面平台的 PROCESS-NAME。若流量已被排除，就不會進入核心供一般規則比對。

MATCH 預設規則：最後一條決定未分類流量的去向

MATCH 不帶網域或網段條件，會接管執行到這裡的連線。它應放在一般規則清單的最後；若放在開頭，後續的一般規則就沒有比對機會。通常保留一條明確的預設規則即可，多寫幾條不會形成故障轉移。

mode: rule
rules:
  - "DOMAIN,api.example.com,DIRECT"
  - "DOMAIN-SUFFIX,example.com,REJECT"
  - "IP-CIDR,192.168.0.0/16,DIRECT,no-resolve"
  - "MATCH,DIRECT"

以下範例只示範內建策略語法：拒絕指定網域，其餘流量直連。這不是通用的代理方案。如果未分類流量要走代理，請將最後一行的 DIRECT 改為現有的代理群組名稱，並確認該群組目前選取了所需出口。

預設策略沒有標準答案。預設走代理能涵蓋未分類的境外服務，但可能讓本地服務繞遠路；預設直連則能減少誤走代理的情況，但需要為目標服務補上規則。先決定預設行為，再補上例外，比反覆切換全域模式更容易找出問題。

驗證與排錯：從執行中的設定查到新連線

排查規則時應建立完整的證據鏈：設定是否載入、請求是否進入核心、命中哪條規則，以及最後使用哪個出口。只看網頁能不能開啟，很難分辨是 DNS、規則還是節點故障。

檢查最終設定：確認頂層只有一個預期的 rules: 鍵，清單縮排一致，且未使用 Tab。找出新增規則實際所在的位置，尤其要確認它沒有被加在 MATCH 後面。
檢查載入記錄：若提示策略不存在，請逐字核對代理群組名稱；若提示不支援規則類型，請確認核心具備相應功能，不要試圖靠調整縮排來掩蓋功能差異。
發出新請求：先關閉原有連線，再連線至測試目標。在「連線」頁面查看網域、目標 IP、規則類型與代理鏈。各用戶端的連線詳細資訊欄位名稱可能不同。
排除代理入口問題：使用明確指定代理的請求，可排除應用程式未遵循系統代理設定的影響；但仍須確認監聽連接埠確實屬於目前使用的核心。

curl -I --proxy http://127.0.0.1:7890 https://example.com

以下假設本機 HTTP 或混合代理連接埠為 7890。若實際的 mixed-port 設為 7897，命令中的連接埠也必須一併修改。此測試只檢查明確指定的 HTTP 代理路徑，無法單獨證明 TUN 接管正常；前面的拒絕範例中，無法連線到該網域反而符合規則預期，請同時查看命中記錄。

三種常見狀況的排查順序

規則已儲存卻沒有作用：先檢查目前啟用的設定檔和最終規則清單，再確認執行模式，最後關閉舊連線並重新測試。不要馬上新增重複項目。
網域規則一直沒有命中：確認核心是否取得網域資訊。若只有目標 IP，且沒有可用的網域對應或嗅探結果，就不能要求網域規則憑空識別網站。
命中代理群組但出口不對：檢查群組目前的選擇及代理鏈。規則決定交由哪個策略處理，代理群組再決定實際節點，兩個層級都要檢查。

穩定的修改方式是一次只調整一類規則，完成載入檢查後，再用新連線複測。精確規則在前、廣泛規則在後、以 MATCH 收尾，再搭配可持久保存的覆寫機制，才不會每次更新訂閱後，又把剛修好的路由還原。