一、設定前確認：核心、規則模式與策略群組

「中國大陸直連、海外走代理」並不是能自動判斷所有網站歸屬的開關。通常需要三個部分：明確的網域規則、網域或 IP 分類資料庫，以及最後一條兜底規則。設定目標是讓常用的中國大陸服務優先直連，指定的海外服務使用代理策略群組，並為未分類的連線提供可預期的出口。

本文以 mihomo 為準；它是 Clash Meta 後續採用的核心名稱。傳統 Clash 核心、不同分支，以及用戶端內建的設定轉換器，支援的欄位不盡相同。尤其是 GEOSITE 和地理資料庫設定，不能只看用戶端名稱就判斷是否可用。

  1. 確認實際執行的核心。在用戶端的「關於」或核心資訊頁面記下核心名稱與版本。若設定檢查提示不支援某種規則，應先確認核心功能，而不是繼續新增相同類型的規則。
  2. 選擇規則模式。規則分流需要設定 mode: rule。全域模式通常會將連線交由全域策略處理；直連模式則不會依本文的規則選擇代理。
  3. 確認出站名稱。本文以 Proxy 表示已存在的代理策略群組；名稱有大小寫之分。它必須存在於目前設定的 proxy-groups 中，且能選取有效節點。
  4. 備份目前的設定。訂閱產生的設定可能在更新後被覆寫。建議使用用戶端提供的持久化覆寫、合併設定或規則編輯功能，並檢查最終生效的設定。

二、規則比對順序：由上而下，先符合先處理

在規則模式下，核心會依序檢查 rules。一般分流情境中，一旦找到符合的規則，就會依該規則指定的出站處理，不會繼續尋找「更精確」的下一條。因此，排序比規則數量更重要：手動例外放前面，批次分類放中間，MATCH 放最後。

規則類型適用對象主要差異
DOMAIN單一完整網域精確比對，不會自動涵蓋其他子網域
DOMAIN-SUFFIX網域及其子網域github.com 也會涵蓋 api.github.com
GEOSITE資料庫中的網域集合需視本機資料庫是否包含相應分類
GEOIP目標 IP 所屬地區不能據此判定網站、帳號或營運主體所屬地區
RULE-SET規則提供者中的項目集合定義於 rule-providers 中
MATCH此前未符合規則的連線作為最後兜底，不代表「辨識海外」

先用兩條網域規則確認比對順序

rules:
  - DOMAIN,api.github.com,Proxy
  - DOMAIN-SUFFIX,github.com,DIRECT
  - MATCH,Proxy

這段設定用來說明優先順序：api.github.com 會符合第一條並使用 Proxy；github.com 和其他子網域則可能符合第二條而直連。如果將前兩條對調，後綴規則會先匹配 api.github.com，精確網域規則便不會生效。實際部署時，請依需求統一 GitHub 相關連線的出口，不必照搬這個用來比較的範例。

不要將 MATCH,DIRECT 放在規則開頭，也不要假設同一網域會自動選擇最精細的規則。廣告封鎖、公司內網、下載站等例外，也應遵循「需求越具體，規則越優先」的原則。

三、基本分流：網域優先、GEOIP 補充、代理兜底

先不加入外部規則檔，使用少量網域規則建立可驗證的基準設定。以下設定目標為：本機私有 IPv4 位址直連、Bilibili 相關主網域直連、GitHub 常用網域走代理、中國大陸目標 IP 直連，其餘連線交由 Proxy。

mode: rule

rules:
  - 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
  - DOMAIN-SUFFIX,bilibili.com,DIRECT
  - DOMAIN-SUFFIX,bilivideo.com,DIRECT
  - DOMAIN-SUFFIX,github.com,Proxy
  - DOMAIN-SUFFIX,githubusercontent.com,Proxy
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,Proxy

no-resolve 不代表「關閉 DNS」

no-resolve 表示不要只為了比對這條 IP 規則而主動觸發網域解析。如果連線中繼資料已有可用於比對的實際目標 IP，仍可判斷它是否位於指定網段或地區；如果目前只有網域、沒有可用 IP，這條規則可能會略過，連線接著往下比對。

