Clash 中國大陸與海外規則分流設定：策略組、規則集與兜底順序實戰

Clash 的規則分流並不是簡單地把「中國大陸網域」設為直連、把「海外網域」交給代理。真正決定連線去向的是三層結構：規則負責識別流量，策略組負責選擇出口，代理節點或內建動作負責執行。任何一層的名稱、順序或引用關係不一致，都可能表現為網站走錯線路、區域網路服務被代理、應用程式連線逾時，或切換節點後部分連線仍沿用舊路徑。

以下設定思路適用於支援規則模式的 Clash 客戶端，也適用於以 Clash Meta 名義流傳、目前通常稱為 mihomo 的核心。不同客戶端的圖形介面名稱可能不同，核心版本對規則類型、規則集格式與程序比對能力也有差異。修改前應確認客戶端實際使用的核心，並保留一份能正常啟動的設定。

先確定直連、代理、攔截與兜底模型

一份便於維護的中國大陸與海外分流設定，至少要明確四種處理結果。第一類是 DIRECT，連線直接交給本地網路；第二類是自訂代理策略組，例如 PROXY；第三類是 REJECT，用於阻擋確定不需要存取的網域或網段；第四類是最終兜底策略，用來接收前面所有規則都未命中的流量。

DIRECT 並不等同於「中國大陸」。區域網路位址、印表機、路由器管理頁面與公司內部系統通常需要直連，但某些中國大陸服務可能因帳號區域、辦公出口或測試需求而指定代理。反過來，部分海外網站也可能透過目前的網路直接存取。因此，地域規則適合負責大範圍的基礎判斷，業務例外應放在地域規則之前。

用策略組隔離節點選擇與業務意圖

在規則中直接填寫單一節點名稱可以運作，但維護成本較高。訂閱更新後節點名稱可能改變，多條規則也可能重複綁定同一個具體節點。更穩定的方式是讓規則引用語意明確的策略組，再由策略組選擇節點、自動測速組或其他策略組。

常見結構包括總入口 PROXY、自動測速組 AUTO、手動選擇組，以及按業務劃分的媒體、辦公或開發服務組。業務規則只指向業務策略組，節點調整則在組內完成。如此既能維持規則檔穩定，也能在客戶端介面中暫時切換出口。

mode: rule

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - MANUAL
      - DIRECT

  - name: AUTO
    type: url-test
    use:
      - airport
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

  - name: MANUAL
    type: select
    use:
      - airport

上例中的 airport 必須已在 proxy-providers 中定義。use 引用的是代理提供器，不是規則提供器。url-test 會根據測試結果選擇符合條件的節點，但延遲最低不代表所有業務的吞吐量最高；若目標服務對出口地區有要求，應建立地區組或手動選擇組，不要只依賴全域測速結果。

允許 PROXY 選擇 DIRECT，方便臨時診斷，但也代表使用者切換該組後，所有引用它的規則都會改變出口。對必須固定代理的業務，可單獨建立不包含 DIRECT 的策略組。對必須直連的流量，則讓規則直接指向 DIRECT，避免受到總策略組切換影響。

策略組名稱必須維持單一寫法

YAML 中的名稱會區分字元內容。規則寫成 PROXY，策略組卻命名為 Proxy，不會被視為同一個目標。中文名稱、空格與符號通常可以使用，但在不同客戶端之間移轉時，簡短的英文大寫名稱更便於檢查。若名稱包含特殊字元，建議使用引號，並在規則、策略組與腳本引用中保持一致。

規則集訂閱與策略組的搭配方式

rule-providers 用於宣告可重複使用的規則集。它與節點訂閱負責不同工作：節點訂閱提供代理伺服器資訊，規則集提供網域、IP 網段或經典規則項目。規則集本身不決定出口，只有在 rules 中透過 RULE-SET 引用，並指定 DIRECT、PROXY 或其他策略後，才會參與連線決策。

