2026-10-28 · 協定選型 · 約 10 分鐘

Xray 路由规则怎么匹配？domainStrategy 与 JSON 进阶设定

Xray 自訂路由規則為何沒有照預期分流？本指南從規則比對順序、domainStrategy 的解析方式到 DNS 與 IP 條件逐一說明，並附上可直接套用的 JSON 範例。也整理常見誤判情境與檢查方向，協助你打造清楚、好維護的代理路由設定。

本文重點

Xray 路由會依規則清單由上而下比對；一條規則中的多種條件通常須同時符合，符合後便採用指定的出口。理解 domainStrategy，要先分清網域比對、IP 比對與 DNS 解析各自的作用。本文說明網域規則寫法、三種解析策略的差異，並以 Xray JSON 範例示範如何安排直連、私有 IP 與預設代理出口，適合想自行維護進階分流的使用者。

路由規則怎麼匹配：順序與條件是關鍵

Xray 路由不是看到某個條件就自動選擇「最精確」的規則，而是依 routing.rules 陣列的排列順序逐條檢查。第一條符合的規則會決定這次連線交給哪個出口；後續規則不會再覆蓋已選定的結果。因此，特定網域、私有網路等較窄的條件，通常要放在範圍較廣的規則之前。

每條規則可包含 domain、ip、port、network、protocol、inboundTag 等欄位。若同一條規則同時指定網域與連接埠，兩種條件都要符合；同一欄位中的多個值則可用來列出多個候選目標。實際測試時，除了檢查規則是否命中，也要確認 outboundTag 對應到現有出口的 tag，拼字或大小寫不一致都可能造成設定錯誤。

應用程式請求 取得目標資訊 依序比對規則 選定出口標籤 建立遠端連線

domain 欄位常見寫法包括 domain:example.com、full:host.example.com、keyword:example 及 regexp:...。其中 domain: 用於符合指定網域及其子網域；full: 用於精確比對完整網域名稱。使用較寬鬆的 keyword: 或正規表示式時，應仔細檢查是否意外涵蓋其他網域，避免把不相關的流量導向直連或代理出口。

條件欄位常見用途容易忽略的細節
domain依網域名稱分流，例如指定內部網站直連若請求只有 IP，核心不一定取得可供比對的網域
ip依目標 IP 或網段分流，例如讓私有位址直連以網域連線時，須考慮是否需要解析出 IP 才能符合規則
port依目標連接埠分流，例如處理 TCP 443連接埠條件不等同於網域或協定條件
inboundTag只對指定入口送入核心的流量套用規則標籤必須與實際 inbound 設定完全一致
outboundTag指定命中後使用的出站必須指向已設定的 outbound 標籤

domainStrategy 的三種策略與 DNS 關係

routing.domainStrategy 控制路由在檢查 IP 規則時如何處理網域名稱，並不負責指定要向哪個 DNS 伺服器查詢。DNS 伺服器、DNS 路由與網域解析結果，仍須依核心的 DNS 設定及實際流量路徑另行確認。即使網域能解析，也不代表某條網域規則必然命中；反過來，使用 IP 直連的應用程式也可能沒有原始網域可供比對。

AsIs

路由用途
依請求原有的網域或 IP 資訊比對
解析行為
不因路由策略主動把網域解析成 IP 來匹配 IP 規則
適合情境
主要以網域規則分流，且希望避免額外解析

若規則只寫 IP 網段，網域請求可能無法按預期命中。

IPOnDemand

路由用途
遇到需要 IP 條件的規則時再嘗試解析網域
解析時機
比對流程進入 IP 條件時
適合情境
網域與 IP 規則並用，並需讓 IP 規則參與分流

解析可協助匹配 IP 網段，但不會替代完整的 DNS 設定。

另一種策略是 IPIfNonMatch：先依現有資訊比對規則；若沒有規則命中，才嘗試解析網域並再次檢查 IP 條件。它適合希望先讓明確網域規則優先、再以解析所得 IP 補充判斷的情況。請勿把三種模式視為「解析速度」等級；它們的差異在路由比對時機與依據，實際解析結果仍可能受 DNS 設定、快取及網路環境影響。

判斷重點：先確認規則需要哪種目標資訊

主要以網域分類時，先確認請求保留了網域名稱；使用 geoip 或 CIDR 網段時，再決定是否需要 IPOnDemand 或 IPIfNonMatch。不要只為了「讓 DNS 正常」而任意更改路由策略。

JSON 設定範例：網域、私有 IP 與預設代理

以下範例示範：指定的內部網域直連、私有 IP 網段直連，其餘流量交由代理出口。範例只展示 routing 區塊，不是可以單獨啟動的完整設定檔；請將其合併到現有 JSON，並確認設定中確實存在標籤為 direct 與 proxy 的出站。將預設代理放在第一條明確的直連規則之後，可避免未命中前置條件的連線被過早截走。