因此，上述 GEOIP,CN,DIRECT,no-resolve 無法保證所有中國大陸網域都直連。若某個網域未被網域規則涵蓋，當下又沒有可用 IP，它最後仍可能使用 Proxy。相較於單靠 IP 分類，補上中國大陸網域集合通常更容易掌控。若改為允許 IP 規則觸發解析，也要一併評估解析路徑、耗時及回傳位址是否符合預期。

  • 私有網段規則只會決定已進入核心的連線使用哪個出口，不會自動建立區域網路路由，也不會授予應用程式存取內網的權限。
  • 這份範例只列出常見的私有 IPv4 網段；若使用 IPv6 內網，還需依實際網路補上相應規則。
  • 使用 fake-ip DNS 時，應留意核心還原的網域與實際解析結果，不要直接將 fake-ip 位址範圍加入一般直連網段。
  • 同一項服務可能使用多個網域。如果首頁正常，但圖片、登入或下載失敗，請從連線記錄找出遺漏的網域，不要直接將所有流量改為直連。

四、加入 GEOSITE：以網域分類補足中國大陸直連

GEOSITE 依據網域集合比對，不會根據伺服器 IP 推測網域歸屬。適合放在 GEOIP 前面，讓已分類的中國大陸網域直接使用 DIRECT。不過，集合內容取決於所使用的資料庫，不同資料來源的分類名稱和涵蓋範圍可能不同。

在 mihomo 中，可以採用以下局部結構。合併時保留上一節已確認的本機網段與手動例外；不要將這裡較短的 rules 誤認為必須取代原有規則清單的完整方案。

geodata-mode: true

rules:
  - DOMAIN-SUFFIX,github.com,Proxy
  - DOMAIN-SUFFIX,githubusercontent.com,Proxy
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,Proxy

geodata-mode: true 會讓 GEOIP 使用 DAT 資料模式；這種用法需要可用的 geoip.dat，而 GEOSITE 也需要 geosite.dat。請確認用戶端所用核心的工作目錄、資料庫載入記錄，以及資料來源確實包含 cn 分類。若沒有該分類，調整大小寫或反覆重新啟動都無法解決問題。

若記錄顯示資料庫載入失敗或找不到分類，請先還原上一節的基本規則，再修復資料檔。不要在同一次修改中同時更換 DNS、資料庫和代理節點，否則難以判斷是哪項調整改變了行為。

五、rule-providers 實作：將手動規則拆成易維護的檔案

規則增加後，可將中國大陸直連與強制代理項目拆成兩個檔案，減少重複編輯主設定的情況。以下使用本機 file 類型，避免直接加入來源不明的規則網址。檔案路徑以核心實際使用的設定目錄為準；透過用戶端匯入時，也要確認用戶端是否會複製或改寫設定目錄。

步驟一：建立兩個規則檔案

在核心設定目錄下建立 rules 資料夾，將以下內容分別儲存為 rules/direct.yaml 和 rules/proxy.yaml。這裡採用 classical 行為，因此每個項目都包含規則類型，但不包含最後的出站名稱。

# rules/direct.yaml
payload:
  - DOMAIN-SUFFIX,bilibili.com
  - DOMAIN-SUFFIX,bilivideo.com
  - DOMAIN-SUFFIX,qq.com
  - DOMAIN-SUFFIX,jd.com
# rules/proxy.yaml
payload:
  - DOMAIN-SUFFIX,github.com
  - DOMAIN-SUFFIX,githubusercontent.com
  - DOMAIN-SUFFIX,wikipedia.org

步驟二：定義提供者並加入規則

以下片段整合了本機 IPv4 網段、兩個規則集合、中國大陸網域分類及 IP 分類。現有設定仍須先定義有效的 Proxy 策略群組，且上一節提到的資料庫必須能正常載入。

mode: rule
geodata-mode: true

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

rules:
  - 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
  - RULE-SET,local-proxy,Proxy
  - RULE-SET,local-direct,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,Proxy

若兩個集合都包含同一個網域，仍會依主設定中 RULE-SET 的排列順序處理。本例將強制代理集合排在中國大陸直連集合之前，讓它覆寫例外項目。集合名稱只是識別名稱，不會自動決定優先順序。

步驟三：檢查格式與更新方式

  • YAML 階層：使用空格縮排，不要使用定位字元。同一份設定只保留一個頂層 rules 和一個頂層 rule-providers，並將新增項目合併至其中。
  • 行為與內容：classical 檔案應填入 DOMAIN-SUFFIX,github.com 這類完整規則條件，不要混入純網域清單。domain 和 ipcidr 行為各自有不同的內容格式。
  • 本機更新：type: file 不會定時從網路下載內容。修改檔案後，請使用用戶端支援的重新載入或規則集更新功能使設定生效，再檢查記錄。
  • 遠端更新：若改用 type: http，還需填寫可信任的實際 URL、快取路徑和更新間隔。例如 interval: 86400 代表 86400 秒，也就是 24 小時，不是 86400 毫秒。

