Clash 自訂規則設定教學：rules 語法、比對順序與優先級

1. rules 的作用範圍與基本語法

rules 是設定檔頂層的有序清單，用來決定連線交由哪個策略處理。它不會建立節點，也不會執行速度測試。規則右側可填入內建策略 DIRECT、REJECT，也可填入設定檔中已存在的代理節點名稱或策略群組名稱。名稱必須完全一致，包括空格與大小寫。

本文以 Clash Nyanpasu 使用 mihomo 核心的常見規則模式為例。不同 Clash 核心支援的擴充規則不盡相同；移轉設定時，請先從用戶端的核心資訊或啟動記錄確認實際使用的核心。以下基本網域規則可協助理解流量分流，但不代表所有核心都支援相同的進階欄位。

先確認模式，再編輯欄位

Rule 模式：依照 rules 清單判斷連線的處理方式，本文討論的就是這種模式。
Global 模式：使用全域策略，不會依一般 rules 清單進行分流。
Direct 模式：以直連方式處理流量，無法用來驗證代理分流規則。

YAML 中的 mode: rule 代表規則模式。用戶端介面也可能切換執行模式，因此請一併確認目前的執行狀態。系統代理與 TUN 決定哪些流量會進入核心，並非控制規則優先級的開關；未進入核心的連線，不會因新增規則就自動交由核心處理。

mode: rule
rules:
  - DOMAIN,portal.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,節點選擇
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,節點選擇

2. 常用規則類型與欄位位置

一般規則通常採用「類型、比對內容、目標策略」的格式。MATCH 不需要比對內容；部分 IP 規則可加上 no-resolve。參數之間以半形逗號分隔，清單項目保留前置短橫線與空格，縮排統一使用空格，不要使用 Tab。

類型	範例	比對說明
`DOMAIN`	`DOMAIN,api.example.com,DIRECT`	只比對完整網域 api.example.com。
`DOMAIN-SUFFIX`	`DOMAIN-SUFFIX,example.com,DIRECT`	比對根網域及其各層子網域。
`DOMAIN-KEYWORD`	`DOMAIN-KEYWORD,example,節點選擇`	比對網域中包含的字串，涵蓋範圍較廣。
`IP-CIDR`	`IP-CIDR,10.0.0.0/8,DIRECT,no-resolve`	比對 IPv4 位址範圍。
`IP-CIDR6`	`IP-CIDR6,fc00::/7,DIRECT,no-resolve`	比對 IPv6 位址範圍。
`GEOIP`	`GEOIP,CN,DIRECT`	依目標 IP 所屬的地理資料庫項目判斷。
`RULE-SET`	`RULE-SET,business,節點選擇`	引用名稱為 business 的規則提供者。
`MATCH`	`MATCH,節點選擇`	接收前面所有規則都未符合的連線。

網域規則不填 URL 路徑

DOMAIN 的比對內容是主機名稱，不是完整網址。應填入 api.example.com，而非 https://api.example.com/login。一般網域規則無法區分同一主機下的 /login 與 /images。HTTPS 請求的路徑也不是一般網域分流可直接使用的條件。

DOMAIN-SUFFIX,example.com 會比對 example.com 和 a.example.com，不會因為另一個網域含有相似字元就比對到 notexample.com。而 DOMAIN-KEYWORD 是字串條件，容易擴大比對範圍，通常應排在明確的網域例外之後。

3. 規則優先級：由上而下，採用第一條符合規則

一般規則清單不會自動依照「網域規則優先於 IP 規則」或「越精確越優先」排序。核心會依清單順序逐一檢查，遇到第一條符合的規則後，就採用其目標策略，不再由下方規則覆蓋。只有將精確規則排在涵蓋範圍較廣的規則之前，才能建立有效的例外。

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

api.example.com：符合第 1 條規則，直連。
www.example.com：不符合第 1 條規則，符合第 2 條規則，交由「節點選擇」處理。
example.net：前兩條規則都不符合，由第 3 條規則兜底。

如果把第 2 條移到第 1 條之前，api.example.com 會先符合後綴規則，原本的直連例外就會失效。同樣地，若將 MATCH 放在清單第一行，後續的一般規則就沒有比對機會。

建議的排序層次

明確例外：需要個別處理的完整網域、內部服務或指定裝置條件。
區域網路目標：依實際網路需求填入私有位址範圍，避免內部服務誤走代理。
業務規則：特定網域後綴、業務規則集，以及刻意設定的封鎖規則。
廣泛分類：例如依 GEOIP 分類的直連規則。
最後兜底：設定一條 MATCH，明確指定未知流量的處理方式。

這是一種方便維護的排序方式，並非核心強制規定的固定順序。若某個業務網域必須經過代理，即使其位址被地理資料庫歸類為 CN，也應將該業務規則排在 GEOIP,CN,DIRECT 之前。

4. IP-CIDR、GEOIP 與 no-resolve

IP-CIDR,192.168.0.0/16,DIRECT 涵蓋從 192.168.0.0 到 192.168.255.255 的 IPv4 位址。只處理單一 IPv4 位址時可使用 /32；只處理單一 IPv6 位址時可使用 /128。網段範圍應依實際需求填寫，不要把所有內部網路位址都視為同一項業務規則。

連線目標是網域時，IP 類規則可能需要解析網域才能判斷。加上 no-resolve 表示不要為了這條規則主動觸發網域解析；如果連線已取得可用的目標 IP，仍可進行位址比對。這不代表關閉整個用戶端的 DNS，也不代表略過所有 DNS 請求。

