規則進階 預計閱讀 12 分鐘

Clash 自訂規則設定教學：DOMAIN-SUFFIX、IP-CIDR、GEOIP 與由上而下的比對順序

整理 Clash 常用規則格式與適用情境，說明由上而下比對、命中即停止，以及 rule-providers 和 MATCH 兜底規則的配置位置。

規則格式：類型、比對內容與出口策略

Clash 自訂規則寫在 YAML 設定檔的 rules: 清單中。用戶端以規則模式執行時，核心會依照清單決定連線使用哪個出口。本文以 Clash 通用規則語法為基礎；涉及規則集載入時，則以 mihomo 支援的設定為準。圖形用戶端提供編輯介面，實際執行規則的是目前啟用的核心。

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

這是要合併至現有設定的片段，並非完整訂閱。範例中的 節點選擇 必須是現有 proxy-groups 中的策略組名稱，也可以換成設定檔裡已有的節點名稱。名稱必須完全一致，包括空格與大小寫；若策略不存在，可能會導致設定載入失敗。

  • DOMAIN：規則類型，用來決定如何解讀第二個欄位。
  • example.com：比對內容，此處為完整網域，不包含通訊協定、路徑或連接埠。
  • DIRECT：內建直連策略，由本機網路直接連線至目標。
  • REJECT：內建拒絕策略，用來阻擋符合規則的連線。
  • no-resolve：部分 IP 類規則支援的附加參數，並非出口名稱。

DOMAIN-SUFFIX：網域後綴與精確網域的差異

只比對單一主機名稱時使用 DOMAIN；要比對某個網域及其所有子網域時，則使用 DOMAIN-SUFFIX。後綴比對會以網域標籤邊界為準，不是任意搜尋一段字串。

規則範例可比對無法比對
DOMAIN,example.com,DIRECTexample.comwww.example.com
DOMAIN-SUFFIX,example.com,DIRECTexample.com、api.example.comnotexample.com
DOMAIN-KEYWORD,example,DIRECT網域中包含 example 的主機不含該字串的網域

例外規則應排在後綴規則之前

假設整個 example.com 都要直連，只有 api.example.com 需要透過代理。請先寫精確網域，再寫涵蓋範圍較大的後綴規則：

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

若將前兩行對調，API 網域會先符合後綴規則並直連。核心不會因為後面還有更精確的規則，就重新選擇出口。DOMAIN-KEYWORD 的涵蓋範圍較廣，容易連不相關的網域也一起比對到；若能用精確網域或後綴表達，請優先採用範圍明確的規則。

網域規則無法比對網頁路徑

不要把 https://example.com/video 寫進 DOMAIN。此處比對的是主機名稱，不是完整 URL。同一網域下的 /video 與 /docs 無法用上述網域規則區分。對於 HTTPS，核心也無法只靠這些規則讀取加密後的網頁路徑。

IP-CIDR 與 GEOIP：位址範圍、資料庫及 no-resolve

IP-CIDR 用來比對目標 IPv4 網段，IP-CIDR6 則適用於 IPv6。斜線後的數字代表前綴長度，不是連接埠。單一 IPv4 位址可寫成 /32，單一 IPv6 位址則可寫成 /128。

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

前三條涵蓋常見的 IPv4 私有位址範圍，第四條涵蓋 IPv6 唯一本機位址範圍。這些是核心內的分流規則，不代表所有區域網路連線都會進入核心。系統代理的略過清單與 TUN 的路由排除設定，仍可能讓相關連線直接繞過用戶端。

GEOIP 不代表判斷網站所屬國家

GEOIP,CN,DIRECT 會依據核心使用的 IP 地理資料比對目標位址，不會檢查網域後綴、公司註冊地或使用者帳號所在地。CDN 位址變動、DNS 回應差異及地理資料庫版本不同，都可能影響比對結果。若要固定處理特定服務，應將明確的網域規則排在 GEOIP 之前。

no-resolve 只限制目前規則觸發解析

連線只有網域資訊、尚無可用的實際目標 IP 時，IP 類規則可能會觸發 DNS 解析，以判斷位址。加上 no-resolve 後，該規則不會為了比對而主動解析網域；如果連線已有可用 IP，仍可進行位址比對。

  • 私有網段規則加上 no-resolve，通常可減少單純為判斷私網位址而進行的解析。
  • 在 GEOIP 加上此參數後，只有網域、沒有可用 IP 的連線可能會略過這條規則，繼續比對後續規則。
  • 若前面的規則已觸發解析，後面的 no-resolve 不會撤回已取得的結果。

比對順序：由上而下，符合第一條後即停止

規則清單不會自動依「精確規則優先」排序，也不會按規則類型自動將 DOMAIN 排到 GEOIP 前面。一般分流流程是先讀取第一條規則，未符合才檢查下一條；一旦符合，就將連線交給對應策略，不會再繼續尋找更適合的規則。

  1. 最前面放明確的例外規則。例如必須透過代理的 API，或必須拒絕連線的測試網域。
  2. 接著放網域與服務規則集。在處理 IP 歸屬之前，先明確指定服務的處理策略。
  3. 再放私有網段與地區 IP 規則。具體順序取決於是否要讓網域策略優先於位址策略。
  4. 最後放 MATCH。為所有尚未符合其他規則的連線指定明確出口。

上述順序是常見的整理方式，並非核心強制規定。如果業務需求是「所有私網目標都必須直連」，就應將私網規則移到可能涵蓋這些目標的服務規則之前。要判斷順序是否正確，得先釐清各策略的業務優先級。

rules:
  - DOMAIN,blocked.example.com,REJECT
  - DOMAIN,api.example.com,節點選擇
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