rule-providers:
  reject-list:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/reject.yaml
    url: https://example.com/rules/reject.yaml
    interval: 86400

  cn-domain:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/cn-domain.yaml
    url: https://example.com/rules/cn-domain.yaml
    interval: 86400

  cn-ip:
    type: http
    behavior: ipcidr
    format: yaml
    path: ./ruleset/cn-ip.yaml
    url: https://example.com/rules/cn-ip.yaml
    interval: 86400

範例網址僅用於展示欄位結構，實際設定應使用規則維護方提供的原始檔案網址。path 是規則集的本機快取位置；客戶端必須對相應目錄具備寫入權限。interval 通常以秒為單位，設定為一天可以減少頻繁請求。規則更新頻率應配合上游維護節奏決定，過短的間隔不會提高比對精確度。

behavior 決定規則集內項目的解讀方式。domain 適合網域及網域後綴集合，ipcidr 適合 IPv4、IPv6 網段，classical 則可容納帶有類型的經典規則。檔案內容必須與宣告的行為和格式相符。把網域清單宣告成 ipcidr，或把經典規則檔當作純網域集合讀取，通常會觸發解析失敗，或導致規則無法命中。

規則順序：從具體例外到範圍兜底

Clash 會按照清單由上而下檢查規則，第一條命中的規則會立即決定處理策略。它不會比較所有規則後再選擇「最精確」的一條。因此，順序設計應遵循「具體例外在前、寬泛集合在後、最終兜底位於末尾」的原則。

建議的基礎順序是：明確攔截項目、區域網路與私有位址、必須直連的業務、必須代理的業務、中國大陸網域集合、中國大陸 IP 集合、其他地區或代理集合，最後是 MATCH。具體專案可以調整分類，但不能把寬範圍規則放在它應覆蓋的例外之前。

rules:
  - RULE-SET,reject-list,REJECT
  - DOMAIN-SUFFIX,internal.example,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve

  - DOMAIN-SUFFIX,service-needs-proxy.example,PROXY
  - DOMAIN-SUFFIX,service-needs-direct.example,DIRECT

  - RULE-SET,cn-domain,DIRECT
  - RULE-SET,proxy-domain,PROXY
  - RULE-SET,cn-ip,DIRECT,no-resolve
  - GEOIP,CN,DIRECT,no-resolve

  - MATCH,PROXY

上例中的業務網域同樣用於說明順序，部署時應替換為實際需要控制的網域。若「必須代理」的網域同時存在於中國大陸網域規則集，它必須放在 cn-domain 之前，否則會先命中直連。若某個攔截規則範圍過寬，登入介面、靜態資源或驗證碼網域可能先被拒絕，即使後面存在代理規則也不會繼續判斷。

DOMAIN 比對完整網域，DOMAIN-SUFFIX 比對指定網域及其子網域，DOMAIN-KEYWORD 只檢查網域中是否包含關鍵字。關鍵字規則的覆蓋範圍大，容易誤傷名稱相似但業務無關的網站，通常應優先使用完整網域、後綴或經過維護的規則集。

IP-CIDR 與 GEOIP 屬於 IP 維度判斷。附加 no-resolve 可以避免規則為取得目標 IP 而主動觸發額外解析，但也代表該規則只有在核心已取得目標 IP 時才會參與比對。是否加入此參數，應配合 DNS 模式、連線中繼資料與核心行為進行驗證，而不是機械式地套用到每條規則。

MATCH 應該直連還是代理

兜底去向取決於設定目標。針對「中國大陸直連、其他流量代理」的常見模型，可使用 MATCH,PROXY，讓新出現且尚未納入規則集的網域先進入代理策略。若環境要求預設直連，僅少數業務使用代理，則可使用 MATCH,DIRECT，但必須確保需要代理的規則覆蓋完整。兩種模式沒有通用的優劣，關鍵在於未知流量出現時，哪種風險更可控。

DNS 與 TUN 模式對分流結果的影響

