適合已匯入訂閱、準備調整 v2rayN 分流規則的使用者。先分清網域與 IP 比對，再依「明確例外、分類規則、最後兜底」的順序編排。本文範例採用 V2Ray/Xray 的 field 路由結構，提供可修改的 JSON 片段；套用前請確認實際使用的核心、出站標籤與規則資料庫，這些片段不能直接當作完整用戶端設定執行。
一、先了解路由規則
路由不是訂閱節點清單。訂閱提供伺服器連線參數；路由則決定連線要交由哪個出站處理。更換 VMess 或 VLESS 節點，不會自動修正寫錯的網域條件。以下以 direct、proxy、block 作為標籤，分別代表直連、代理與封鎖；這些名稱必須已存在於實際設定的出站中。
最簡單的規則只要說明「比對什麼」以及「交給誰」。以下物件會將 example.com 及其子網域交由代理出站處理。它只是 routing.rules 陣列中的一個元素，並非完整設定。本文的 example.com 網域僅用於說明語法，實際使用時請替換成目標網域。
{
"type": "field",
"domain": ["domain:example.com"],
"outboundTag": "proxy"
}type: "field"：依連線屬性比對。domain：網域條件陣列；ip則用來指定 IP 位址、網段或 IP 分類。outboundTag：參照已存在的出站標籤，不會建立新的出站。- 同一欄位中的多個項目通常是「或」；同一條規則中的不同條件欄位則是「且」。
例如，將 domain 和 port: "443" 放在同一個物件中，表示網域符合且目標連接埠為 443 時才會命中，並非符合其中一項就生效。若要設定「網域符合或 IP 符合」，通常應拆成兩條規則，而非將兩個欄位放進同一條規則。
二、如何選擇 domain、full、regexp
domain 既是 JSON 欄位名稱，也是欄位內的一種比對前綴，兩者不要混淆。欄位中的一般字串預設採子字串比對，範圍往往比預期更廣；若要明確比對某個網站及其子網域，優先使用 domain:。
| 寫法 | 比對範圍 | 使用提醒 |
|---|---|---|
full:api.example.com | 僅限此完整網域 | 不包含其下層子網域 |
domain:example.com | 根網域及其子網域 | 不會比對 notexample.com |
example.com | 網域中包含這段字串 | 比對範圍可能過廣 |
regexp:... | 符合正規表示式的網域 | 留意錨點與 JSON 跳脫 |
geosite:cn | 網域資料庫中的 cn 分類 | 依據已載入的資料庫內容 |
網域欄位不支援網頁路徑語意。若要比對 https://api.example.com/v1/items，應填入 full:api.example.com，不要把通訊協定、斜線與路徑一併貼上。一般路由也無法透過這個欄位區分同一個 HTTPS 網站的不同頁面路徑。
{
"type": "field",
"domain": [
"full:api.example.com",
"domain:static.example.com",
"regexp:^edge[0-9]+\\.example\\.net$"
],
"outboundTag": "proxy"
}這三個條件是「或」：符合任一項就會選擇代理。正規表示式可用來比對 edge1.example.net、edge23.example.net 這類帶編號的網域。JSON 中的 \\. 經解析後才會成為正規表示式中的 \.；少寫一層反斜線可能導致解析錯誤或語意改變。
三、ip、geoip 與 geosite 的適用範圍
geosite 用來分類網域，geoip 用來分類 IP，兩者依賴不同資料，不能互換。geosite:cn 不代表「解析結果位於中國大陸的所有網域」；geoip:cn 也不表示伺服器內容一定屬於中國大陸網站。CDN、共用位址與資料庫更新都可能影響比對結果。
網域分類規則
- 欄位
domain- 範例
geosite:cn- 資料來源
- 已載入的 geosite 網域資料庫
- 比對依據
- 連線可取得的目標網域
先確認分類存在，再檢查網域是否收錄其中；分類不會即時自動辨識。
IP 分類規則
- 欄位
ip- 範例
geoip:cn- 資料來源
- 已載入的 geoip 位址資料庫
- 比對依據
- 目標 IP，或路由解析取得的位址
網域連線是否會觸發解析，取決於 domainStrategy 等設定。
明確的區域網路網段可直接使用 CIDR，避免仰賴網站分類來判斷「本機裝置可否連線」。以下將三個常見的 IPv4 私有網段設為直連；這不涵蓋所有特殊用途位址，也未包含 IPv6 本機位址。若需要更完整的範圍，可使用資料庫中的 geoip:private，並確認其中實際收錄的內容。
{
"type": "field",
"ip": [
"10.0.0.0/8",
"172.16.0.0/12",
"192.168.0.0/16"
],
"outboundTag": "direct"
}這些數值是位址與通訊協定的基本參數，並非速度測試結果。連接埠條件使用連線的目標連接埠，例如 "port": "443"，不是 v2rayN 的本機監聽連接埠。只依 443 分流會同時影響許多不同網站，通常應搭配網域等條件使用。
四、優先順序：先命中就停止
規則會依陣列順序由上而下檢查，命中一條後就選擇對應的出站，不會繼續尋找後面「更精確」的規則。完整網域不會自動優先於前面的分類規則，較長的網段也不會自動優先於先出現的短網段。若有精確例外，必須主動放在範圍較廣的規則之前。
- 先放明確例外：例如單獨封鎖某個網域，或指定某個業務網域使用代理。
- 接著放本機連線：讓私有位址直連，減少對區域網路裝置連線的影響。
- 再放分類分流：依 geosite、geoip 等分類處理大部分連線。
- 最後放兜底規則：明確指定其餘 TCP、UDP 連線的處理方式。
以下是完整的 routing 片段，仍須與現有的入站、出站等設定合併。它會先封鎖範例遙測網域，再讓區域網路與 cn 分類直連，最後將其餘流量交由代理處理。刪除不需要的規則時，也請確認 JSON 逗號位置正確。
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"domain": ["full:telemetry.example.com"],
"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"
}
]
}
}沒有規則命中時，通常會使用出站清單中的第一個出站，不一定是名為 proxy 的出站。明確設定兜底規則較容易理解，但也會改變比對行為；刪除兜底規則後，也不能忽略出站順序。若要在代理失敗後自動切換，還需要另外設定策略；一般路由規則不會自動改用下一條規則重試。
五、domainStrategy 決定解析時機
網域規則比對網域，IP 規則比對位址。若應用程式透過代理通訊協定提交的是網域，核心不一定已取得目標 IP。routing.domainStrategy 決定路由階段是否為了比對而解析網域；它不等同於 DNS 伺服器的選擇，也不要與出站中的同名選項混為一談。
| 策略 | 解析時機 | 注意事項 |
|---|---|---|
AsIs | 路由階段不會主動解析網域以供比對 | 純網域目標無法透過解析結果命中 IP 規則 |
IPIfNonMatch | 網域未命中任何規則後，再嘗試解析並重新比對 | 若先命中兜底規則，就不會進行這次額外解析 |
IPOnDemand | 比對過程遇到需要 IP 的規則時，嘗試解析 | 前面的 IP 規則可能增加 DNS 查詢，並使流量提早分流 |
假設某個業務網域必須走代理，就應將它的 full: 或 domain: 規則放在 geoip:cn 之前。使用 IPOnDemand 時，若 IP 分類規則排在前面，網域解析到 cn 位址後可能已被送往直連，後面的網域例外就沒有機會執行。
- 先決定要以「網域分類優先」還是「解析位址優先」，再安排規則順序。
- 檢查核心 DNS 設定中的解析伺服器與分流選項；修改策略不會自動更換解析器。
- 若應用程式自行解析後只提交 IP，網域規則可能無法命中；嗅探有時能取回部分網域資訊，但無法保證涵蓋所有流量。
- 遇到 UDP、加密 DNS 或共用 CDN 位址時，請分別驗證；不能只憑瀏覽器開啟一個網頁，就判定所有設定都正確。
六、在 v2rayN 中套用與驗證
v2rayN 是桌面用戶端，實際規則由所選核心執行。本文介紹 V2Ray/Xray 的 JSON 結構；編輯規則前，請先記下 v2rayN 版本與目前使用的核心。不同版本的編輯入口與欄位名稱可能有所調整，不能將核心 JSON 物件直接貼入只接受網域清單的輸入框。
- 備份目前設定。保留正在使用的路由設定與預設出站。桌面版常見入口為「設定」→「路由設定」；若目前版本的入口不同，請先找出路由設定管理功能，不要藉由修改訂閱網址來調整分流。
- 確認標籤。在設定編輯器或產生的核心設定中查看
outbounds的tag。將範例中的direct、proxy、block對應到實際使用的標籤。 - 先新增一條例外規則。先使用一個完整網域進行測試，並將規則放在分類規則之前。儲存後選取這組路由設定，讓用戶端重新產生設定並重新啟動核心。
- 檢查啟動記錄。確認沒有 JSON 解析錯誤、分類不存在或找不到出站標籤等問題，再進行連線測試。
- 建立新連線進行驗證。關閉舊頁面的連線，再重新發出請求。根據存取記錄中的目標與出站標籤判斷；若目前記錄未顯示這些資訊，可暫時提高記錄詳細程度。
- 逐步擴充規則。確認測試成功後，再新增 geosite、geoip 與兜底規則；每增加一層，都保留可還原的設定。
測試時至少準備三類實際目標：應直連的網站、應使用代理的網站，以及區域網路裝置。若需要封鎖，再加入一個可控的測試網域。規則只會影響進入該核心的連線；若應用程式繞過系統代理，即使規則正確也不會留下比對記錄。可參考系統代理使用說明，確認系統代理的接管範圍。
七、規則未生效的四個常見問題
設定了 full 規則，為什麼還是直連？
先檢查上方是否已有 geosite:cn、geoip:cn 或全流量規則先行命中。將完整網域例外移到這些規則之前，儲存後重新建立連線。接著確認連線實際提交的是網域，而不是應用程式預先解析的 IP。
新增 geosite 後，為什麼核心無法啟動？
檢查記錄是否指出分類不存在或資料檔無法載入。確認目前資料庫包含指定分類，並透過用戶端提供的規則資料更新功能更新。不要只因分類名稱看起來合理就直接使用；先移除新增項目，讓核心恢復啟動，再逐項確認。
網域和 IP 都寫在同一條規則裡，為什麼反而沒有命中？
不同欄位之間是「且」的關係，也可能受到網域解析條件影響。若預期是二選一，請拆成兩條規則，並使用相同的 outboundTag。若確實要求兩者同時符合，請再檢查位址是否可用，以及 domainStrategy 的行為。
修改規則後，為什麼瀏覽器還是走舊路由？
路由通常在建立新連線時決定；已建立的長連線不一定會重新選擇出站。先確認目前選取的是修改後的路由設定，再關閉相關應用程式連線；必要時重新啟動核心後再試。若記錄中完全沒有請求，請確認應用程式是否進入代理入口。
整理設定時，保留少量且容易理解的規則即可：先放精確例外，再放本機位址與分類規則，最後明確指定兜底。遇到問題時，依序檢查「連線是否進入核心、目標是網域還是 IP、哪條規則先命中、標籤是否存在」，比不斷疊加規則更容易找到原因。