規則分流 預計閱讀 10 分鐘

Clash 規則分流實作：搭配 GEOIP 與 DOMAIN-SUFFIX 設定中國大陸與海外流量分流

透過實際規則示範中國大陸直連、海外流量走代理的設定，說明規則順序、MATCH 兜底與 rule-provider 維護。

先確認：連線已進入核心，模式設為 Rule

中國大陸與海外流量分流，不是看軟體介面上的節點名稱來判斷，而是讓每條進入核心的連線，依網域、目標 IP 等條件選擇出口。本文採用「明確指定的網域優先直連、中國大陸 IP 直連，其餘連線交由代理群組」的做法。這裡所說的中國大陸與海外，是路由策略的簡稱，不代表能準確辨識網站的註冊地、營運主體或內容所屬地區。

Clash for Windows 原專案已停止維護。若仍在使用舊環境，可參考基本規則語法；建立新設定檔時，建議先到客戶端選型確認維護狀態與核心功能。下文的基本規則適用於常見 Clash 設定，規則集範例則以 mihomo 為執行環境；不要將現代核心的功能視為舊版 CFW 必定具備的能力。

  1. 在 Clash for Windows 的 General → System Proxy 開啟系統代理，讓遵循 Windows 代理設定的程式透過客戶端連線。不遵循系統代理設定的程式，則需要個別設定代理，或使用已正確設定的 TUN。
  2. 進入 Proxies → Rule，確認執行模式為規則模式。Global 會將所有連線交由全域策略處理，Direct 則會直接連線，兩者都不適合用來驗證本文的規則。
  3. 在 Profiles 確認目前啟用的設定檔，再檢查其中是否已有代理策略群組。本文以 PROXY 作為現有代理群組的名稱，實際使用時必須改成設定檔中的名稱。

DOMAIN-SUFFIX、GEOIP 與 MATCH 各自負責一層

Clash 規則通常由上而下比對，遇到能確定出口的規則後就會停止搜尋。不要把規則列表當成會自動比較「哪條更精確」的清單。若先寫較寬泛的規則，後面的精確例外可能就沒有機會執行。

寫法比對對象注意事項
DOMAIN,example.com,DIRECT完整網域名稱不包含 www.example.com。
DOMAIN-SUFFIX,example.com,DIRECT根網域及其子網域符合 example.com 與 a.example.com，不符合 notexample.com。
GEOIP,CN,DIRECT目標 IP 在 GeoIP 資料中的歸屬地依賴本機資料；不代表網站屬於中國公司。
MATCH,PROXY前面尚未決定出口的連線應放在最後；PROXY 必須是已存在的代理或策略群組。

網域規則不可寫成網址

DOMAIN-SUFFIX 後面只填網域，不要加上 https://、連接埠或路徑。例如要讓支付寶相關網域直連，可以寫成 DOMAIN-SUFFIX,alipay.com,DIRECT，不能填入完整網址。這條規則也不會判斷 URL 中的 /login 或 /video 路徑。

網域後綴也不是地理界線。不能把所有 .com 網域都當成海外，也不宜單靠 .cn 判斷伺服器的實際位置。常用服務以明確的網域規則處理，其餘目標再依 IP 歸屬判斷，通常會更容易檢查與維護。

基本設定：先處理例外，再用 GEOIP，最後設兜底

以下是主設定檔中的片段，不是含有節點的完整訂閱。使用前請先備份目前的設定，並確認有名為 PROXY 的代理群組。合併時保留原有節點、DNS 與連接埠設定；若頂層已有 rules:，請編輯原本的列表，不要再新增第二個同名鍵。

mode: rule

rules:
  # 本機與常見區域網路 IPv4 位址
  - DOMAIN,localhost,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - 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

  # 本機與區域網路 IPv6 位址
  - IP-CIDR6,::1/128,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - IP-CIDR6,fe80::/10,DIRECT,no-resolve

  # 依實際需求新增明確的網域策略
  - DOMAIN-SUFFIX,baidu.com,DIRECT
  - DOMAIN-SUFFIX,qq.com,DIRECT
  - DOMAIN-SUFFIX,alipay.com,DIRECT
  - DOMAIN-SUFFIX,wikipedia.org,PROXY

  # 未經網域規則處理的中國大陸 IP 直連
  - GEOIP,CN,DIRECT

  # 其餘連線交由現有代理群組
  - MATCH,PROXY