規則順序正確但存取結果仍異常時，需要檢查 DNS。網域請求、解析結果與實際連線可能經過不同路徑。如果系統 DNS 回傳受網路環境影響的位址，網域規則雖然命中了預期策略，後續連線仍可能逾時。使用 Clash 內建 DNS 時，應確認 nameserver、proxy-server-nameserver、回退解析與規則分流之間的關係，並從核心日誌觀察查詢實際交給了哪台伺服器。

在 fake-ip 模式下，核心會向應用程式回傳保留位址，並在連線階段根據映射還原目標網域。這有利於網域規則穩定參與判斷，但部分區域網路設備、區域網路網域、遊戲平台或依賴真實 IP 的應用程式可能需要加入 fake-ip-filter。過濾項目不應無限擴大；範圍過大時，越來越多請求會退回真實 IP 解析，網域分流的一致性也會降低。

redir-host 模式會直接向應用程式回傳真實解析位址，與 fake-ip 的相容路徑不同。切換模式後，舊 DNS 快取與既有連線可能仍然存在，因此測試前應中斷相關應用程式的連線，並依作業系統情況清除 DNS 快取。僅重新整理瀏覽器頁面不一定會重新建立完整鏈路。

TUN 模式負責接管更多系統流量，但不會改變規則由上到下比對的基本邏輯。啟用 TUN 後，原本繞過系統代理的應用程式也可能進入 Clash，因此規則命中數量會增加。如果應用程式只提供目標 IP，網域規則可能缺少可用的中繼資料；支援嗅探的核心可以從部分 HTTP 或 TLS 流量還原主機資訊，但嗅探並非對所有協定都有效。

遇到「瀏覽器分流正常，但命令列或桌面應用程式走錯線路」時，應依序確認該程式是否進入核心、TUN 路由是否生效、網域是否被識別，以及最終命中了哪條規則。不要只根據網頁顯示的出口位址判斷整個系統，因為不同程序可能使用系統代理、直連 socket、QUIC 或獨立 DNS。

依連線日誌驗證，而不是憑存取結果猜測

分流設定完成後，最有效的驗證方式是查看客戶端連線面板或核心日誌。每次測試都應記錄目標主機、命中規則、選擇的策略組、實際節點與連線結果。只看到「能開啟」不能證明規則正確：目標可能支援直連，也可能使用快取、備用網域或已建立的長連線。

1. 確認設定已載入。查看設定更新時間與核心日誌，排除 YAML 縮排、欄位拼寫、規則集下載或策略組引用錯誤。
2. 固定測試策略。暫時為 PROXY 選擇一個狀態明確的節點，避免自動測速組在測試過程中切換出口。
3. 測試區域網路與私有位址。確認路由器管理頁面、區域網路設備及內部網域命中 DIRECT，並檢查 TUN 是否錯誤接管保留網段。
4. 測試中國大陸網域與 IP。觀察命中的是網域規則集、IP 規則集還是 GEOIP。若直接落到 MATCH，表示需要檢查規則集內容或網域識別路徑。
5. 測試強制代理例外。確認它位於中國大陸大型集合之前，並實際命中指定策略組，而不是被前面的後綴規則提前攔截。
6. 測試未知網域。選擇不在自訂規則中的目標，確認最終由 MATCH 接收，藉此驗證兜底策略。

常見現象與對應檢查點

維護長期設定時，建議將自訂例外、公共規則集與兜底規則分開管理。自訂例外通常數量較少，應放在主設定中並附上用途說明；公共網域與 IP 集合交由規則提供器更新；兜底策略則保持固定。規則出現問題時，就能快速判斷是本機例外、遠端集合還是出口策略發生變化。

每次修改只調整一個層面。先驗證策略組能夠連線，再驗證規則集能夠載入，最後調整規則順序。一次同時修改 DNS、TUN、規則提供器與策略組，會讓日誌中出現多個變數，難以定位真正原因。需要進一步了解設定欄位與客戶端操作時，可搭配進階設定文件和使用教學逐項核對。