在此清單中，blocked.example.com 會被拒絕；api.example.com 會交由節點選擇；www.example.com 則會直連。即使 API 解析出的位址符合後面的 GEOIP 條件，也不會再檢查該規則，因為網域規則已經符合。

MATCH 後面的普通規則不會執行

MATCH,節點選擇 沒有比對內容欄位，所有進入這一行的連線都會符合。若將它放在清單中間，後面的普通規則就會失效。也不要寫成 MATCH,*,節點選擇；出口就是第二個欄位。

規則符合後若連線失敗，核心通常也不會回頭嘗試下一條規則。若需要節點故障切換，應在策略組中設定相應的選擇機制，而不是在 rules 中重複撰寫相同網域並指定多個出口。

rule-providers：定義規則集，再以 RULE-SET 引用

rule-providers 用來宣告規則集來源，RULE-SET 則用來將規則集加入比對清單。只有宣告規則集不會自動參與分流。以下以 mihomo 的本機檔案規則集為例，規則檔採用經典規則格式：

rule-providers:
  office-services:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/office-services.yaml

rules:
  - DOMAIN,api.example.com,節點選擇
  - RULE-SET,office-services,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

將以下內容儲存至核心工作目錄對應的 rules/office-services.yaml。相對路徑的基準取決於用戶端啟動核心時使用的工作目錄，不一定是下載目錄；檔案也必須放在該用戶端允許核心存取的位置。

payload:
  - DOMAIN-SUFFIX,example.org
  - DOMAIN,intranet.example.com
  - IP-CIDR,10.20.0.0/16

此處的 payload 項目不需填寫 DIRECT 或策略組名稱，出口會由引用處的 RULE-SET,office-services,DIRECT 統一指定。一般設定中的 rules 與規則集檔案中的 payload 結構不同，兩者不能直接互換。

behavior內容格式適用範圍
classicalDOMAIN-SUFFIX,example.org 等含類型的項目適合混合使用網域與 IP 條件
domain專用網域比對項目不要貼上以 DOMAIN-SUFFIX, 為前綴的經典格式項目
ipcidr10.20.0.0/16 等位址範圍不要混入網域或出口策略

RULE-SET 在 rules 中的位置就是它的優先級。放在 MATCH 後面不會生效；放在精確例外之前，則可能先攔截原本要套用例外的連線。頂層的 rule-providers 寫在 rules 前或後，不會影響比對優先級。

若使用遠端 HTTP 規則集，interval: 86400 表示該 provider 每隔 86400 秒，也就是 24 小時更新一次。這與訂閱設定的更新週期、代理節點清單的更新週期不同。本文採用本機檔案範例，因此不設定 HTTP 更新參數。

用戶端設定：覆寫、重新載入與連線驗證

直接編輯訂閱檔案後，下次更新訂閱時可能會還原原有內容。若要長期保留自訂規則，建議優先使用用戶端的覆寫、合併設定或腳本功能，並確認最終產生的 rules 順序。不同用戶端處理陣列的方式可能是整份取代，也可能提供插入至前方或後方的選項；不能只看編輯器中的內容就判定最終結果。

依最終生效的設定檢查，不要只看編輯內容

  1. 記下目前的用戶端與核心版本。在用戶端的「設定」或「關於」頁面確認執行的是 mihomo 或其他核心，避免直接在舊版核心中使用新語法。
  2. 在「設定檔」頁面選取目前使用的訂閱，再進入該設定檔的編輯或覆寫介面。選單名稱會隨用戶端版本而異；儲存後還要重新載入或套用設定。
  3. 確認最終生效的設定中只有一個頂層 rules:，並確保新增的例外規則排在訂閱產生的 MATCH 之前。
  4. 切換至「規則 / Rule」模式，在「連線 / Connections」中開啟目標連線的詳細資訊，查看命中規則、規則內容與策略鏈。

建立一筆新連線來驗證規則

既有的 TCP 連線通常會繼續使用建立連線時選定的出口。修改規則後，請關閉相關舊連線，或結束應用程式後重新發出請求，避免瀏覽器重用連線而造成誤判。以下指令僅適用於最終設定確實使用 mixed-port: 7890，且監聽位址允許本機存取的情況：

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

在 Windows 上使用 curl.exe 可明確呼叫 curl 程式。此處會明確指定 HTTP 代理，不必依賴瀏覽器是否讀取系統代理；7890 是測試範例連接埠，並非所有用戶端預設使用的連接埠。執行後，請在連線頁面搜尋 example.com，以符合的規則和策略鏈為準，不要只根據網頁能否開啟來判斷分流是否正確。

常見錯誤與排除方向

  • 設定解析失敗：檢查縮排是否使用空格、清單項目是否以 - 開頭，以及是否誤用了全形逗號。不要重複新增同名的頂層鍵。
  • 找不到策略：逐字比對規則第三個欄位與實際策略組名稱，尤其要確認訂閱更新後策略組是否已更名。
  • 規則集載入失敗：確認 provider 名稱、檔案路徑、behavior 與檔案內容，並檢查 payload 的縮排是否正確。
  • 一直符合 MATCH：檢查連線詳細資訊中是否有網域資訊、目標是否已變成其他主機名稱，以及規則是否確實寫入最終設定。
  • 連線頁面沒有紀錄：先確認應用程式是否使用代理，或流量是否由 TUN 接管；流量若尚未進入核心，調整規則順序也無法解決問題。

需要確認設定欄位時，可參閱協定參考；不確定策略組、系統代理與 TUN 的差異時，可先閱讀名詞解釋。維護規則時，重點是讓例外清楚、出口有效，並確保 MATCH 始終放在兜底位置。

下載 Clash依作業系統選擇安裝檔