V2Ray 路由設定教學：geosite／geoip 分流與規則配置

本文重點

本文適合已成功連上節點、準備調整分流規則的使用者。先了解網域清單與 IP 清單的差異，再選擇解析策略，最後依序組合廣告封鎖、中國大陸直連與代理備援。範例採用 V2Ray／Xray 原生路由欄位，說明如何整合至現有用戶端設定，並透過日誌確認實際使用的出站，不要只靠網頁能否開啟來判斷規則是否生效。

1. geosite 與 geoip：各自比對什麼

路由分流是在連線進入核心後進行。核心取得目標網域或 IP，依序檢查 routing.rules；找到第一條符合條件的規則後，就會將連線交給對應的 outboundTag。符合多條規則時不會合併處理，也不會接著尋找「更精確」的規則。因此，規則內容和排列順序同樣重要。

寫法	比對對象	依賴項目與限制
`geosite:cn`	網域清單	依賴 geosite.dat 中的 cn 分類，不代表所有以 .cn 結尾的網域。
`geoip:cn`	中國大陸 IP 網段	依賴 geoip.dat；僅依 IP 位址的地理歸屬比對，與網頁內容及營運者所在地無關。
`geoip:private`	私有與特殊用途 IP 位址清單	常用於區域網路直連；實際收錄範圍以目前使用的資料檔為準。
`domain:example.com`	指定網域及其子網域	不依賴網域分類，適合用來補充自訂例外規則。
`full:example.com`	完整網域	只比對該網域，不包含其子網域。

geosite 是分類資料，不是即時搜尋服務。同一分類在不同資料來源或更新日期下，可能包含不同項目。啟動時若提示找不到 category-ads-all，應先確認資料檔是否包含這個分類，而不是調整節點協定。Xray 與 V2Fly 常用的資料檔可能提供這些標籤，但實際內容仍以本機檔案為準。

2. domainStrategy：何時為分流解析網域

routing.domainStrategy 控制的是路由判斷階段如何使用網域解析結果，不是全域 DNS 開關，也不等同於直連出站的同名設定。如果應用程式傳給核心的是目標 IP，網域規則通常無法憑空還原網站名稱；如果傳入的是網域，是否進一步查詢 IP 則由下列策略決定。

IPIfNonMatch

建議

先使用網域等現有資訊進行比對；沒有規則符合時，再解析目標網域並嘗試比對 IP 規則。適合作為中國大陸與海外分流的起點，但若末尾設有全匹配規則，第一輪就會結束，因此必須確認備援規則的設定方式。

適用情境：優先比對網域，並希望未分類網域接著依 IP 判斷

AsIs

路由判斷時不主動解析網域。網域交由 geosite 或明確指定的網域規則處理；應用程式直接傳入的 IP 仍可比對 geoip。這種方式容易預測，但未收錄的網域無法靠 geoip:cn 補充判定。

適用情境：希望減少路由解析，主要依賴網域分類

IPOnDemand

比對過程遇到需要 IP 的規則時，才按需解析目標網域。將明確的網域規則放在 IP 規則之前，再設定代理備援，即可優先比對網域，同時讓未分類網域繼續進行 IP 判斷。

適用情境：需要以 IP 補充比對，並採用明確的備援規則

本文的組合範例採用 IPOnDemand，因為最後會明確加入 network: "tcp,udp" 代理備援。若改用 IPIfNonMatch，這條備援規則會在第一次比對時就符合，未分類網域便不會觸發「無符合項目後再解析」。另一種做法是移除全匹配備援，並讓設定中的第一個出站為代理；此時必須確認用戶端產生的出站順序，不能只修改策略名稱。

網域已符合廣告規則：直接交由阻斷出站處理，不必再查詢 IP。
網域已符合中國大陸網域規則：直接交由直連出站處理，不受後續 IP 分類影響。
網域未符合前面的規則：在 IP 規則處按需解析；中國大陸 IP 直連，其餘連線交由代理備援。

3. 設定前檢查：出站標籤、連接埠與資料檔

以下設定使用三個出站標籤：proxy 是已可正常使用的代理節點，direct 是 Freedom 直連，block 是 Blackhole 阻斷。這些是區分大小寫的字串參照，不是介面上顯示的名稱。節點使用 VMess 或 VLESS，不會改變路由引用標籤的方式；節點傳輸與安全參數仍由原有出站設定負責。

3 個

範例所需的出站標籤

5 條

組合範例中的規則順序

10808

