V2Ray 自訂路由規則設定：domain、ip、geosite 比對方式與優先順序

本文重點

本文適合已能連線至節點，準備調整直連與代理範圍的使用者。先了解網域與 IP 的比對寫法，再依序安排「局部例外、分類規則、最後兜底」，最後檢查網域解析策略與實際出站。範例採用 V2Fly V2Ray 與 Xray 常見的 field 路由結構；用戶端編輯介面並非完整的核心設定，儲存後還要確認產生的設定內容。

路由規則基礎：比對條件與出站標籤

路由分流會決定連線交由哪個出站處理，不會建立節點，也不會變更節點使用的 VMess 或 VLESS 協定。V2Ray 是核心專案，Xray 是另一個核心專案；v2rayN 則是桌面圖形用戶端，負責將介面設定轉換為所選核心可讀取的設定。

常見規則包含 type: "field"、比對條件與 outboundTag。標籤必須對應 outbounds 中既有的 tag。本文以 proxy、direct、block 分別代表代理、直連與阻擋出站；這些只是範例名稱，不代表每份用戶端設定都採用相同標籤。

同一欄位內通常採「或」：domain 陣列中只要有一個網域條件成立，就符合該欄位。
不同欄位之間採「且」：同一條規則同時填入 domain 與 port 時，網域和目標連接埠都必須符合。
domain 與 ip 並非二選一：將兩者寫在同一條規則中，表示兩個條件都必須符合；若要表示「網域或 IP」，請拆成兩條規則。
連接埠指的是目標連接埠：port: "443" 比對遠端服務連接埠，不是本機代理的監聽連接埠。

10808

本文測試使用的本機 SOCKS 連接埠

443

HTTPS 常見的目標連接埠

/32

IPv4 單一位址的 CIDR 前綴

這些數值只是範例參數，並非測速結果，也不代表用戶端預設值。本機實際監聽連接埠請從設定中確認；HTTPS 也可能使用其他連接埠，不能只憑 443 判斷所有加密流量。

domain 四種比對方式：包含、正規表示式、根網域與完整網域

domain 欄位容易與 domain: 前綴混淆：前者是規則欄位，後者則是欄位內字串的比對模式。四種常見寫法中，一般字串不加前綴，另外三種使用 regexp:、domain:、full:。一般字串不需要為了看起來一致而自行加上前綴。

寫法	比對範圍	使用注意事項
`example.com`	網域中包含這段字串	可能比對到 `notexample.com`，範圍比根網域比對更廣
`domain:example.com`	`example.com` 及其子網域	比對 `www.example.com`，不比對 `notexample.com`
`full:api.example.com`	僅完整網域 `api.example.com`	不包含 `cdn.api.example.com`
`regexp:^api[0-9]+\.example\.com$`	符合正規表示式的完整字串	JSON 中的反斜線需要再次跳脫

日常依網站進行分流時，優先使用 domain:；只為單一介面設定例外時，使用 full:。網域條件只接受網域，不要填入 https://、網頁路徑或查詢參數；路由規則也不會依特定網頁的文章路徑分流。

{
  "type": "field",
  "domain": [
    "full:api.example.com",
    "domain:example.org",
    "regexp:^api[0-9]+\\.example\\.com$"
  ],
  "outboundTag": "proxy"
}

此正規表示式會比對 api12.example.com。開頭的 ^ 和結尾的 $ 用來限定字串邊界，點號前的反斜線則表示實際的點。範例網域僅用於說明語法，實際設定時請換成需要分流的業務網域。

ip、geoip 與 geosite：位址範圍和資料檔案

ip 欄位可填入單一位址、CIDR 網段或 geoip: 引用。192.168.1.10/32 僅涵蓋一個 IPv4 位址，192.168.1.0/24 則涵蓋該網段；IPv6 單一位址可使用 /128。這裡比對的是目標位址；若要比對請求來源，需使用其他對應欄位。

{
  "type": "field",
  "ip": [
    "192.168.1.0/24",
    "geoip:private"
  ],
  "outboundTag": "direct"
}

