跳至正文
進階設定 閱讀時間約 12 分鐘

Clash 規則設定教學：DOMAIN-SUFFIX、IP-CIDR 比對順序與 MATCH 最後兜底

Clash 規則依序比對，符合第一條就停止。本文說明 DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、IP-CIDR、GEOIP、MATCH 的語法、no-resolve 用途與排序原則。

規則沒有生效？先確認流量是否進入規則模式

替網站新增直連規則，連線卻仍走代理；將某個網段設為代理，連線結果卻沒有變化。問題未必出在語法。先確認應用程式的流量有經過 Clash，再確認核心使用規則模式，最後才檢查規則內容。

  1. 在用戶端的「代理模式」中選擇「規則（Rule）」。不同用戶端也可能顯示為「規則模式」；請勿在「全域（Global）」或「直連（Direct）」模式下測試分流規則。
  2. 開啟「連線（Connections）」頁面，再次造訪目標網站。若看不到新連線，請先檢查系統代理、應用程式本身的代理設定，或 TUN 接管範圍。
  3. 確認目前選用的設定檔確實是剛修改的那份。儲存檔案後，還需要讓用戶端重新載入設定；只儲存檔案不一定會更新正在執行的核心。
  4. 關閉目標應用程式的舊連線後再測試。規則主要在建立連線時決定出站方式；檔案變更不會讓已建立的長連線自動重新分流。

規則的組成：類型、比對值與出站策略

常見規則會寫在 YAML 的 rules: 清單中，每行以連字號開頭。網域規則通常包含三個欄位：規則類型、比對值、出站策略。MATCH 不需要比對值；支援 no-resolve 的 IP 類規則還可以加上第四個欄位。

rules:
  - DOMAIN,login.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,REJECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,DIRECT

這段設定只使用內建策略，方便檢視結構：DIRECT 表示直連，REJECT 表示拒絕連線。實際需要代理時，最後一個欄位應填入設定檔中已存在的代理節點名稱或策略群組名稱。PROXY 並非所有設定檔都通用的內建策略。若沒有同名節點或策略群組，直接照抄可能導致設定檔載入失敗。

  • 請使用英文半形逗號，不要使用中文逗號。
  • YAML 縮排請使用空格，不要使用 Tab；同一清單中的規則請保持相同縮排。
  • 策略名稱必須與定義完全一致，包括大小寫、空格與符號。
  • 修改現有設定時，請將項目合併到原本的 rules: 底下，不要再新增同名的頂層索引鍵。

網域規則：DOMAIN、DOMAIN-SUFFIX 與 DOMAIN-KEYWORD

類型範例比對範圍
DOMAINDOMAIN,example.com,DIRECT只比對 example.com，不包含 www.example.com。
DOMAIN-SUFFIXDOMAIN-SUFFIX,example.com,DIRECT比對 example.com 本身，以及 www.example.com、api.example.com 等子網域。
DOMAIN-KEYWORDDOMAIN-KEYWORD,example,REJECT比對網域中含有 example 字串的連線，適用範圍比後綴規則更廣。

後綴依網域邊界比對，不是比對任意字串結尾

DOMAIN-SUFFIX,example.com,DIRECT 會比對 a.example.com，但不會比對 notexample.com 或 example.com.other.org。通常不必寫成 *.example.com；後綴類型本身就包含子網域。

規則值只填網域，不要加上 https://、連接埠或路徑。造訪 https://example.com:8443/account 時，網域欄位仍是 example.com。一般網域規則無法區分同一網站的 /account 與 /video 頁面路徑。

精確例外要排在範圍較廣的規則之前

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

此處允許 login.example.com 直連，其餘屬於 example.com 的網域則拒絕連線。若調換前兩行，登入網域會先符合後綴規則，後面的精確規則就沒有機會生效。核心不會比較哪條規則「比較精確」，也不會在符合後繼續尋找更適合的選項。

DOMAIN-KEYWORD 適合清楚掌握比對範圍的情境，不適合用常見短字串為整類服務分流。關鍵字越短，越容易誤擋網域名稱中剛好含有相同字串的其他網站。

IP-CIDR 與 GEOIP：網段和地區資料庫並不相同

IP-CIDR 用來判斷目標 IPv4 位址是否屬於指定網段。192.168.0.0/16 涵蓋 192.168.0.0 至 192.168.255.255；/32 則只代表一個 IPv4 位址。IPv6 網段使用 IP-CIDR6，單一 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,代理選擇

GEOIP,CN,DIRECT 表示依據目前載入的 IP 地區資料庫，判斷目標位址是否屬於 CN，再選擇直連。這不代表「所有中文網站都直連」，也不會依網頁語言或網域後綴判斷。CDN 位址配置、資料庫更新，以及 IPv4／IPv6 回應差異，都可能讓同一網站在不同網路環境下符合不同結果。

如果某項服務必須固定使用特定策略，建議優先設定明確的網域規則。將地區規則放在較後面作為補充，通常更容易維護。若無法載入所需的地區資料庫，請先處理用戶端記錄中的資源載入問題，而非調整規則順序來掩蓋錯誤。

no-resolve 的用途：不為這條規則額外解析網域

連線帶有網域、而規則需要目標 IP 時，核心可能會為了執行 IP 比對而發出 DNS 查詢。no-resolve 用來避免這條 IP 規則主動觸發網域解析。它不是全域 DNS 開關，也不代表「略過這條 IP 規則」。

  • 目標本身就是 IP：可直接判斷位址是否屬於該網段，即使帶有 no-resolve 仍可能符合。
  • 連線已有可用的目標 IP：仍可能進行比對，不能將此參數理解為「網域連線一定會略過」。
  • 只有網域，沒有可用的目標 IP：不會只為這條規則額外解析網域，因此可能會繼續檢查後續規則。
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,代理選擇