這個順序會先讓區域網路目標直連，再處理明確的網域例外。接著由 GEOIP,CN,DIRECT 進行較廣泛的 IP 歸屬判斷，最後用 MATCH 接住其餘連線。範例網域僅示範寫法，並非完整的中國大陸服務清單；同一個應用程式可能還會使用不同的圖片、登入、付款與更新網域。

為什麼不把 GEOIP 放在所有網域規則之前

假設某個服務網域需要固定走代理，但目前解析出的 IP 被 GeoIP 資料判定為 CN。若先設定 GEOIP 直連，後面的網域代理規則可能就不會生效。反過來說，先處理明確的服務需求，再用地理資料補充判斷，就能保留例外規則。

區域網路網段也應符合實際網路環境。範例包含 172.16.0.0/12，而不是整個 172.0.0.0/8。不要為了少寫幾行，就把可能包含公網位址的整段網段都設為直連。上述規則只負責選擇出口，不會自動修復 TUN 路由、網卡優先順序或防火牆封鎖問題。

GEOIP 後面的 no-resolve：少一次解析，也可能少一次命中

排查分流問題時，常會看到兩種寫法：GEOIP,CN,DIRECT 與 GEOIP,CN,DIRECT,no-resolve。差別不在地理資料庫，而在比對這條規則時，是否允許主動解析網域以取得目標 IP。

  • 不加 no-resolve：對於仍需目標 IP 才能判斷的網域連線，核心可以進行解析，再依結果查詢 GeoIP。上方的基本範例採用這種寫法，較容易涵蓋未列入網域清單的中國大陸服務。
  • 加上 no-resolve：這條規則不會為了比對而主動觸發網域解析。如果目前的連線情境中沒有可用的真實目標 IP，連線就可能繼續套用後面的 MATCH。
  • 已取得 IP：直接連線至 IP，或核心在目前的連線情境中已有可供比對的位址時，仍可能符合帶有 no-resolve 的 IP 類規則。實際情況應查看連線詳細資訊，不要只根據設定檔內容推測。

因此，不能在 GEOIP 加上 no-resolve 後，還期待它完整接住所有未列出的中國大陸網域。若想盡量減少為分流而觸發的解析，就應先維護足夠完整的網域規則，並接受部分未知網域會落入代理兜底。

fake-ip 不等於網站的真實位址

啟用 fake-ip 時，應用程式可能會看到 198.18.0.0/16 範圍內的映射位址。這是核心用來對應網域的虛擬位址，不是網站的實際所在地。不要把整個 fake-ip 位址池設為直連來「修復 GEOIP」；應查看核心還原出的網域、實際解析資訊與命中規則。DNS 設定也應符合所用的核心與客戶端版本，詳情請參閱設定參考。

rule-providers：將常用網域規則拆分成易維護的檔案

規則從十幾條增加到幾百條後，繼續把所有網域都塞進主設定檔，會讓檢查變得困難。rule-providers 用來宣告規則來源，RULE-SET 則在主規則列表中引用規則集。以下採用 mihomo 支援的本機檔案規則集，避免把遠端規則下載、定期更新與基本分流問題混在一起排查。

第一步：在主設定檔中宣告並引用

將需要維護的網域移至規則集後，使用下方的宣告與規則列表取代主設定檔中相對應的部分。local-direct 是自訂的規則集名稱，引用時必須完全相同；原有的區域網路規則仍應保留在規則集之前。

rule-providers:
  local-direct:
    type: file
    behavior: classical
    path: ./rules/local-direct.yaml

rules:
  - DOMAIN,localhost,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - 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,::1/128,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - IP-CIDR6,fe80::/10,DIRECT,no-resolve
  - DOMAIN-SUFFIX,wikipedia.org,PROXY
  - RULE-SET,local-direct,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

第二步：建立規則集檔案

在核心工作目錄對應的 rules/local-direct.yaml 中儲存以下內容。相對路徑通常以核心工作目錄為基準，不一定是下載訂閱檔案所在的目錄；請以客戶端記錄檔與實際資料目錄為準。mihomo 對路徑存取設有限制，建議將檔案放在允許使用的資料目錄中。