下文驗證使用的本機 SOCKS 範例連接埠

連接埠 10808 只是本文測試命令使用的範例值，不代表所有安裝環境的預設值。執行命令前，請在用戶端的本機監聽設定中確認實際連接埠；若本機監聽的連接埠不同，請替換命令中的數字。監聽位址維持 127.0.0.1 即可，路由測試不需要開放給區域網路中的其他裝置。

備份設定

先備份現有設定與自訂路由。使用目前的節點連上已知可用的網站，確認基本連線正常後，再開始調整分流。
確認路由設定入口

v2rayN 常見的操作路徑是「設定」→「路由設定」。先記下目前啟用的規則集；若不同版本的介面選單位置不一樣，請以實際出現的「路由設定」頁面為準，不要把原生設定直接貼進訂閱網址欄位。
確認出站設定

查看匯出的執行設定，確認代理出站實際使用的 tag。若不是 proxy，請替換下文所有對應參照；既有節點的伺服器、驗證與傳輸設定則應保留。
確認資料檔

確認核心可以讀取 geosite.dat、geoip.dat，並包含本文使用的 cn、private、category-ads-all 等分類。若缺少分類，請先修復資料檔，或移除對應規則後再測試。
套用並重新啟動

儲存規則後重新啟動代理服務，再檢查啟動日誌。先處理 JSON 解析錯誤、標籤不存在或資料載入錯誤，再測試網站連線。

4. 中國大陸直連、廣告封鎖與代理備援設定

以下是可合併至原生設定頂層的 routing 物件，不是包含節點驗證資料的完整用戶端設定。規則依序處理：封鎖廣告網域、中國大陸網域直連、私有位址直連、中國大陸 IP 直連，其餘 TCP／UDP 流量走代理。確認前文約定的三個出站標籤都存在，即可將這些規則用於現有設定。

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

如果現有設定已有 routing，請替換或整理其中的策略與規則陣列，不要在同一層重複新增同名鍵。以下提供直連與阻斷出站物件：將需要的物件加入現有 outbounds 陣列即可。若已有相同標籤，保留一份即可；不要用這段陣列覆蓋原有代理節點。

[
  {
    "tag": "direct",
    "protocol": "freedom",
    "settings": {}
  },
  {
    "tag": "block",
    "protocol": "blackhole",
    "settings": {}
  }
]

兩種整合方式：保留節點，只調整路由

透過圖形介面管理規則

在路由設定中新增或複製一組自訂規則。
依照範例順序填入網域、IP 與網路條件。
使用用戶端提供的代理、直連和阻斷出口選項對應標籤。
啟用該規則集，並檢查產生的執行設定。

原生 JSON 設定

將 routing 物件合併至頂層。
保留已確認可用的 proxy 出站。
補上 direct、block 兩個出站物件。
由用戶端載入受管理的自訂設定，並查看啟動日誌。

圖形介面可能會改寫標籤或出站順序。最終應以核心實際載入的設定為準，而不是規則集的顯示名稱。

此方案中「海外流量走代理」的確切意思是「未被前面規則判定為阻斷或直連的流量走代理」，並非逐一列出所有海外網站。採用備援規則可涵蓋新出現的網域，但 geoip:cn 仍可能讓某些海外服務使用的中國大陸 CDN 位址直連。若特定網站必須使用代理，請將該網站的明確網域規則放在 IP 規則之前。

5. 規則排序與例外：先精確，再寬鬆

廣告規則排在中國大陸網域規則之前，代表被廣告分類收錄的中國大陸網域也會遭到阻斷。若必要的登入或靜態資源網域被誤擋，可先新增精確的例外規則，再保留廣告規則。例外範圍應盡量縮小，不要只為了修正一個資源網域，就讓整個大型網域清單直連。

{
  "type": "field",
  "domain": [
    "full:static.example.com"
  ],
  "outboundTag": "direct"
}

static.example.com 是用來示範比對語法的網域，不是實際需要放行的服務資源。使用時請換成日誌中確認的完整目標名稱，並將這條規則放在廣告規則之前。只有需要一併處理所有子網域時才使用 domain:；若只處理單一主機名稱，優先使用 full:。

需求	插入位置	檢查重點
放行遭廣告規則誤擋的網域	廣告阻斷規則之前	只放行日誌中確認必要的網域。
指定網站強制走代理	中國大陸網域與 IP 直連規則之前	必要時也要涵蓋網站使用的獨立資源網域。
指定區域網路位址直連	代理備援之前	確認應用程式確實將請求交給核心處理。
調整預設出口	規則陣列末尾	不要讓全匹配規則提早攔截，影響後續規則。

