進階設定 預計閱讀 12 分鐘

Xray 路由規則深入解析：JSON 設定與自訂分流實戰

掌握 Xray-core 路由引擎的規則優先順序、domainStrategy、geosite 與 geoip 用法，透過可直接套用的 JSON 範例建立自訂分流。文章同時整理 DNS 防洩漏、規則集維護、日誌除錯與模組化管理方法，適合需要精細控制連線行為的進階使用者。

在 Xray 中，routing 不只是「國內直連、海外代理」的一行開關，而是一套按照請求特徵依序比對的決策流程。網域名稱、目標 IP、連接埠、傳輸協議、來源入站與使用者標籤，都可以成為分流條件。規則寫得越多，不代表效果越好；如果順序混亂、出站標籤不存在，或 DNS 解析方式與路由條件不一致，常見結果就是部分網站打不開、規則沒有命中，甚至所有流量都落到最後的代理出站。

本文速覽

本文從 Xray 的 routing.rules 執行順序開始，逐項說明 domainStrategy、domain、ip、port 與 outboundTag 的配合方式，再以直連、代理、阻擋及 DNS 分流範例示範可維護的 JSON 架構，適合想在 v2rayN、v2rayNG 或其他 Xray 核心客戶端中自訂分流的使用者。

先理解 routing 的決策流程

Xray 收到應用程式連線後，會先由入站接收請求，再依據請求中的目標網域、IP、連接埠及其他資訊檢查路由規則。routing.rules 通常採用由上至下的順序，一旦某條規則符合，Xray 就會把請求交給該規則指定的出站。後面的規則不會再被檢查，因此「先寫什麼」比「寫了多少」更重要。

應用程式發起請求入站接收流量規則依序比對選擇出站建立遠端連線

例如，阻擋廣告的規則應放在一般代理規則之前；區域網路直連規則應放在「所有網域代理」之前；最後才使用兜底代理或直連。若先寫一條只要有網域就送往代理的規則，後面的 geosite:cn 直連規則就不可能生效。

  • domain：依完整網域、關鍵字、正規表示式或內建規則集匹配。
  • ip：依 IPv4、IPv6、CIDR 或 geoip 規則集匹配。
  • port：依目的連接埠或連接埠範圍匹配，例如 80、443 或 1000-2000。
  • network：限制 tcp、udp，或同時符合兩者的請求。
  • inboundTag：只處理來自特定入站的流量，適合區分透明代理、Socks 或 HTTP 入站。
  • outboundTag：命中後交給指定出站；標籤必須與 outbounds 中的 tag 完全一致。

結論：先設計優先級，再補規則

一個容易排錯的路由表，通常遵循「本機與區域網路 → 阻擋 → 特定直連 → 特定代理 → IP 分流 → 兜底」的順序。先畫出決策樹，再把每個節點寫成 JSON，會比直接複製大量規則更可靠。

domainStrategy 會改變 IP 規則的命中方式

routing.domainStrategy 決定 Xray 面對網域目標時，是否以及何時把網域解析成 IP，再繼續檢查 ip 規則。最常見的三個值是 AsIs、IPIfNonMatch 與 IPOnDemand。它們不是 DNS 伺服器設定，也不會直接決定請求使用哪個出站；它們控制的是路由比對階段的解析策略。

AsIs

網域處理
優先保留原始網域
解析時機
不為 IP 規則主動解析
適合情境
以網域規則為主

設定簡單、查詢較少，但依 IP 的規則可能無法命中。

IPIfNonMatch

第一次比對
先檢查網域規則
解析時機
網域未命中後再解析
適合情境
網域與 geoip 混合分流

通常是一般分流設定較容易理解的起點。

以 IPIfNonMatch 為例，若請求目標是 example.com，Xray 會先檢查網域規則。若已命中 domain:example.com 或 geosite:cn，就直接選擇對應出站；若沒有命中，才可能解析網域並用取得的 IP 繼續檢查 geoip 或 CIDR 規則。這樣可以降低不必要的 DNS 查詢，同時保留依 IP 判斷的能力。