geoip:private 用來引用資料檔案中的私有位址分類，geoip:cn 則引用其中的中國 IP 分類。它們不是即時定位服務，實際範圍取決於載入的 geoip.dat。網路歸屬與資料更新時間都可能影響判斷，不能將分類比對結果直接視為伺服器的實際所在地。

geosite 放在 domain 中：例如 "domain": ["geosite:cn"]，會讀取網域分類，而非 IP 分類。
geoip 放在 ip 中：例如 "ip": ["geoip:cn"]，會讀取位址範圍，無法用來比對網頁網域文字。
分類必須存在：geosite:category-ads-all 是部分常用資料集提供的廣告分類，但並非所有資料檔案都包含此分類。
屬性篩選取決於資料：geosite:geolocation-!cn 及帶有 @ 的分類寫法，都需要確認目前使用的檔案是否提供相應分類或屬性，不能只看名稱猜測其含義。

規則優先順序：先比對到的規則先生效

規則會依 rules 陣列由上而下檢查；命中第一條符合條件的規則後，連線就會交由對應出站處理。並沒有「完整網域天生優先於 geosite」或「IP 規則天生優先於網域規則」的排序機制；前面的寬泛規則也可能先攔截符合精確條件的流量。

先放局部例外：若指定某個完整網域必須走代理，請先放入 full: 規則。
接著放業務分類：再加入需要代理或阻擋的網域分類，以及一般直連分類。
依目的安排 IP 規則：區域網路位址通常設為直連，但它與網域規則的先後順序，需配合解析策略決定。
最後放兜底規則：沒有規則符合時，通常會使用 outbounds 陣列中的第一個出站；若要明確指定結果，可在最後加入涵蓋目標連接埠範圍的規則。

以下是一段 routing 設定範例，並非可直接執行的完整檔案。它要求已有 proxy、direct、block 三個出站，且資料檔案包含引用的分類。若實際標籤與用戶端產生的名稱不同，請先修改標籤。