rules:
  - DOMAIN,intranet.example.com,DIRECT
  - 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
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

此處將已知的內部網域個別排在前面，是因為含有 no-resolve 的位址規則無法保證只靠網域就能判斷出其內部網路位址。GEOIP 依據的是目標 IP 的資料庫分類，不是頁面內容、網域註冊地或伺服器品牌；CDN 位址與資料庫更新都可能影響結果。

5. 搭配使用 RULE-SET 與 rule-providers

規則數量較多時，可將比對內容放入規則提供者，再用 RULE-SET 引用。rule-providers 定義資料來源與格式，rules 則決定它在比對順序中的位置，以及符合時採用的策略。提供者名稱相同，不代表它會自動參與流量分流，仍須在 rules 中引用。

本機 domain 規則集範例

以下使用 mihomo 的本機檔案提供者。請將規則集檔案放在核心實際使用的設定目錄中；相對路徑取決於執行時的工作目錄，不應只根據下載檔案的位置推斷。可從用戶端記錄確認實際讀取路徑。

rule-providers:
  business:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/business.yaml

rules:
  - DOMAIN,health.example.org,DIRECT
  - RULE-SET,business,節點選擇
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

./rules/business.yaml 的內容如下。對於 domain 類型，+.example.org 代表比對該網域及其子網域；不要將完整的 DOMAIN-SUFFIX,example.org,節點選擇 規則列直接放進 domain 類型的清單。

payload:
  - '+.example.org'
  - 'api.example.net'

behavior: domain：內容為網域比對運算式。
behavior: ipcidr：內容為 IP 位址範圍。
behavior: classical：內容為相應核心支援的規則條件，例如 DOMAIN-SUFFIX,example.org，通常不會在項目中填寫目標策略。

三種 behavior 不可任意混用。遠端提供者還涉及下載、更新與快取；排解問題時，請先確認提供者載入成功，再檢查規則優先級。即使規則集包含數千筆項目，它在主清單中的優先級仍由那一行 RULE-SET 的位置決定；主清單中更前面的規則一旦符合，就不會被它覆蓋。

6. 訂閱規則的持續保存與覆寫檢查

遠端訂閱更新時可能會重新產生設定檔。直接修改下載的 YAML，常見結果是這次有效、下次更新就消失。較穩妥的做法是保留原訂閱，將個人規則放在用戶端支援的本機覆寫、合併或腳本處理流程中，並確認處理後的最終順序。各版本用戶端的功能名稱可能不同，不要把「儲存訂閱文字」當成「儲存永久覆寫」。

備份目前可用的設定，記下選用的 Profile、模式與策略群組名稱。
在設定檔管理中確認目前使用的設定檔，不要只編輯未啟用的副本。
先加入一條明確的網域規則，並確認它排在原有的廣泛規則之前。
查看執行時產生的設定檔，確認只有一份 rules，並檢查第一行、規則集引用及結尾的 MATCH。
執行一次訂閱更新，再次確認規則是否保留及順序是否變動。

不同合併工具處理清單的方式可能是取代、附加或插入在前。只在文字中看到新規則，不足以證明規則有效：附加在 MATCH 後面的規則雖然存在，卻不會有比對機會。腳本覆寫也應檢查輸出結果，而不只是確認腳本是否執行成功。YAML 層級與欄位說明請參閱YAML 設定手冊。

7. 自訂規則未生效時的排查順序

排查時請使用相同的目標主機、固定策略群組選擇，並且每次只修改一個條件。連線面板中的「符合規則」、「目標策略」與「實際代理鏈」代表不同資訊：符合「節點選擇」只表示連線交給該群組處理；如果群組內選擇的是 DIRECT，實際上仍會直連。

狀況	優先檢查	處理方式
連線面板沒有目標請求	應用程式流量是否進入核心	檢查系統代理、應用程式代理或 TUN 路由，先確認流量入口。
符合了涵蓋範圍較廣的舊規則	自訂規則的實際排列順序	將精確例外移到該規則之前，確認覆寫方式是否只是附加規則。
提示策略不存在	規則右側的群組名稱	複製目前設定檔中的完整群組名稱，並確認空格、大小寫與設定檔切換狀態。
RULE-SET 載入失敗	提供者名稱、路徑與 behavior	檢查啟動記錄與檔案格式，先修正載入錯誤再測試流量。
修改後仍採用舊策略	是否沿用舊連線	關閉目標連線後重新送出請求，不要只重新整理既有的長連線。
更新訂閱後規則消失	修改是否保存在產生的設定檔中	改用可持續保存的覆寫方式，並檢查更新後的最終設定檔。

最精簡的驗證流程

確認執行模式為 Rule，並確認所選設定檔已套用。
為實際測試的網域新增一條 DOMAIN 規則，並將它排在清單前段。
儲存並套用設定；若出現解析錯誤，先還原備份，不要繼續疊加修改。
關閉該目標的既有連線，再重新連線一次。
在連線詳細資訊中確認目標主機、符合的規則、策略群組與實際出口。
確認結果正確後，再擴充為後綴規則或規則集，並重新測試未符合規則時的兜底路徑。

維護規則的核心在於三點：流量確實進入核心、比對條件與連線資訊一致，以及目標規則排在會涵蓋它的規則之前。先用精確網域建立可重現的結果，再加入 IP 分類與規則集，比起一次修改大量項目，更容易找出問題原因。若要確認 Profile、策略群組與 TUN 的概念，請參閱術語手冊。