IPOnDemand 會在路由判斷需要 IP 時較早觸發解析。它不是「速度更快」的設定，解析請求本身也可能受 DNS 可用性、代理路徑及 IPv4/IPv6 條件影響。若使用者只想依網域分流，卻啟用會觸發大量解析的策略，可能增加延遲與排錯複雜度。修改後應配合核心日誌與實際網站測試，不要只依名稱猜測行為。

策略優先比對主要優點注意事項
AsIs原始網域流程直觀、解析需求低依 IP 的規則可能不會發揮作用
IPIfNonMatch先網域、後 IP兼顧 geosite 與 geoip未命中的網域需要可用 DNS
IPOnDemand依判斷需要提早解析適合強依賴 IP 條件的設計可能增加解析量與診斷難度

rules 的欄位與順序設計

一條路由規則可以同時包含多種條件，但這些條件通常是「同一條規則內全部符合」才算命中。例如同時寫入 domain、port 與 network，代表只處理指定網域、指定連接埠與指定網路類型的請求。條件越多，範圍越窄；如果實際請求沒有網域資訊，單純依 domain 的規則就不會命中。

以下是一個可作為骨架的設定片段。假設已經在 outbounds 中建立 proxy、direct、block 與 dns-out 四個標籤，路由規則便可以只負責描述「什麼流量交給誰」。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "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",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

這個範例的最後一條是兜底規則：只要是 TCP 或 UDP，就交給 proxy。它必須放在私有 IP、廣告網域及中國大陸網域規則之後，否則前面的分流沒有機會生效。若你的預期是「未命中時直連」，可以把最後的 outboundTag 改為 direct，但要先確認這符合實際需求。

推薦方案：先固定出站，再逐層增加條件

簡單分流
  • 私有 IP 直連
  • 中國大陸網域直連
  • 其餘流量代理
進階分流
  • 先阻擋廣告與追蹤
  • 再分 DNS 與服務類型
  • 最後處理 IP 與兜底

先讓三種基本結果「直連、代理、阻擋」各自可測試，再加入更多規則集，排錯成本最低。

動手建立自訂路由 JSON

修改前先備份目前使用的設定，並記下客戶端使用的核心類型與版本。以 2026 年常見的 Xray 核心配置為例，v2rayN 可在目前設定或核心設定入口查看並編輯 JSON；v2rayNG 則應透過目前設定的自訂配置或進階設定確認最終合併結果。不同客戶端可能會把訂閱產生的基礎設定與自訂規則分開保存，因此不要直接覆寫原始訂閱內容。

  1. 備份設定

    複製目前 JSON 至獨立檔案，保留核心類型、入站連接埠與原有出站標籤。常見本機 HTTP 或 Socks 入站可能使用 10809，但實際數值應以客戶端畫面為準。

  2. 確認出站

    檢查 outbounds 是否真的存在 proxy、direct、block 等 tag。路由只引用不存在的標籤時，核心會報錯或無法依預期轉送。

  3. 加入私有直連

    把 geoip:private 放在前面，避免路由器管理頁面、區域網路儲存裝置或本機服務被錯誤送往遠端代理。

  4. 加入網域分流

    依序加入阻擋、特定直連及特定代理規則。每次新增一組規則後先驗證 JSON，再測試一個已知網域。

  5. 測試並記錄

    重新載入核心，檢查路由日誌、DNS 日誌與目標網站結果。確認無誤後才加入下一組外部規則集或更精細的連接埠條件。

測試時不要同時變更節點、DNS、TUN 模式與路由規則。可以準備四個測試目標：一個區域網路位址、一個應被阻擋的廣告網域、一個預期直連的網域，以及一個預期代理的網域。若只有最後一個測試失敗，先檢查代理出站；若所有網站都失敗，則應先確認入站連接埠、系統代理或 TUN 接管是否正常。

外部規則集與 DNS 分流如何配合

