V2Ray 路由規則設定實戰：中國大陸直連與境外代理分流寫法

分流核心：為每類請求選擇出站

V2Ray 路由不是另一種代理協定，而是核心處理請求時使用的一組判斷條件。應用程式請求進入本機 SOCKS、HTTP 或透明代理入口後，核心會讀取目標網域、目標 IP、連接埠與網路類型，再從 routing.rules 頂端開始逐條比對。第一條符合的規則會決定請求使用哪個 outboundTag，後續規則不再執行。

常見設定會準備三個出站標籤：proxy 連線訂閱節點，direct 直接存取目標，block 拒絕連線。路由規則本身不儲存節點位址，也不會變更 VMess、VLESS 等節點參數；它只會將流量送往已存在的出站。因此，從用戶端匯出設定後，應先確認實際標籤名稱，再複製規則。

「中國大陸直連、其他流量走代理」通常由三層條件完成：私有位址直連、中國大陸網域與中國大陸 IP 直連，其餘 TCP 與 UDP 請求交由代理。最後一條是兜底規則，必須放在規則清單底部。如果將兜底代理放在最前面，所有請求都會立即符合，後面的中國大陸直連規則就等於沒有執行。

routing 設定：geosite、geoip 與兜底規則

geosite 是網域分類資料，geoip 是 IP 位址區段分類資料。網域請求可以先依 geosite:cn 判斷；沒有符合網域規則時，將 domainStrategy 設為 IPIfNonMatch 會嘗試解析目標位址，再交由 IP 規則判斷。這種寫法兼顧網域存取與直接連線 IP 的程式。

