適合已匯入訂閱、節點可正常連線,但希望中國大陸網站直連、境外網站走代理的 v2rayN 使用者。先了解網域集與 IP 集的差異,再選擇網域解析策略,最後依序設定規則並透過日誌確認。本文也會說明「末尾全代理規則」為何可能讓 geoip 回退失效;範例是核心路由片段,並非可直接匯入用戶端的完整設定。
一、geosite 與 geoip 分別比對什麼
v2rayN 是用戶端介面,實際處理連線的是所選核心。訂閱主要提供伺服器位址、協定、驗證與傳輸參數;路由則決定進入本機核心的連線要使用哪個出口。更新訂閱不等於更新路由資料庫,也不會自動調整自訂規則的順序。
geosite 依網域集合比對,geoip 依 IP 位址集合比對。兩者都仰賴對應的資料檔,不能只從名稱就以為是即時定位服務。尤其是 geosite:cn,代表資料庫維護的網域分類,不是「所有以 .cn 結尾的網站」,更不保證伺服器的實際所在地。
| 條件 | 比對對象 | 常見用途 | 注意事項 |
|---|---|---|---|
geosite:cn | 目標網域 | 資料庫收錄的中國大陸網站直連 | 分類依所使用的 geosite 資料而定 |
geosite:category-ads-all | 廣告相關網域 | 交由 block 出口處理 | 資料檔必須包含該分類 |
geoip:cn | 目標 IP | 中國大陸 IP 範圍直連 | 網域連線可能需要先解析 |
geoip:private | 私有與本機位址集合 | 存取內網裝置 | 以資料集定義為準,不代表所有區域網路網域 |
full:example.com | 完整網域 | 單一網域的例外規則 | 不會同時比對其子網域 |
domain:example.com | 網域及其子網域 | 同一網站家族使用相同出口 | 涵蓋範圍比完整網域規則更廣 |
此處的 example.com 僅用來說明語法,並非實際應新增的業務規則。檢查自己的網站時,請使用瀏覽器或核心日誌中出現的實際主機名稱。同一頁面可能載入多個網域;首頁能直連,不代表登入介面、圖片與影片也會比對到相同規則。
二、domainStrategy 怎麼選:先比對網域還是 IP
routing.domainStrategy 決定路由比對時是否解析目標網域。它不是 DNS 伺服器位址,也不是 direct 出口內部的解析策略。名稱雖然相似,作用位置卻不同:一種是為「選擇出口」提供 IP,另一種則可能在「實際建立直連」時解析位址。
IPIfNonMatch
推薦先依目前已有的目標資訊比對規則。網域階段沒有任何規則命中時,再解析網域並嘗試比對 IP 條件。適合本文「網域優先、IP 補漏」的做法,但必須保留真正未命中的狀態,不能先被全流量規則接手。
適用情境:以網域規則為主、geoip 補充,且已明確設定預設出口
AsIs
路由階段不額外解析網域。以網域形式進入的連線主要依靠網域規則;以 IP 形式進入的連線仍可比對 IP 規則。這不代表整個連線過程都不會使用 DNS。
適用情境:網域規則涵蓋範圍明確,希望避免路由階段額外查詢
IPOnDemand
比對過程遇到需要 IP 的規則時才解析網域。如果私有位址或國家 IP 規則放在前面,網域連線可能較早觸發 DNS 查詢。這能讓末尾兜底規則之前的 IP 規則參與比對,但也更依賴解析結果。
適用情境:需要依目標 IP 判斷,且已確認 DNS 行為
最容易忽略的狀況是:使用 IPIfNonMatch,同時在末尾加入 network: tcp,udp → proxy。這條規則第一次比對時就能接手連線,因此不會出現「完全未命中」的狀態;網域解析回退可能不會觸發,前面的 geoip:cn 也就無法為這次網域連線補漏。
- 沿用本文做法:不加入全流量兜底規則,並確認產生的設定中第一個出口是
proxy。沒有路由規則命中時,核心會使用第一個出口。 - 必須明確設定末尾兜底:可考慮改用
IPOnDemand,並將需要判斷的 IP 規則放在兜底之前,再檢查 DNS 與出口日誌。 - 只依網域分流:可以選擇
AsIs,但不要期待網域連線能透過geoip:cn自動補漏。
三、direct、proxy、block 與規則順序
核心會由上而下檢查規則清單,第一條符合的規則決定出口。這裡的 direct、proxy、block 都是出口標籤,不是隨意填上就會生效的關鍵字。完整設定中必須存在同名出口;自訂設定若使用其他標籤,也要同步修改路由引用。
直連與代理出口
- 直連標籤
direct- 直連方式
- 通常使用 freedom 出口
- 代理標籤
proxy- 代理目標
- 目前選取且可用的節點
- 未命中的流量
- 本文要求第一個出口為 proxy
切換節點會改變代理連線的目標,但不應影響這套規則的比對順序。
封鎖與規則前提
- 封鎖標籤
block- 封鎖方式
- 通常使用 blackhole 出口
- 網域資料庫
geosite.dat- IP 資料庫
geoip.dat- 比對原則
- 由上而下,第一條符合的規則生效
資料檔缺失或分類不存在時,核心可能無法載入設定,應先處理啟動日誌中的錯誤。
建議順序為:必要的單站例外、廣告封鎖、內網位址直連、中國大陸網域直連、中國大陸 IP 直連,最後由預設出口代理。例外規則放在最前面,是為了避免被涵蓋範圍更廣的分類蓋過;但它也會優先於後續廣告規則,因此只新增確實需要的網域。
| 優先順序 | 規則用途 | 出口 | 放置原因 |
|---|---|---|---|
| 1 | 單一網站的手動例外 | direct 或 proxy | 優先於後續的廣泛分類 |
| 2 | 廣告網域集合 | block | 避免先符合中國大陸直連分類 |
| 3 | 私有 IP 與本機網段 | direct | 內網連線不應送往遠端節點 |
| 4 | 中國大陸網域集合 | direct | 網域可直接判斷時,不必等待 IP 回退 |
| 5 | 中國大陸 IP 集合 | direct | 補足純 IP 連線與未收錄網域 |
| 預設 | 沒有任何規則符合的連線 | proxy | 使用產生設定中的第一個出口 |
四、在 v2rayN 建立獨立的路由規則
以下選單路徑以 v2rayN 7.x 的 Windows WPF 介面為例。桌面版與不同小版本的按鈕名稱可能不同;找不到相同選項時,請先在目前介面的設定選單確認路由編輯功能,不要將下方核心 JSON 貼到節點位址欄或訂閱位址欄。設定前請保留原有路由方案,方便切換回去。
-
確認節點可用
在主畫面選取可用節點,並設為作用中的伺服器。先沿用原有路由確認網頁能正常瀏覽;若節點逾時、驗證失敗或 TLS 交握失敗,請先依故障排除處理,分流規則無法修復遠端連線。
-
開啟路由設定
前往「設定」→「路由設定」,新增一套路由方案,命名為「中國大陸直連測試」。如果介面提供進階路由開關,請確認已啟用進階規則,並將新建方案設為目前使用的路由。
-
選擇網域策略
在路由方案的網域策略選項中選擇
IPIfNonMatch。接著確認是否有「所有 TCP、UDP 都走代理」的末尾規則;本文做法不保留這種規則,而是要求預設出口為 proxy。 -
分別新增條件
依序新增廣告網域、私有 IP、中國大陸網域、中國大陸 IP 四條規則。
geosite:用於網域條件,geoip:用於 IP 條件。不要在同一條規則中同時填入網域條件和 IP 條件,來表示「符合其中一項即可」。 -
儲存並核對
儲存方案,讓核心重新載入設定。確認產生設定中的規則順序、出口標籤與
outbounds順序;若預設出口不是 proxy,請依目前版本提供的預設出口設定進行調整,或改用前文介紹的明確兜底方案。 -
逐項測試
保持節點、瀏覽器與代理接入方式不變,分別測試中國大陸網域、境外網域及內網 IP。每次調整後都建立新連線,避免瀏覽器沿用舊連線;只有日誌顯示的出口符合預期,才能確認規則生效。
在同一條 field 規則中,不同類型的條件通常必須同時符合;同一個條件陣列中的多個值才表示符合其中任一值。將 domain 和 ip 放進同一條規則,不能取代兩條獨立的直連規則。無論手寫設定或使用圖形介面編輯,都很容易遇到這個錯誤。
五、核心路由片段:網域優先,IP 補漏
以下僅展示 routing 物件,不含入站、節點憑證、DNS 或出口定義,因此不是完整設定,也不是可匯入 v2rayN 路由方案的格式。可依此在介面中逐條填寫;若使用自訂核心設定,則須合併至現有設定結構,並確認三個出口標籤都已定義。
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"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"
}
]
}
}
- 預設代理前提:完整設定中的
outbounds[0].tag必須是proxy。只有上方的路由片段,無法保證未命中的連線會走代理。 - 分類前提:目前的資料檔包含
cn、private與category-ads-all。更換資料庫後,請先確認這些分類仍可載入。 - 純 IP 連線:存取
192.168.1.1時,可直接以 IP 條件比對,不需要等待網域解析。若實際裝置不是這個位址,請改用自己的裝置位址測試。 - 網域連線:先嘗試比對廣告與中國大陸網域分類;未命中時,再依策略解析並嘗試比對 IP 條件。解析失敗不會憑空產生可用的目標 IP。
如果某個中國大陸分類中的網站必須固定走代理,可在廣告規則之前新增獨立的網域例外,並指向 proxy。如果只有某個子網域異常,優先使用 full: 精確比對,不要立刻擴大到整個主網域及所有子網域。
六、如何驗證分流:檢查接入、DNS 與出口
網頁能開啟只代表某條連線路徑可用,無法證明使用了預期出口。測試時先固定一個節點,再確認應用程式使用的本機代理連接埠。v2rayN 常見的本機監聽連接埠是 10808,但既有安裝可能已修改,應以目前設定與核心啟動日誌為準,不要假設它永遠固定。
| 測試項目 | 預期結果 | 確認內容 |
|---|---|---|
| 已確認包含於 cn 集合的網域 | direct | 日誌中的目標網域與出口標籤 |
| 未符合直連分類的境外網域 | proxy | 預設出口是否為代理 |
192.168.1.1 等實際內網位址 | direct | 連線是否進入核心,以及是否符合私有 IP 規則 |
| 日誌中實際出現的廣告網域 | block | 分類是否有收錄,以及是否先被例外規則比對 |
若要確認網域會保留並交由 SOCKS 代理,可使用下方的測試命令。socks5h 中的 h 表示由代理端處理目標網域解析,避免先在本機解析、再只將 IP 提交給核心。命令需要本機連接埠提供 SOCKS 服務,系統也必須已安裝 curl 工具。
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 https://www.baidu.com/ --output /dev/null
上述指令適用於 Linux、macOS 終端機;在 Windows 命令提示字元中,可將 /dev/null 改為 NUL,並視需要使用 curl.exe 執行。這裡的 10 秒連線逾時與 20 秒總逾時只是測試限制,不代表實際延遲,也不是速度保證。該網域是否應直連,仍應以自己的資料檔與日誌為準。
- 沒有連線日誌:先確認應用程式是否繞過代理、監聽連接埠是否正確,以及核心是否已啟動;不要先修改 geosite。
- 有網域但出口不正確:檢查規則順序、分類內容、目前使用的路由方案,以及是否有更早命中的全流量規則。
- 日誌中只有 IP:應用程式可能已在本機完成解析。網域規則無法直接比對純 IP 目標;在適用的協定中,嗅探可能提供網域資訊,但無法保證還原所有流量。
- 解析失敗或位址異常:檢查目前的 DNS 設定與解析路徑。路由選擇與 DNS 查詢的出口相關但並不相同,不應將所有 DNS 請求一律設為直連。
七、常見問題:規則未生效與廣告誤封
寫了 geoip:cn,為什麼中國大陸網站還是走代理?
前往「設定」→「路由設定」,先確認目前使用的方案與網域策略。若使用 IPIfNonMatch,檢查末尾是否有 tcp,udp 全代理規則;它可能讓第一次比對就結束。接著確認日誌中的目標是網域還是 IP,以及實際解析出的位址是否屬於目前 geoip 資料中的 cn 分類。
廣告規則放在最後,為什麼完全沒效果?
將 geosite:category-ads-all → block 移到中國大陸直連與範圍較廣的代理規則之前,儲存後重新載入設定並建立新的瀏覽器連線。若仍未命中,請確認該網域是否包含在目前分類中。不要只因頁面上仍有廣告就認定失敗;與網站內容共用網域的廣告不一定適合用網域封鎖。
修改路由後核心無法啟動,該先檢查什麼?
先切回原本的路由方案以恢復連線,再查看核心啟動日誌。重點檢查資料檔無法讀取、分類不存在、出口標籤引用錯誤及 JSON 語法錯誤。若顯示無法載入 geosite.dat 或指定分類,應修復資料來源與檔案位置,而不是繼續新增規則。
無法開啟內網管理頁面,該新增什麼規則?
先使用裝置的實際 IP 位址連線,並確認私有 IP 規則指向 direct。若使用自訂內網網域,也要確認本機 DNS 能正確解析;可為實際網域新增精確的直連例外。網域路由本身不會自動將不存在的 DNS 紀錄變成可連線的位址。
這套規則可以直接複製到 Android 用戶端嗎?
v2rayNG 使用 Xray 核心,v2flyNG 使用 V2Fly 核心;基本路由概念相近,但介面欄位、匯入格式、資料分類與核心功能都要分別確認。可以沿用「規則條件與順序」,但不要直接把 v2rayN 用戶端備份當成通用設定。移轉後仍須檢查預設出口與 DNS。
最後請保留一份已驗證的路由方案。之後遇到單一網站異常時,每次只調整一個變數:先判斷問題來自網域分類、IP 分類、DNS 或節點連線,再新增範圍最小的例外。這樣更容易確認變更原因,也能在修改無效時快速還原。
- 儲存前確認:網域與 IP 條件沒有填錯欄位,廣告規則沒有被涵蓋範圍更廣的規則蓋過。
- 啟用後確認:預設出口為 proxy,內網與中國大陸測試連線使用 direct。
- 更新資料後確認:核心正常載入、原有分類仍存在,重要網站沒有意外分流。
- 分享排查資訊時:只提供必要規則與已去識別化的日誌,不要公開訂閱網址或節點驗證參數。