payload:
  - DOMAIN-SUFFIX,baidu.com
  - DOMAIN-SUFFIX,qq.com
  - DOMAIN-SUFFIX,alipay.com

這裡的 behavior: classical 表示規則項目採用含規則類型的寫法。請注意，檔案內容結尾沒有 ,DIRECT：出口由主設定檔中的 RULE-SET,local-direct,DIRECT 指定。若改用 behavior: domain，規則項目的格式也必須跟著調整，不能只修改 behavior，卻保留原本內容。

本機檔案類型不會依遠端訂閱週期自動取得新內容。編輯後，請使用客戶端提供的設定重載或規則集重載功能，並檢查記錄檔是否成功讀取。若需要 HTTP 類型規則集，再設定可信任的來源、快取路徑與更新間隔；例如 interval: 86400 的單位是秒，代表一天，但來源格式仍必須符合 behavior 的設定。

訂閱更新與規則維護：先確認哪些設定會互相覆蓋

直接修改客戶端產生的訂閱設定，通常會在下次更新時被覆蓋。較穩妥的做法是保留原訂閱作為節點來源，並在客戶端支援的覆寫、合併或擴充設定層中維護自訂規則。不同客戶端的合併方式不盡相同：有些會取代整段 rules，有些則支援前置追加。不能只因為儲存成功，就認定規則順序正確。

  1. 先備份：儲存原始設定與目前可用的規則集檔案，並記下正在使用的設定名稱。
  2. 檢查最終設定：確認 mode: rule、代理群組名稱、規則順序與 rule-providers 宣告，都出現在實際執行的設定中。
  3. 手動更新一次訂閱：更新後重新檢查，不要等到隔天發現自訂規則消失才開始排查。
  4. 每次只修改一類內容：先驗證網域規則，再新增 GEOIP，最後拆分規則集。發生異常時，較容易找出是哪一層造成變化。

維護 GeoIP 資料與維護網域規則是兩件不同的事。更新 GeoIP 資料無法補上應用程式新增的網域；新增網域規則也無法修正過時的 IP 歸屬資料。資料庫名稱、下載方式與更新入口都取決於核心，不應直接把其他客戶端的檔名照搬到 CFW 目錄中。

驗證分流：查看命中規則，不要只看網頁能否開啟

儲存設定後，請先重新建立要測試的連線。既有的長連線通常不會因為修改規則就自動更換出口；瀏覽器重複使用連線也可能讓舊結果持續出現。可以先關閉相關連線再重試，接著開啟客戶端的 Connections 頁面，檢查目標網域、命中規則與代理鏈。各客戶端的欄位名稱可能略有不同。

驗證情境範例設定的預期結果發生異常時先檢查
造訪 www.baidu.com符合網域規則或 local-direct，出口為 DIRECT網域拼寫、規則集是否載入，以及前面是否已有攔截規則。
造訪 www.wikipedia.org符合網域規則，進入 PROXY 策略群組群組目前選擇的項目是否為代理節點，而非 DIRECT。
造訪實際的路由器位址，例如 192.168.1.1連線進入核心時，應符合區域網路直連規則若連線列表沒有記錄，可能是系統代理的略過清單直接放行了連線。
造訪未列入網域清單的公網目標先依 GEOIP 判斷，未命中則套用 MATCH目標解析位址、GeoIP 資料，以及是否設定了 no-resolve。

三個常見誤判

  • 看到 PROXY 就認為一定經過代理節點：PROXY 只是群組名稱；如果群組內選的是 DIRECT，最後仍會直連。請繼續檢查完整的代理鏈。
  • 網頁能開啟就認為所有資源都走相同路徑：主頁、圖片與登入介面可能連線至不同網域，請逐一檢查相關連線。
  • 連線列表沒有記錄就認為規則失效：程式可能根本沒有進入核心。請先確認系統代理或 TUN 是否已接管流量，再排查規則比對問題。

遇到網域分流錯誤時，依照「是否進入核心 → 執行模式 → 實際網域與 IP → 命中規則 → 最終出口」的順序檢查，通常比反覆切換節點更有效。基本方案穩定後，再逐步補齊服務網域與規則集；不要為了追求看似完整的規則列表，就同時加入多組來源不明、優先順序重疊的清單。

下載客戶端