這組規則會先處理明確的網域，再檢查私有網路位址，接著判斷地區。請注意：第二條雖然加上 no-resolve，第三條卻沒有，仍可能為了地區比對而觸發解析。只替單一規則加上參數，不會限制後續所有規則的 DNS 行為。

若將第三條改為 GEOIP,CN,DIRECT,no-resolve，只有網域且沒有可用目標 IP 的連線，可能無法在此完成地區判斷，接著會落到代理兜底。是否加入此參數，應依預期分流結果與 DNS 路徑決定，不要只為減少查詢就一律加上。

MATCH 兜底與由上而下的排序原則

MATCH 是無條件比對，格式為 MATCH,策略名稱。通常放在規則清單最後，接住所有前面未處理的連線。不要寫成 MATCH,*,策略名稱，也不要把它放在仍有有效規則待執行的位置之前。

rules:
  - DOMAIN,login.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,代理選擇
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,代理選擇

透過三次連線測試確認規則順序

  1. 造訪 login.example.com：符合第一條規則後就停止搜尋，使用 DIRECT。
  2. 造訪 static.example.com：不符合第一條，符合第二條後交由「代理選擇」策略群組處理。
  3. 造訪不屬於上述網域、且目標位址未符合 IP 與地區規則的服務：最後由 MATCH 交給「代理選擇」處理。

以上是依設定推導出的結果，不代表範例網域提供可連線的服務。實際測試時，請換成自己要分流的真實目標。也請留意，符合策略群組不代表一定會走遠端節點：若該群組目前選擇 DIRECT，最後仍會直連。

實用的排序方式通常是：精確例外、明確的網域範圍、其他業務規則或規則集、IP 與地區補充規則、最終兜底。這並非核心強制規定；如果業務需求是讓某條拒絕規則優先於例外，就應將它往前移。重點是掌握每條規則會涵蓋哪些後續項目，而不是一味依規則類型分類。

訂閱與規則集：內容要修改，位置也要放對

訂閱更新後自訂規則消失，通常是因為修改了會被重新下載覆蓋的訂閱檔案。請先保留原設定，再使用用戶端提供的覆寫、合併或擴充設定功能。各用戶端的操作位置與合併格式不同，不要把特定用戶端的擴充欄位當成 Clash 核心通用設定。

RULE-SET 的位置也會影響比對結果

在支援的 Clash 核心版本與 mihomo 中，規則提供者通常定義於 rule-providers:，並透過 RULE-SET,提供器名稱,策略名稱 引用。引用的項目也會依同一套由上而下的順序比對：若前面已符合範圍較廣的網域規則，就不會再檢查後面的規則集。

  • behavior: domain 的內容應依網域集合格式撰寫，不要直接放入完整的三欄位出站規則。
  • behavior: ipcidr 的內容是 IP 網段，適合用來建立位址範圍集合。
  • behavior: classical 使用規則條件格式，最終出站策略則由引用它的 RULE-SET 項目指定。

原版 Clash、不同歷史分支與 mihomo 的規則類型及擴充欄位並不完全相同。若出現 unsupported rule type 等提示，請先查看用戶端的「關於」頁面或核心資訊，確認實際執行的核心，再查閱對應文件。升級介面程式不代表核心也已切換。

驗證規則：每次只修改一項，檢查符合的規則與最終出站

  1. 先備份並儲存。保留一份能正常啟動的設定檔，只新增一條精確網域規則，重新載入後確認是否出現解析錯誤。
  2. 清除舊連線。關閉目標應用程式，或在用戶端的「連線」頁面中結束對應連線，再重新送出要求。瀏覽器透過 HTTP/2、HTTP/3 重複使用連線，可能讓舊路徑持續存在。
  3. 確認目標資訊。在連線詳細資料中檢查網域、目標 IP、符合的規則與策略鏈。不同用戶端的欄位名稱可能略有差異，不能只看總流量圖表。
  4. 檢查記錄。必要時可暫時將 log-level 設為 debug，重現一次問題後再恢復為 info。分享記錄前，請遮蔽訂閱連結、權杖及不宜公開的位址。
狀況優先檢查項目
一直符合 MATCH規則是否已載入、網域是否拼錯、連線是否只帶有 IP，以及規則集是否載入成功。
精確規則未符合前面是否有涵蓋該目標的後綴規則、關鍵字規則或規則集；測試連線是否在修改前就已建立。
符合代理群組，連線卻仍直連確認該策略群組目前選擇的項目是否為 DIRECT，以及巢狀群組的最終選擇。
網域規則對部分應用程式無效連線是否沒有網域資訊、應用程式是否自行解析，以及系統代理或 TUN 是否實際接管該應用程式。
訂閱更新後設定又恢復原狀確認修改的是訂閱原始檔還是可持續保留的覆寫設定；自訂項目是否合併在範圍較廣的規則之後。

若流量只有目標 IP，網域規則可能缺乏比對依據。mihomo 的 Fake-IP 對應、DNS 接管與嗅探設定會影響網域資訊是否可用，但嗅探不保證能識別所有協定，更無法還原所有加密連線中的真實網域。請先查看連線詳細資料，再決定是否調整 DNS 或嗅探設定，避免同時修改多個環節。

Clash 安裝檔