規則分流 預計閱讀 14 分鐘

Clash 規則分流實戰：中國大陸直連、海外代理的完整設定指南

以中國大陸與海外分流為例，說明 GEOIP、GEOSITE 與規則集的搭配方式，提供可直接套用的策略組架構，並整理確認分流是否生效的排查步驟。

先確認分流目標：優先依網域判斷，再用 IP 補漏

「中國大陸直連、海外代理」不是把所有流量簡單分成兩個地區。Clash 實際處理的是連線請求，每個請求可能只帶有網域、只有目標 IP，或先經過 DNS 解析再建立連線。可靠的設定通常會先用網域規則辨識目標，再用 IP 所屬地規則補漏，最後以一條兜底規則處理未命中的流量。

以 Clash Meta，也就是目前常見的 mihomo 核心為例，一次連線會依照 rules 中的順序由上而下檢查。第一條命中的規則會立即決定該連線進入哪個策略組，後續規則不再執行。因此，規則類型是否齊全只是基礎，排列順序同樣會決定最終結果。

流量類別 建議動作 主要判斷依據 典型範例
區域網路與本機位址 DIRECT 私有網域、私有 IP 網段 192.168.1.1、10.0.0.0/8
明確的中國大陸網站 DIRECT GEOSITE 或網域規則集 中國大陸影音、支付、地圖服務
解析至中國大陸的 IP DIRECT GEOIP,CN 未收錄於網域資料庫的中國大陸服務
明確指定代理的服務 PROXY 獨立網域規則或規則集 需要固定經由代理的開發服務
其餘未命中的連線 PROXY MATCH 新網域、冷門網域、未知目標

為什麼不能只寫 GEOIP,CN

GEOIP,CN,DIRECT 只能在核心取得目標 IP 後判斷其所屬地區。如果連線仍處於網域匹配階段，或 DNS 使用 Fake-IP 模式，單靠 GEOIP 無法完整表達網域層級的分流。此外，CDN 節點的位置不一定等同於服務所屬地區：同一個網域可能因網路、時間與 DNS 結果不同，而回傳位於不同地區的 IP。

更穩妥的架構是「網域優先、IP 補漏」。先用 GEOSITE,cn,DIRECT 或中國大陸網域規則集處理已知網站，再用 GEOIP,CN,DIRECT 接住未收錄但解析至中國大陸位址的連線。如此既能減少不必要的 DNS 依賴，也能涵蓋只有 IP 的存取請求。

GEOIP、GEOSITE 與 RULE-SET 分別負責什麼

GEOIP：依目標 IP 的地區歸屬進行匹配

GEOIP 規則查詢的是 IP 位址與地區代碼之間的對應關係。常見寫法是 GEOIP,CN,DIRECT，意思是目標 IP 被識別為中國大陸位址時使用直連。它適合作為中國大陸流量的補漏規則，但不適合單獨負責所有網域分流。

rules:
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

no-resolve 參數表示匹配這條 IP 規則時，不為了取得目標 IP 而主動解析網域。例如 GEOIP,CN,DIRECT,no-resolve 可以避免規則匹配階段觸發額外 DNS 查詢；但當請求本身只有網域時，這條規則也可能無法命中。是否加入此參數，應配合前面是否已有完整的網域規則來判斷。

GEOSITE：依網域集合進行匹配

GEOSITE 是 mihomo 等核心支援的網域分類機制。GEOSITE,cn,DIRECT 會將 geosite 資料庫中歸入 cn 分類的網域交給直連策略。它不會根據網域目前解析出的 IP 來判斷，因此更適合表達「某項服務屬於哪一類網站」。

rules:
  - GEOSITE,private,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

GEOSITE 能否正常使用，取決於核心與地理資料檔案。舊版 Clash 核心、不同分支的用戶端，以及 mihomo 的資料模式並不完全相同。設定報出 unsupported rule type GEOSITE 時，不應繼續調整規則順序，而應先確認用戶端使用的核心類型，並在用戶端的核心或地理資料更新入口完成更新。

RULE-SET：將外部規則檔案接入主設定

當規則數量達到數百或數千條時，不適合全部堆放在主設定的 rules 下。rule-providers 可以定義獨立的規則檔案，再透過 RULE-SET 引用。如此便於更新、分組與檢查，也能避免每次維護規則時改動策略組與 DNS 設定。

rule-providers:
  cn-domain:
    type: file
    behavior: domain
    format: yaml
    path: ./ruleset/cn-domain.yaml

  direct-extra:
    type: file
    behavior: classical
    format: yaml
    path: ./ruleset/direct-extra.yaml

rules:
  - RULE-SET,direct-extra,DIRECT
  - RULE-SET,cn-domain,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

behavior: domain 適合只包含網域項目的規則集；behavior: ipcidr 用於 IP 網段；behavior: classical 可以保存 DOMAIN、DOMAIN-SUFFIX、IP-CIDR 等完整規則。規則檔案的行為類型必須與內容一致，否則可能載入失敗或項目無法匹配。