{
  "routing": {
    "domainStrategy": "IPOnDemand",
    "rules": [
      {
        "type": "field",
        "domain": ["full:api.example.com"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "port": "1-65535",
        "outboundTag": "proxy"
      }
    ]
  }
}

此範例會先處理完整網域例外，再處理私有位址。由於使用 IPOnDemand，檢查前面的 IP 規則時可能會進行解析。廣告分類放在私有位址規則之後，代表私有位址具有較高優先順序；若業務需求是優先阻擋該分類，就必須調整規則順序，而不是期待核心自動判斷規則的重要性。

domainStrategy：何時解析網域以參與比對

路由中的 domainStrategy 會控制是否將網域解析為 IP，以協助路由判斷；它不等同於 DNS 伺服器設定，也不等同於直連出站中名稱相同的選項。連線一開始提供的是網域還是 IP，也會影響可使用的比對條件。

AsIs

建議

路由階段不會主動將網域解析為 IP。網域目標主要依靠 domain、geosite 等規則；目標原本就是 IP 時，仍可比對 IP 規則。適合作為行為明確的網域分流基礎設定。

適用情境：以網域規則為主，初次檢查比對順序

IPIfNonMatch

網域在第一輪沒有符合規則時，會嘗試解析後再比對。如果前面已有一條可命中的連接埠兜底規則，可能會在第一輪直接結束，不再進行解析後的比對。

適用情境：網域規則未命中後，再以 IP 分類判斷

IPOnDemand

檢查規則時遇到需要判斷 IP 的條件，便會依需求解析網域。較前面的 IP 規則可能影響後續網域分類是否會被檢查，因此必須一併規劃 DNS 行為與規則順序。

適用情境：明確需要 IP 分類參與網域目標分流

結論：先決定解析時機，再設定兜底

若選擇 IPIfNonMatch，請勿同時加入一條第一輪必定命中的通用連接埠兜底規則，並期待後續 geoip 規則生效；可讓第一個出站承接預設流量，或重新安排策略。若需要在最終兜底前先判斷 IP，再評估 IPOnDemand 與實際 DNS 設定。

如果應用程式直接連線至 IP，核心一開始就沒有可供 domain 比對的網域。在支援的流量上，嗅探可以擷取網域，但並非所有協定都能擷取，也無法完整還原網域。DNS 查詢本身從哪裡送出，還需查看核心 DNS、出站與用戶端模式，不能只靠變更路由策略推斷。

v2rayN 設定步驟：編輯後確認實際設定

v2rayN 的路由編輯介面會隨版本更新而調整。桌面版通常可從「設定」→「路由設定」進入；若目前介面不同，請先記下「說明」→「關於」中的版本資訊，再依照對應版本的介面操作。請勿將本文的核心 JSON 整段貼入只接受網域清單的輸入框。

記錄目前設定

在「說明」→「關於」記下用戶端版本，並在「設定」→「參數設定」確認使用中的核心與本機監聽連接埠。先備份現有路由內容，確認目前模式確實使用自訂路由，而非直接切換為全域代理。
加入例外規則

進入「設定」→「路由設定」，編輯目前使用的路由規則集。先加入一個實際業務網域的 full: 條件，選擇目標出站，並將規則放在寬泛分類規則之前。
檢查策略

在路由設定中確認 domainStrategy，並檢查網域陣列、IP 陣列與出站標籤。使用分類規則時，請確認目前的核心能否載入對應的 geosite、geoip 資料檔案。
重新啟動並驗證

儲存並啟用修改後的規則集，重新啟動目前的核心連線。確認實際產生的設定中規則順序正確，再送出新的請求並查看日誌；既有連線通常不會因規則變更而重新選擇出站。

v2rayNG 在 Android 上使用 Xray 核心，v2flyNG 則使用 V2Fly 核心。即使基礎規則格式相近，各用戶端可編輯的欄位、匯入入口與資料檔案管理方式仍可能不同。移轉時請確認欄位是否支援，不要將桌面用戶端的整份設定檔當成通用核心設定。

路由未生效疑難排解：請求入口、資料與日誌

「網站能開啟」只能證明連線成功，無法證明使用了正確的出站。驗證時，請分別對一個完整網域、一個區域網路目標及一個分類內的目標發起新連線。先確認流量有進入核心，再檢查規則命中情況與出站標籤，最後確認 DNS 與分類範圍。

現象	優先檢查項目	處理方式
完整網域例外仍走直連	前面是否已有 geosite 或連接埠規則命中	將該條 full 規則移至相關寬泛規則之前，並建立新連線
geoip 對網域目標不起作用	AsIs 或 IPIfNonMatch 的解析條件	確認策略，並檢查是否被第一輪兜底規則提前命中
啟動後立即報錯	JSON、分類名稱、資料檔案、出站標籤	先移除新增的分類引用，改用一條 full 規則縮小問題範圍
瀏覽器與命令列結果不同	是否使用相同代理入口，以及是否在本機解析	明確指定相同的 SOCKS 入口，比對網域與 IP 請求
變更規則後結果沒有改變	目前使用的規則集、核心是否重新啟動，以及連線重用情況	確認啟用的是修改後的規則集，關閉舊連線再測試

若本機提供 SOCKS 入站，且監聽連接埠確實為範例中的 10808，可使用以下指令。socks5h 會讓 curl 將網域交給代理端，而不是先在本機解析；這能減少測試入口的差異，但不代表核心不會依照自身的 DNS 設定繼續解析。

curl --proxy socks5h://127.0.0.1:10808 --head https://example.com/

先確認入口：未進入核心的請求不會受到其路由規則影響。系統代理也不保證所有程式都會遵循該設定。
接著檢查日誌：短暫啟用適當的存取日誌或更詳細的日誌，留意目標位址、入站與出站標籤；疑難排解完成後，請恢復日常日誌層級。
最後縮小規則範圍：保留一個網域條件與一個明確的出站，確認成功後再逐項恢復分類與 IP 條件，避免同時變更多個變因。

分享日誌前，請遮蔽訂閱網址、節點憑證與業務網域等敏感資訊。若要了解用戶端、核心與出站的差異，可查看術語表；若要從連線入口重新確認設定，請從快速入門開始。