{
  "routing": {
    "domainStrategy": "IPOnDemand",
    "rules": [
      {
        "type": "field",
        "domain": [
          "domain:intranet.example",
          "full:printer.office.example"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private",
          "127.0.0.0/8",
          "10.0.0.0/8",
          "172.16.0.0/12",
          "192.168.0.0/16"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "outboundTag": "proxy"
      }
    ]
  }
}

此設定使用 IPOnDemand，讓流程進入 IP 條件時才嘗試解析目標網域；如果解析出的位址屬於私有網段，第二條規則會導向 direct。最後一條不設匹配條件，作為明確的兜底規則，因此應放在其他規則之後。若在最前面放入這種無條件規則，後面的網域與 IP 規則便沒有機會執行。

geoip:private 依賴核心可用的 GeoIP 資料；資料檔缺失、版本過舊或實際載入路徑不正確時，相關分類可能無法如預期工作。範例同時列出常見 IPv4 私有網段，方便閱讀與檢查，但這並不代表所有內部網路配置都已涵蓋。若環境使用自訂網段，請加入實際 CIDR，並避免把不熟悉的公網網段誤標為直連。

將內部網域或私有 IP 設為直連前，先確認該連線確實應使用本機網路。若要讓內部服務走代理，應調整對應規則的出口或排列位置，而不是只修改 domainStrategy。

動手操作：安全修改並驗證路由規則

修改前先備份現有設定，並記錄目前 Xray 核心版本、路由模式、DNS 設定與正在使用的出口標籤。若透過 v2rayN 管理核心，應以實際匯出或生成的 Xray JSON 為準；用戶端介面中的選項名稱，未必和核心設定欄位一一對應。一次只修改一項，能降低 JSON 格式錯誤與規則順序變更造成的排查成本。

  1. 備份現有設定

    複製目前使用的 JSON 設定檔，另存一份原始版本。記下 direct、proxy 等出站標籤，以及目標流量目前走的入口，方便設定錯誤時復原。

  2. 整理規則順序

    將精確網域與需要直連的 IP 條件放在兜底規則之前。逐條確認條件是否過於寬泛，並檢查 outboundTag 是否對應現有出站。

  3. 檢查 JSON 格式

    確認字串使用雙引號、陣列與物件括號成對，最後一個欄位後沒有多餘逗號。保存後使用目前版本支援的設定檢查方式或啟動記錄確認核心接受設定。

  4. 逐項驗證命中

    分別測試一個指定網域、一個私有 IP 服務與一個一般外部網站。每次關閉舊連線並重新建立測試連線，再對照核心記錄中的目標及出站資訊。

測試時不要只用網頁是否開啟作為判斷依據：目標服務本身可能不可用，即使路由出口正確也會連線失敗。可以先使用已知可連線的目標建立基準，再逐一替換網域或出口。若系統啟用了連線重用或 DNS 快取，切換規則後也要重新建立連線，避免舊連線被誤認為新規則的結果。

我加了網域規則，為什麼沒有命中？

先確認請求進入 Xray 時仍保留網域名稱，再檢查規則是否排在無條件或廣泛規則之前。若應用程式直接連線到 IP，網域規則通常無法按原樣匹配；可檢查入口的嗅探設定及實際請求資訊。

設定 IP 規則後，網域流量還是走代理？

檢查 domainStrategy 是否會在適當時機解析網域，並確認解析結果確實屬於規則所列網段。若有更早命中的網域規則，或 DNS 解析得到的是公網 IP，私有 IP 規則就不會生效。

改了 outboundTag，核心卻無法啟動？

比對路由規則中的 outboundTag 與 outbounds[].tag，確認兩者完全一致；再檢查 JSON 逗號、括號及欄位型別。恢復備份後一次修正一項，並查看核心啟動記錄中的錯誤位置。

規則不生效時：依序檢查入口、網域與出口

排查時先確認連線是否真的進入 Xray 核心。若應用程式沒有使用系統代理、TUN 或其他已配置的入口，修改路由不會自動接管該應用程式。接著確認核心收到的目標是網域還是 IP、請求是否經過嗅探，以及條件是否能取得所需資訊；最後再核對規則順序與出口標籤。這個順序能避免把入口問題誤判成 domainStrategy 錯誤。

若需要使用 HTTP 或 TLS 嗅探來取得應用程式請求中的網域資訊，應先確認目前入口已啟用相應設定，並留意不同傳輸與加密方式下可取得的資訊有限。嗅探不是 DNS 解析的替代品，也無法保證所有應用程式都會暴露可供匹配的網域。將嗅探、DNS 與路由規則分開檢查，才能定位是哪一層缺少條件。

設定完成後，建議保留一份精簡的規則說明：記錄規則目的、匹配條件、預期出口、測試目標及最後修改日期。日後更新核心、GeoIP 資料或訂閱時，可用同一組目標重新驗證，而不必只憑「網站能不能開」猜測規則是否生效。分流設定的核心原則是先確認入口，再確認匹配資訊，最後核對規則順序與出口。

下載v2rayN