本機網域規則檔案可以寫成：

payload:
  - '+.bilibili.com'
  - '+.jd.com'
  - '+.taobao.com'
  - 'cn.bing.com'

這裡的 +.example.com 表示主網域及其子網域。若只需要匹配單一精確主機名稱，應寫完整網域，而不是使用後綴形式。修改檔案後還要在用戶端執行設定重新載入；只儲存檔案而不重新載入，正在執行的核心不會自動套用新規則。

可直接調整的策略組與規則骨架

以下設定採用一個主要代理組、一個自動測速組與一條兜底規則。節點名稱需要與訂閱實際提供的名稱一致。如果用戶端透過訂閱產生代理節點，通常應在訂閱覆寫或設定合併功能中加入策略組，而不是直接修改下次訂閱更新就會被覆蓋的暫存檔案。

mixed-port: 7890
mode: rule
log-level: info
allow-lan: false
external-controller: 127.0.0.1:9090

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - DIRECT
      - 香港節點
      - 日本節點
      - 新加坡節點

  - name: AUTO
    type: url-test
    proxies:
      - 香港節點
      - 日本節點
      - 新加坡節點
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

rules:
  - GEOSITE,private,DIRECT
  - GEOIP,private,DIRECT,no-resolve
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

mode: rule 是啟用規則分流的前提。如果用戶端目前處於 Global 模式，所有連線都會統一進入全域策略組；如果處於 Direct 模式，所有連線都會繞過代理。許多「規則沒有命中」的問題，實際原因只是執行模式沒有切換至 Rule。

url-test 會依指定網址定期測試節點延遲。範例中的 interval: 300 表示每 300 秒測試一次，tolerance: 80 表示目前節點與較快節點的延遲差超過 80 毫秒時，才會考慮切換。頻繁測速會增加連線與耗電量，桌面端設定為 300 至 600 秒通常更合適。

使用訂閱提供器時的策略組寫法

如果節點來自 proxy-providers，策略組可以透過 use 引用提供器，避免將每個節點名稱寫入主設定。以下結構假設設定中已存在名為 airport 的代理提供器：

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - DIRECT
    use:
      - airport

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

訂閱更新後，新節點會加入引用該提供器的策略組。若用戶端支援設定合併，建議將自訂規則與策略組放在覆寫檔案中；具體入口通常位於「設定」→「設定檔」→「覆寫」或「訂閱」→「設定編輯」。不同用戶端的選單名稱可能有所差異，但原則相同：保留原始訂閱，將本機分流邏輯作為獨立的合併層。

DNS 與 Fake-IP 對分流結果的影響

規則看似正確，但中國大陸網站仍經由代理時，DNS 是必須檢查的一層。Clash 接管 DNS 後，網域解析、規則嗅探與連線建立會互相配合。若系統 DNS、瀏覽器安全 DNS 與 Clash DNS 同時運作，部分請求可能繞過核心的網域判斷，最後只留下 IP 資訊。

mihomo 常用的 Fake-IP 設定如下。監聽連接埠 1053 可避免直接佔用系統的 53 連接埠，再由用戶端負責將系統 DNS 請求轉送至該監聽位址：

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - 'localhost.ptlogin2.qq.com'

Fake-IP 模式會先向應用程式回傳 198.18.0.0/16 範圍內的保留位址，再由核心保存 Fake-IP 與原始網域的對應關係。如此即使應用程式隨後連線的是 IP，核心仍能還原網域並執行 DOMAIN、GEOSITE 或網域規則集。不適合使用 Fake-IP 的區域網路裝置探索、印表機與部分登入元件，可以加入 fake-ip-filter。

為什麼瀏覽器安全 DNS 會干擾判斷

瀏覽器啟用獨立的 DoH 後，DNS 查詢可能會以 HTTPS 流量傳送至瀏覽器指定的解析服務。Clash 仍可代理這條 HTTPS 連線，但不一定能取得與系統 DNS 一致的後續服務網域對應。排查期間可暫時關閉瀏覽器的安全 DNS，或設定為「使用目前的服務提供者」，接著清除瀏覽器 DNS 快取並重新測試。

Windows 可先執行 ipconfig /flushdns 清除系統快取；Chromium 系瀏覽器需要完全關閉相關程序後再重新開啟，才能排除舊連線重複使用造成的誤判。修改 DNS 設定後，還應在用戶端執行「設定」→「重新載入」，再中斷並重新連線系統代理或 TUN。

系統代理與 TUN 模式該如何選擇

系統代理通常會將 HTTP 與 HTTPS 請求傳送至 mixed-port: 7890。遵循系統代理設定的瀏覽器、下載器與開發工具可以正常進入 Clash，但部分遊戲、命令列程式、商店應用程式，以及自行實作網路堆疊的軟體可能會繞過系統代理。