訂閱更新與規則提供者更新是兩回事。前者可能重建整份設定，後者通常只會更新單一規則集合。若規則每次訂閱更新後都消失，請檢查用戶端的覆寫合併順序，而不是一再編輯暫時產生的檔案。

六、驗證分流：檢查規則、策略鏈與新連線

網頁能開啟，只代表某條存取路徑可用，無法證明連線符合預期規則。建議先將記錄層級設為 info，並在連線頁面同時檢查目標網域、目標 IP、符合的規則和出站鏈。不同用戶端的頁面名稱可能不同，請以實際顯示的欄位為準。

  1. 載入前檢查語法。若直接管理 mihomo，可在相同工作目錄執行 mihomo -t -f ./config.yaml。設定檔名稱與路徑應符合實際檔案；使用圖形介面用戶端時，也應使用內建的設定檢查功能。
  2. 測試直連範例。重新連線至 www.bilibili.com，確認是否符合 local-direct，且最後使用 DIRECT。頁面中的其他資源可能符合不同規則，請逐筆檢查記錄。
  3. 測試代理範例。重新連線至 github.com，確認是否符合 local-proxy。展開出站鏈，確認 Proxy 目前選取的是代理節點，而不是群組中的 DIRECT。
  4. 測試兜底規則。選擇一個不在手動集合中的網域，觀察它符合的是 GEOSITE、GEOIP 還是 MATCH。不要預設「未列入手動規則的網域」就一定會走代理。
  5. 關閉舊連線後重新測試。重新載入規則通常不會切換已建立的連線。瀏覽器連線重用、HTTP/2 和 QUIC 都可能讓舊路徑繼續使用；請關閉相關連線或離開應用程式後，再重新發出請求。

使用明確指定的代理，區分「流量未進入核心」與「規則未符合」

若設定的 mixed-port 是 7890，可在終端機執行以下兩次請求。若使用其他連接埠，請替換為實際值；Windows PowerShell 可使用 curl.exe，避免與其他命令別名混淆。7890 僅為範例連接埠，並非所有用戶端的固定設定。

curl -I --proxy http://127.0.0.1:7890 https://www.bilibili.com
curl -I --proxy http://127.0.0.1:7890 https://github.com

伺服器可能會對 HEAD 請求回傳重新導向或拒絕狀態，這不影響確認連線是否進入核心。重點是同步查看連線記錄。若明確指定代理的請求有記錄，但瀏覽器或遊戲沒有，應優先檢查系統代理、應用程式本身的代理設定或 TUN 接管範圍，不要先擴充規則清單。

TUN 模式負責接收符合路由條件的網路流量，不代表所有流量都會強制走代理；流量進入核心後，仍需依模式和規則選擇出口。並非所有應用程式都會遵循系統代理；兩者處理的是流量如何進入核心，而不是取代規則比對。

七、常見問題與維護順序

現象優先檢查項目處理方式
中國大陸網站仍走代理是否符合 MATCH、連線是否只有網域中繼資料補上網域規則，確認 GEOSITE 分類及 no-resolve 的影響
顯示 Proxy，實際卻使用本機出口策略群組目前的選項與完整出站鏈確認群組中選取的是有效代理節點，而非 DIRECT
修改後行為沒有改變生效中的設定、目前模式與既有連線重新載入正確的設定，關閉舊連線後再測試
規則提供者載入失敗檔案路徑、payload、behavior 與縮排先修正本機檔案，再處理遠端下載問題
部分圖片或登入功能失敗失敗請求使用的其他網域及其出口為必要的相關網域設定一致的出口
只有某個應用程式未依規則連線該應用程式的連線是否出現在核心中檢查應用程式代理或 TUN 路由接管，不要先修改分類資料庫

維護時依「流量接管路徑 → 規則模式 → 生效中的設定 → 符合的規則 → 策略群組選項 → 節點連線狀態」依序排查。規則負責選擇出口，無法修復失效的節點，也無法保證直連線路本身正常。若已確認符合正確規則，接著應檢查對應出口，而不是重複新增相同網域。

若要進一步了解規則模式、監聽連接埠與策略群組，請參閱代理模式說明、連接埠說明和策略群組說明；訂閱更新造成設定被覆寫的問題，可從訂閱相關疑難排解繼續查找。