廣告網域阻斷不是篩除網頁元素。如果廣告與正文共用同一個主機名稱，路由無法只移除廣告區塊；依網域阻斷也可能影響影片播放、登入或統計回呼。遇到功能異常時，先確認實際符合的網域和出站，再縮小封鎖範圍。

6. 驗證分流：查看出站日誌，不只看網頁

測試時先維持代理模式與節點不變，每次只調整一條規則。暫時啟用能記錄連線去向的日誌層級，觀察同一筆請求的目標與出站標籤；完成後再恢復日常日誌層級。日誌可能包含瀏覽目標，分享截圖前請清除訂閱網址、節點驗證資料與個人瀏覽紀錄。

中國大陸網域：選擇確認已收錄於目前 geosite:cn 分類的網站，檢查連線是否交由 direct 處理，不要只看網頁載入速度。
代理備援：選擇確認不符合前置規則的目標，檢查出站是否為 proxy；出口 IP 檢測只能作為這筆請求的輔助驗證。
符合廣告規則：從本機分類資料或連線日誌中找出已確認屬於廣告清單的網域，檢查是否交由 block 處理，不必主動開啟不熟悉的網站。
私有位址：連線至自己管理的區域網路服務，檢查是否走 direct。若瀏覽器依照系統設定略過代理，請求可能根本不會出現在核心日誌中。

使用命令列驗證可減少瀏覽器快取與擴充功能造成的干擾。下列命令假設本機 SOCKS 監聽位址為 127.0.0.1:10808，並使用 socks5h 將目標網域交由代理端處理。在 Windows 使用 curl.exe 可避免命令別名造成的差異；其他系統則可使用 curl。

curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://www.baidu.com
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com

這兩個網址用來產生可觀察的請求，不預設它們在任何資料版本或網路環境下的最終分類。收到 HTTP 狀態碼只代表請求有收到回應，無法證明使用了哪個出站；仍須同時查看日誌。若第一個命令傳回重新導向，也要依各連線的實際目標判斷，不能把後續的新網域視為同一筆比對結果。

7. 常見問題：DNS、模式覆蓋與分類缺漏

設定 geoip:cn 後，中國大陸網站為什麼還是走代理？

先確認實際設定是否為 IPIfNonMatch，且末尾有全匹配規則。這種組合可能讓網域在解析前就符合代理備援。請依本文改用 IPOnDemand，並將 IP 規則放在備援之前；接著查看解析出的位址是否屬於目前 geoip:cn 分類。

規則已儲存，為什麼日誌完全沒有變化？

確認儲存後已啟用該規則集並重新啟動服務。檢查是否仍使用全域代理或全域直連模式，以致自訂路由遭到覆蓋；再確認應用程式是否確實連上本機代理。系統代理只會影響遵循該設定的應用程式，不會接管所有網路連線。

啟動時提示找不到 geosite 分類，該怎麼辦？

先查看錯誤訊息指出缺少哪個標籤，再確認核心實際載入的資料檔位置與內容。可暫時移除該條規則，確認其他設定能否啟動，之後再補上相容的資料檔。只更新訂閱中的節點清單，通常無法修復分類資料問題。

Android 版可以直接複製桌面版的路由設定嗎？

v2rayNG 使用 Xray 核心，v2flyNG 使用 V2Fly 核心；本文的基本欄位在對應核心中廣泛適用，但用戶端介面、自訂設定入口與資源管理方式各有不同。請先確認出站標籤與資料分類，再依用戶端支援的方式匯入；不要把整份桌面版設定檔當成訂閱網址。

使用 geosite 後，還需要檢查 DNS 嗎？

仍然需要。未分類網域的 IP 判斷取決於解析結果，直連也必須取得可用的目標位址。routing.domainStrategy 不保證所有應用程式的 DNS 請求都會由核心接管，也不會自動構成完整的 DNS 隱私方案。請先確認應用程式傳入的是網域還是 IP，再檢查解析路徑與實際出站。

排查順序可以固定為：設定能否載入、請求是否進入核心、目標是網域還是 IP、第一條符合的規則是什麼，以及出站能否建立連線。先確認這五項，再考慮補充分類或調整 DNS。如此便能區分「規則未符合」與「規則符合但節點連線失敗」，減少反覆修改設定造成的干擾。