以下片段只包含 routing 物件，應合併至現有的完整設定，而不是作為獨立設定檔啟動。廣告分類規則依賴 block 出站；如果目前設定沒有該出站，可以先刪除第一條規則，保留直連與代理分流。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "domainMatcher": "hybrid",
    "rules": [
      {
        "type": "field",
        "domain": [
          "geosite:category-ads-all"
        ],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "geoip:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

domainMatcher: hybrid 用於網域規則比對；部分舊版核心不識別此欄位時，可以刪除該行並使用預設比對器。分類資料也需要與核心版本相配套。如果日誌出現資料集不存在，而設定拼寫正確，應更新用戶端使用的核心與規則資料，不要將該錯誤誤判為節點失效。

在 v2rayN 中實作：從訂閱到自訂路由

v2rayN 負責儲存訂閱、選擇使用中的節點並產生核心設定。透過圖形介面維護路由時，用戶端會在啟動核心前組合節點出站與規則集，比反覆修改暫時產生的 config.json 更穩定。暫存檔可能在切換節點、更新訂閱或重新啟動用戶端後重新產生。

1. 確認節點連通性。更新訂閱並選擇一個節點，先使用「測試伺服器真實連線延遲」確認可以建立連線。路由只能分配流量，無法修復節點位址、連接埠或驗證參數。
2. 開啟路由設定。在 v2rayN 7.12.7 中進入「設定」→「路由設定」，建立一個規則集，並將其設為目前使用的路由設定。不同小版本的按鈕位置可能調整，但路由入口名稱維持一致。
3. 新增精確規則。依序建立廣告封鎖、私有 IP 直連、中國大陸網域直連、中國大陸 IP 直連規則。填寫出站標籤時，選擇用戶端現有的 block、direct 或 proxy，不要輸入節點備註名稱。
4. 新增最終代理規則。將網路類型設為 TCP 與 UDP，出站設為 proxy，並將該規則移至最底部。沒有最終兜底時，未符合的請求會依核心預設行為處理，結果不夠直觀。
5. 儲存並重新啟動核心。儲存規則後執行一次重新啟動服務，再開啟日誌視窗確認設定載入成功。只關閉設定視窗而不重新啟動時，正在執行的核心可能仍使用舊設定。

v2rayNG 與 v2flyNG 也提供路由設定，但兩者使用的核心分支不同。v2rayNG 通常搭配 Xray 核心，v2flyNG 則對應 V2Fly 核心。基礎的 field、domain、ip、network 與 outboundTag 邏輯一致，但可用的擴充欄位可能不同。跨用戶端遷移時，應先保留基礎規則，再逐項驗證核心專屬功能。

規則優先順序：具體條件置前，寬泛條件置後

路由規則採用由上而下的首次符合機制，不會先合併多條規則再計算最佳結果。某個網域若同時屬於自訂代理清單與 geosite:cn，最終走向取決於哪條規則排在前面。設計順序時，可以依「手動例外、特殊類別、私有位址、區域分類、最終兜底」排列。

需要讓某個網域始終走代理時，應將自訂規則放在 geosite:cn 之前。網域比對形式也有所不同：full: 只比對完整主機名稱，domain: 可以比對該網域及其子網域，regexp: 使用正規表示式。一般分流優先使用 full 或 domain，只有確實需要模式判斷時才使用正規表示式。

{
  "type": "field",
  "domain": [
    "full:status.example.net",
    "domain:service.example.net"
  ],
  "outboundTag": "proxy"
}

反過來，如果某個下載網站需要始終直連，也應建立獨立的 direct 規則，並放在最終代理規則之前。不要為了一個例外刪除整組 geosite 或 geoip 規則，否則會將局部問題擴大成全域分流變更。

DNS 與網域辨識：為什麼規則正確仍可能走錯

路由能否依網域比對，取決於核心是否取得原始目標網域。瀏覽器透過本機 SOCKS5 傳遞網域時，核心可以直接比對 geosite；如果上游只交給核心一個已解析完成的 IP，網域規則便無法參與，只能依賴 geoip。透明代理情境還可能透過流量探測還原 HTTP 主機名稱或 TLS Server Name。

• AsIs：依請求原始形式比對。目標是網域時檢查網域規則，目標只有 IP 時不會主動為路由解析網域。
• IPIfNonMatch：先嘗試網域規則；網域規則未符合時解析 IP，再檢查 IP 規則。適合本文的區域分流架構。
• IPOnDemand：遇到需要 IP 判斷的規則時可能提前解析。規則很多或 DNS 路徑複雜時，應先在測試環境確認行為。
• 流量探測：入口的 sniffing 可從 HTTP 或 TLS 流量中辨識目標網域。只應啟用設定所需的目標覆寫類型，並觀察核心日誌是否辨識成功。

DNS 查詢本身要走哪個出口也是獨立問題。若系統 DNS 能正常解析中國大陸網域，而代理節點負責連線其他目標，基礎分流通常已足夠。若出現解析污染、境內外結果不同或 UDP 查詢逾時，則需要進一步設定核心 DNS，並明確指定 DNS 伺服器位址、查詢網域範圍與查詢流量的出站。

使用 IPIfNonMatch 不代表所有網域都會先解析。已符合 geosite:cn 或自訂網域規則的請求可以直接選擇出站；只有網域條件沒有結果，且後方還存在 IP 規則時，才需要解析並繼續判斷。這也是它比無條件依賴 IP 判斷更適合一般設定的原因。

日誌排錯：從設定載入到規則符合

分流失敗時，應先區分「核心沒有啟動」與「核心已啟動但走錯出站」。前者通常在啟動後數秒內出現 error 或 failed，常見原因包括 JSON 逗號錯誤、欄位層級放置錯誤、出站標籤不存在及規則資料檔案遺失。後者則需要提高日誌層級，觀察目標位址與最終出站。

1. 檢查 JSON 結構。routing 應與 inbounds、outbounds 位於設定根層級。複製片段時，多餘逗號與重複的大括號是常見錯誤。
2. 核對標籤拼寫。outboundTag 區分字元內容，必須與 outbounds 陣列中的 tag 完全一致。proxy 節點備註不能取代出站標籤。
3. 檢查規則資料。若日誌指出 geosite 或 geoip 項目無法載入，應確認資料檔案存在，且目前核心支援該分類名稱。
4. 暫時提高日誌層級。將 loglevel 從 warning 調整為 info，重新啟動核心後存取一個中國大陸網域與一個需要代理的網域，再查看連線紀錄。排錯結束後可恢復為 warning，減少日常日誌量。
5. 縮小規則集合。先保留 private、cn 與最終 proxy 三組基礎規則。基礎分流正常後，再逐條恢復廣告分類、自訂網域與連接埠規則。

{
  "log": {
    "loglevel": "info"
  }
}

如果中國大陸網域仍走代理，先檢查最終 proxy 規則是否排在 geosite 規則之前，再確認請求是否只攜帶 IP。若請求只有 IP，檢查 geoip:cn 是否載入成功。若某個境外服務走了 direct，檢查它是否被自訂直連規則或區域資料誤判符合，並透過日誌確認實際目標網域。

UDP 請求異常時，應確認目前節點協定與傳輸設定是否允許 UDP，同時檢查最終兜底規則的 network 是否包含 udp。只寫 tcp 會讓網頁看起來大致正常，但依賴 UDP 的 DNS、即時通訊或部分網路檢測出現逾時。路由允許 UDP 不代表節點端必然接受 UDP，兩端能力必須同時具備。

驗證結果：使用固定目標完成回歸測試

儲存規則後不要只測試一個網頁。瀏覽器快取、連線重用與 DNS 快取都可能保留舊結果。建議重新啟動核心、關閉現有連線，再使用固定測試清單，分別涵蓋區域網路位址、中國大陸網域、直接 IP、境外網域、TCP 與 UDP。每次修改規則後重複同一份清單，結果才具可比性。

• 存取路由器管理位址或本機服務，確認 geoip:private 符合 direct，區域網路連線未進入代理。
• 選擇 5 個常用中國大陸網域，清除連線後逐一存取，確認日誌中的出站為 direct。
• 選擇 5 個需要代理的網域，確認最終符合 proxy，而不是被寬泛的直連規則提前攔截。
• 使用設定中的 SOCKS 連接埠 10808 與 HTTP 連接埠 10809 分別發起測試，確認應用程式沒有連線至舊連接埠。
• 測試一個 UDP 請求，並檢查節點端是否支援對應轉發；失敗時單獨記錄 UDP 結果，不要與 TCP 網頁存取混為一談。
• 切換一次訂閱節點並重新啟動核心，確認自訂路由仍被選取，規則沒有隨暫時設定更新而遺失。

可維護的基礎方案通常只有少量規則：私有位址直連、中國大陸網域直連、中國大陸 IP 直連、明確例外與最終代理。規則越多，分類交叉與順序衝突越難排查。新增規則前先說明它要解決的具體目標，並記錄應放在現有哪條規則之前。

geosite 與 geoip 資料會隨網路資源變化而更新，區域分類不可能永久涵蓋每個網域與位址區段。遇到少數分流錯誤時，優先新增精確例外並保持在區域規則上方；只有大量目標同時異常時，才需要檢查規則資料版本、核心相容性與 DNS 路徑。