TUN 模式透過虛擬網路介面接管更廣泛的 TCP、UDP 與 DNS 流量，適合需要統一分流的桌面環境。mihomo 的基礎設定可以寫成：

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  strict-route: true
  dns-hijack:
    - any:53
    - tcp://any:53

stack: mixed 兼顧系統網路堆疊相容性與 UDP 處理；auto-route 會自動寫入路由；auto-detect-interface 用於識別目前的出口網卡；strict-route 可減少流量繞過 TUN 的情況。啟用 TUN 通常需要管理員權限，首次啟動還可能觸發虛擬網卡或網路擴充功能授權。

情境 建議模式 檢查重點
主要使用瀏覽器與遵循系統代理的軟體 系統代理 HTTP 代理是否指向 127.0.0.1:7890
命令列、商店應用程式、遊戲需要統一接管 TUN 管理員權限、虛擬網卡、路由表
只想驗證規則設定 先使用系統代理 減少路由與 DNS 劫持變數
啟用 TUN 後無法存取區域網路裝置 檢查 strict-route 與私有網段規則 GEOSITE,private、GEOIP,private

如何確認中國大陸直連、海外代理已經生效

第一步：確認執行模式與設定已重新載入

  1. 在用戶端首頁確認執行模式為 Rule 或規則模式。
  2. 進入「設定」→「目前設定」，確認啟用的是剛才編輯的檔案。
  3. 執行「設定」→「重新載入」；如果剛修改過 TUN，則先中斷連線再重新連線。
  4. 將記錄層級暫時設為 info，不必一開始就使用輸出量更大的 debug。

第二步：在連線清單檢查命中鏈路

開啟用戶端的「連線」或「Connections」頁面，分別存取一個中國大陸網站與一個需要代理的網站。中國大陸請求應顯示類似 GEOSITE,cn → DIRECT、RULE-SET,cn-domain → DIRECT 或 GEOIP,CN → DIRECT；其餘請求應顯示 MATCH → PROXY → 具體節點。

一個網頁通常會同時請求主網站網域、圖片 CDN、統計介面、登入介面與第三方資源，因此連線清單中同時出現 DIRECT 與 PROXY 不一定代表錯誤。判斷時應選取具體連線，核對目標網域、命中規則、策略組與最終節點，而不是只查看頁面所對應的主網域。

第三步：用命令列避開瀏覽器快取

在系統代理模式下，可以明確指定本機混合連接埠進行測試。以下兩個命令都會透過 127.0.0.1:7890 進入 Clash，接著由規則決定直連或代理：

curl -I --proxy http://127.0.0.1:7890 https://www.baidu.com
curl -I --proxy http://127.0.0.1:7890 https://www.google.com/generate_204

執行命令時同步觀察連線面板。第一個請求通常應命中中國大陸網域規則或中國大陸 IP 規則，第二個請求應進入 PROXY。HTTP 狀態碼只代表目標是否回應，真正的分流結論仍應以連線詳細資訊中的規則鏈路與最終策略為準。

常見異常與定位順序

中國大陸網站全部進入 PROXY

海外網站顯示 MATCH，但仍然無法存取

命中 MATCH,PROXY 只表示規則選擇正確，不代表策略組中的節點可用。繼續展開連線鏈路，確認 PROXY 最終選中了哪個節點。若停在 DIRECT，表示策略組被手動切換為直連；若已選取節點但連線逾時，則應檢查節點狀態、訂閱更新，以及節點是否支援目標協定。

規則檔案更新後沒有變化

啟用 TUN 後無法存取區域網路裝置

先確認私有位址規則位於其他廣泛規則之前，並涵蓋常見網段。常見私有位址包括 10.0.0.0/8、172.16.0.0/12 與 192.168.0.0/16。若存取的是帶有 .local 後綴的裝置，還應將對應網域加入 Fake-IP 過濾清單。之後檢查系統防火牆是否將新建立的 TUN 網卡識別為公用網路，並限制區域網路通訊。

設定維護建議：保留可控的最小架構

中國大陸直連、海外代理不需要不斷增加規則類型。對大多數設定而言，私有位址直連、中國大陸網域直連、中國大陸 IP 補漏、指定服務例外與最終代理兜底已經足夠。規則越多，就越需要明確記錄來源、更新時間與優先級，否則一次規則集更新就可能改變原有行為。

建議將自訂內容拆成三層：訂閱負責提供節點，策略組負責選擇節點，規則集負責決定流量進入哪個策略。訂閱更新時不要覆蓋本機規則；規則集更新時不要重寫代理節點；切換節點時也無需修改規則。三層職責分離後，問題會穩定落在「節點無法使用」、「策略選錯」或「規則未命中」其中一層。

完成設定後，至少保存三項可供複查的資訊：目前核心名稱與版本、實際載入的設定檔，以及一次中國大陸請求和一次代理請求的連線詳細資訊。後續出現異常時，這些資訊比單純描述「網站打不開」更有定位價值。

下載 Clash 依平台選擇用戶端