從規則比對順序開始，說明 Xray 的 routing.domainStrategy 如何影響網域與 IP 規則，再拆解 DNS 解析和代理分流的關係。文中提供可改寫的 JSON 片段、設定步驟與記錄檢查方向，適合想自行掌握不同網域走直連或代理的使用者。範例中的出站標籤與網域分類須依自己的設定調整，不能直接當成完整設定檔使用。
先理解 routing：規則由上往下比對
Xray 的路由功能會依照 routing.rules 中的順序檢查連線，再將符合條件的流量交給指定出站。常見條件包括網域、目的 IP、連接埠、網路類型、入站標籤及協定等。通常第一條符合的規則就決定出站；因此，規則排列不是單純的清單順序，而會直接改變流量走向。
例如，某個網域同時符合「指定網域走代理」和「區域網路 IP 直連」兩條規則，最終結果取決於 Xray 在該次連線中能比對到哪些條件，以及哪條規則先符合。一般會將範圍較窄、優先權較高的規則放前面，再放較廣泛的規則，最後才設置預設出站。
| 規則條件 | 比對對象 | 常見用途 | 注意事項 |
|---|---|---|---|
domain | 連線可辨識的網域名稱 | 指定網域直連或交給代理 | 若連線只提供 IP，可能沒有可供網域規則比對的名稱 |
ip | 目的 IP 位址或 IP 分類 | 區域網路直連、指定網段分流 | 以網域建立連線時，是否解析後再比對受 domainStrategy 影響 |
port | 目的連接埠或連接埠範圍 | 依服務使用的連接埠分流 | 連接埠條件不代表協定內容一定符合預期 |
inboundTag | 流量進入 Xray 時使用的標籤 | 讓不同入站使用不同路由 | 標籤須與實際入站設定一致 |
outboundTag | 指定符合規則後使用的出站 | 選擇代理、直連或封鎖出站 | 標籤必須對應已存在的出站設定 |
網域規則常見寫法包括完整網域、網域後綴與預先定義的網域分類；例如 domain:example.com 用於比對指定網域及其子網域。IP 規則則可使用單一 IP、CIDR 網段或可用的 IP 分類。分類資料依賴 Xray 可讀取的資料檔，若規則引用了本機沒有的分類資料，可能無法依預期比對。修改規則前，先確認目前使用的核心版本、資料檔及標籤名稱。
AsIs、IPIfNonMatch、IPOnDemand 三種策略domainStrategy 的三種行為與適用情境
domainStrategy 是路由設定中的解析策略，主要影響 Xray 何時將連線中的網域解析成 IP，以便檢查 IP 類型的路由條件。它不等於 DNS 伺服器選擇，也不會單獨決定所有 DNS 請求要走代理或直連。不同核心版本與連線情境可能影響可取得的網域資訊，應以啟動記錄及實際測試結果確認。
| 值 | 比對方式 | 適合情境 | 可能的取捨 |
|---|---|---|---|
AsIs | 保留原有網域資訊，不為了 IP 規則主動解析網域 | 以網域規則為主，或希望避免路由階段額外解析 | 只有 IP 規則時，網域請求未必能依解析出的目的 IP 分流 |
IPIfNonMatch | 先以現有資訊比對；沒有規則符合時，再解析網域並嘗試 IP 規則 | 網域規則優先、IP 規則作為補充的常見設定 | 若網域規則已符合，後續不會為了較後面的 IP 規則再做同一輪解析判斷 |
IPOnDemand | 比對流程遇到 IP 條件時，按需要解析網域以供 IP 規則判斷 | 希望 IP 規則參與網域連線判斷的設定 | 解析時機更積極；仍須確認 DNS 可用及規則先後順序正確 |
選擇時可先問：路由規則是否真的需要依目的 IP 分流？如果主要需求是按網域名稱選擇出站，使用網域規則通常較直觀；若還要將解析後的區域網路位址導向直連，才需要確認 IP 比對及解析策略是否配合。將策略改為會解析 IP 的模式，不會自動補上缺少的 DNS 伺服器，也不會修正錯誤的網域規則。
先定義主要判斷條件，再選解析策略
以網域分流為主
- 先建立具體的網域規則。
- 將常用網域規則放在廣泛規則之前。
- 依需求選擇不額外解析的策略或作為補充的解析策略。
需要 IP 規則參與
- 確認 DNS 能解析目標網域。
- 使用適合的解析策略，讓 IP 條件有機會比對。
- 測試網域解析到不同 IP 時的路由結果。
domainStrategy 是路由比對的解析時機設定；DNS 伺服器如何解析，仍由 DNS 區塊與實際請求路徑共同決定。
也要留意網域資訊可能來自應用程式原本使用的網域，也可能在核心支援並啟用相應嗅探功能時，從連線資訊中辨識。直接以 IP 位址連線、加密連線中無法取得所需資訊，或應用程式使用自訂解析方式，都可能令網域規則與預期不同。不要只憑某個網站開啟成功，就推定所有網域和 IP 規則均已驗證。
動手設定：先備份，再逐項驗證
以下以 Xray 常見 JSON 欄位示範路由骨架。proxy、direct 是範例標籤，必須與你的 outbounds 標籤一致；example.com 是示意網域。將片段合併進現有設定時，保留原有入站、出站及其他路由規則，不要把此範例整段覆蓋成完整設定。
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"domain": ["domain:example.com"],
"outboundTag": "proxy"
},
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
}
]
}
}上例的網域規則放在區域網路 IP 規則之前。這種順序代表網域條件先取得比對機會；若某次連線符合前面的規則，就不應假設後面的規則還會覆寫出站。若需求是讓區域網路位址無論網域如何都直連，應先釐清這個優先權，再調整規則位置，並用實際解析結果驗證，而非只改 domainStrategy。
-
備份目前設定
複製正在使用的 JSON 設定，記下目前核心與版本，並確認變更後能還原。若由用戶端產生設定，先確認修改來源，避免下一次套用節點時自訂內容被覆寫。
-
核對出站標籤
檢查
outbounds中是否存在範例使用的proxy、direct標籤。實際設定可能使用其他名稱；路由標籤拼錯或不存在時，不能得到預期出站。 -
加入路由規則
先加入一條容易驗證的網域規則，再加入必要的 IP 規則。將具體條件放前面，避免在測試階段同時引入大量分類規則，難以判斷是哪一條造成結果差異。
-
設定解析策略
在
routing區塊設定適合需求的domainStrategy。例如先用IPIfNonMatch驗證「網域規則未符合時，IP 規則能否作為補充」；若需求不同，應依前節差異選擇，而不是把某個值當成通用最佳設定。 -
重載並測試
依用戶端提供的方式重新載入或重新啟動 Xray，先檢查核心記錄有沒有 JSON 解析錯誤。接著以固定的網域分別測試預期代理與直連的路徑，並記錄使用的網路、時間與結果。
DNS 設定與路由規則是互相關聯、但作用不同的部分。DNS 區塊負責指定核心如何取得網域解析結果及使用哪些 DNS 伺服器；路由規則則決定連線交給哪個出站。舉例來說，路由設定讓網域走代理，不代表 DNS 查詢必定也經同一個代理出口；反過來，指定某個 DNS 伺服器，也不等於所有到該網域的應用程式連線都會走代理。
{
"dns": {
"servers": [
{
"address": "223.5.5.5",
"port": 53,
"domains": ["geosite:cn"]
},
{
"address": "1.1.1.1",
"port": 53,
"domains": ["geosite:geolocation-!cn"]
}
]
}
}這段 DNS 內容只示範按網域分類指定解析伺服器，並非任何環境都能直接使用的完整範本。使用 geosite 分類前，要確認核心所需的網域資料可用，且分類名稱符合目前資料檔。DNS 伺服器的可達性、網路政策和核心支援的設定欄位也會影響結果。若使用加密 DNS 或其他特殊伺服器格式，應依實際核心文件核對欄位，不要只替換伺服器位址而忽略傳輸格式。
驗證流量路徑：以結果和記錄交叉判斷
測試時一次只改一個條件，並選擇可重複的目標。先確認 DNS 是否能取得預期解析結果，再確認路由規則將請求交給哪個出站。若同一網域可能解析到多個 IP，應重複測試並記錄解析結果；否則可能把不同 IP 導致的路由差異誤認為規則偶爾失效。
- 預期走代理，實際卻直連：查看網域規則是否在更早的規則已被截走、出站標籤是否正確，以及應用程式是否真的連到本機 Xray 入站。
- IP 規則沒有生效：確認目標是否以網域發起連線、核心是否取得可用解析結果，以及目前策略是否會在此比對情境解析網域。
- 網域規則沒有生效：確認 Xray 是否取得網域名稱；若應用程式直接連 IP，或網域格式與規則不相符，僅調整 DNS 伺服器不一定能補回網域條件。
- DNS 解析成功但連線失敗：分別檢查解析結果、路由出口和遠端連線。解析成功只能證明取得了位址，不能證明出站、伺服器或目標服務都可用。
- 重新啟動後設定失效：確認修改的是實際載入的設定檔，而不是用戶端暫存或自動產生的另一份檔案；同時查看重啟後核心記錄中的設定路徑及錯誤訊息。
設成 IPIfNonMatch，IP 規則還是沒命中？
先確認前面的網域規則是否已符合，再查看解析結果及 IP 規則內容。此策略不是「所有請求一律先解析」，規則順序仍會影響判斷。
指定 DNS 伺服器後，流量就會走代理嗎？
不一定。DNS 伺服器選擇負責解析請求；應用程式連線使用的出站仍要由路由規則與實際入站決定，兩者須分開驗證。
用 IP 開網站時，網域規則會命中嗎？
不能假設一定會。先檢查請求是否帶有可辨識的網域資訊，以及核心是否啟用了適用的嗅探功能；再對照路由記錄確認。
應該先改 DNS 還是 domainStrategy？
先確認問題是「無法取得解析結果」還是「解析後沒有選到預期出站」。前者檢查 DNS 路徑，後者檢查策略、規則順序和標籤。
如果記錄沒有提供清楚的路由命中資訊，可先縮小測試設定，只保留一條目標網域規則與一個預期出站，確認結果後再逐條加回其他規則。每次變更都記錄設定差異，並保留可還原的備份。不要同時更改 DNS 伺服器、路由順序、核心版本和節點參數；多項變更一起發生時，失敗結果很難定位。
整理設定時，建議為每條規則寫下用途、預期出站與測試目標。當訂閱更新、核心升級或分類資料改變時，按清單重測關鍵網域，比單純依賴「之前能用」更可靠。若由 v2rayN 等用戶端管理 Xray，還應確認目前所選核心確實是 Xray，並查看其實際載入設定；客戶端介面上的規則選項不一定等同於手動編輯的完整 JSON。