geosite 與 geoip 是 Xray 常見的內建規則集引用方式。geosite:cn 主要用於網域分類，geoip:cn 則用於 IP 範圍分類；兩者不是同一份資料，也不保證每個網站都能被同時正確分類。某個網域可能使用境外 CDN 位址，因此命中 geosite:cn 與命中 geoip:cn 的結果不一定相同。

如果配置使用外部規則檔或核心支援的 rule set，應確認檔案格式、載入位置、核心版本與更新時間。規則集更新後，分類結果可能改變；排查時要記錄「核心版本、規則檔版本或更新日期、命中的規則名稱」，不要只說「昨天還能用」。大型規則集也可能增加啟動時間與記憶體使用，行動裝置尤其應避免同時載入多份內容高度重複的清單。

DNS 分流則要與路由目的保持一致。可以讓中國大陸網域使用本地 DNS，海外網域使用遠端 DNS；但 DNS 查詢本身應使用正確的 dns-out 出站，且 DNS 伺服器網域的解析不能形成循環依賴。若採用內建 DNS 的路由分流，常見做法是把 DNS 請求送往專用出站，再用路由規則對一般業務流量做直連或代理判斷。

{
  "dns": {
    "queryStrategy": "UseIPv4",
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": [
          "geosite:cn"
        ]
      },
      "https+local://1.1.1.1/dns-query"
    ]
  },
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "inboundTag": [
          "dns-in"
        ],
        "outboundTag": "dns-out"
      }
    ]
  }
}

上面的 dns-in 必須真的存在於入站設定，否則這條規則不會命中。某些客戶端會自行產生 DNS 入站或改寫 DNS 配置，不能直接照搬範例。若使用 TUN 模式，還要確認 DNS 劫持、FakeDNS、IPv6 查詢及路由策略沒有互相衝突；遇到「瀏覽器能開、部分應用程式不能開」時，應比較不同應用程式使用的解析方式。

常見失敗現象與排錯方法

路由排錯的第一步是確認設定是否能被核心載入，第二步是確認請求是否進入預期入站，第三步才是檢查規則命中結果。不要看到網站無法開啟就立刻把所有規則刪除。保留最小可用版本，逐條加入規則，通常比反覆切換全域代理與規則代理更容易找到原因。

為什麼 geosite:cn 沒有命中？

先確認 Xray 核心能載入對應的 geosite 資料，再檢查請求是否保留網域名稱。若應用程式只提交 IP，網域規則自然無法命中，此時需要檢查 DNS、domainStrategy 或改用 IP 規則。

最後的代理規則會不會攔截前面的直連？

正常不會。Xray 規則是由上至下比對，前面規則命中後就停止；但若前面的條件寫錯、出站標籤拼寫不一致，實際請求便可能落到最後的兜底規則。

加入 geoip 後網站反而變慢，怎麼查？

檢查 domainStrategy 是否觸發額外解析，並確認 DNS 查詢可用。先暫時移除 geoip 規則，只保留網域分流測試；若恢復正常，再逐條加入 IP 條件。

JSON 看起來正確，核心仍然啟動失敗？

使用核心提供的設定檢查功能，確認逗號、括號、重複欄位及出站 tag。也要檢查某些欄位是否屬於目前 Xray 版本支援的格式，不要只依其他核心的範例判斷。

若日誌顯示找不到目的地、解析逾時或出站不存在，應分別處理。目的地錯誤通常指向網域、IP 或 DNS；解析逾時要檢查 DNS 伺服器與 DNS 出站；出站不存在則是 outboundTag 與 outbounds[].tag 不一致。把錯誤類型對應到正確層級，可以避免為了修路由而誤改節點參數。

  • 先用單一節點測試，不要讓自動選擇節點干擾結果。
  • 暫時保留三條規則：私有 IP 直連、已知網域代理、最後兜底直連。
  • 使用核心日誌確認請求目標、解析結果及選用的出站標籤。
  • 修改後重新載入配置，確認客戶端沒有繼續使用舊的快取設定。
  • 規則集更新後重新測試代表性網域，並記錄變更前後差異。
下載v2rayN