Xray 分流與 DNS 防洩漏設定：JSON 規則實戰解析

先理解分流與 DNS 的關係

在 Xray 設定中，「DNS 解析」和「流量分流」是兩個彼此相關、但不能混為一談的環節。DNS 負責把網域名稱解析成 IP 位址，路由規則則負責判斷一個請求應該代理、直連，還是交給其他出站處理。很多人只在 routing.rules 裡加入幾條網域規則，卻沒有檢查 DNS 請求實際送往哪裡，結果瀏覽器流量雖然走了代理，DNS 查詢卻仍然由本地網路或電信商提供的 DNS 伺服器完成。

這種情況就可能形成 DNS 洩漏。它不一定代表節點或 Xray 失效，而是「名稱解析」和「實際連線」走了不同路徑。例如瀏覽器要求存取某個網域時，本機先向路由器 DNS 查詢，取得 IP 後再把 TCP 或 UDP 流量交給代理。外部觀察者仍可能從 DNS 查詢記錄推測你存取過哪些網域，即使最後的網頁流量已經經過代理。

因此，一份較完整的防洩漏設計，至少要回答三個問題：DNS 請求由誰處理、不同網域使用哪一組解析伺服器，以及解析結果與流量規則是否保持一致。只有把這三層連起來，domainStrategy、DNS 出站、FakeDNS 和 routeOnly 等選項才不會變成互相矛盾的開關。

先設計 DNS 伺服器與解析策略

Xray 的 dns.servers 可以放入多個 DNS 來源。最簡單的寫法是直接填入 IP 位址，例如 1.1.1.1 或 8.8.8.8，但實際部署時不應只追求「伺服器越多越好」。每個 DNS 來源都要有清楚用途：可以用於解析代理服務的伺服器、用於一般網域的伺服器，以及只對特定網域生效的伺服器。

如果 DNS 伺服器本身需要經過代理才能穩定存取，可以在伺服器項目中指定 address，並搭配 domains 或 expectIPs 等條件。對於需要按網域分類的設定，思路通常是讓特定網域交給指定 DNS，其餘請求則使用另一個預設來源。這樣比把所有解析工作硬塞給同一台伺服器更容易排查，也能降低不同地區解析結果互相干擾的機會。

還要注意 DNS 伺服器的寫法不能取代路由規則。把伺服器寫進 dns.servers，只表示 Xray 知道可以向它查詢；至於 DNS 查詢本身是否透過代理送出，仍要配合 DNS 出站與 routing.rules。如果使用 DoH、DoT 或其他加密 DNS，應同時確認該請求的傳輸路徑，不能只看網址中有沒有 https。

domainStrategy 也會影響分流判斷。常見策略如 AsIs、IPIfNonMatch 和 IPOnDemand，差別在於網域規則沒有命中時，Xray 是否進一步解析網域並以 IP 規則重新判斷。策略越積極，可能觸發更多 DNS 查詢；策略越保守，則可能讓只依賴 IP 規則的分流無法命中。選擇時應以現有規則集為準，不要盲目套用別人的完整設定。

用 routing.rules 建立清晰的分流順序

Xray 路由規則通常按照陣列順序由上到下匹配，先命中的規則會決定出站。因此，規則排列比規則數量更重要。實務上可以先處理必須阻擋的廣告或無效流量，再處理區域直連網域，接著處理需要代理的網域，最後才用 IP 或預設出站收尾。若把寬泛的規則放在最前面，後面的精細規則就可能永遠沒有機會執行。

例如，規則可以使用 domain、domainSuffix、domainKeyword、geosite、ip、geoip 和 port 等條件。網域規則適合處理服務名稱與站點分類，IP 規則則適合補足沒有清楚網域資訊的連線。不要把所有內容都寫成 domainKeyword，因為關鍵字匹配範圍較寬，可能誤傷名稱相近但實際應直連的服務。

一個可維護的出站命名方式是使用清楚的標籤，例如 proxy、direct、block 和 dns-out。規則中的 outboundTag 必須與 outbounds 內的 tag 完全一致，大小寫和連字號都不能出錯。當某個網域突然無法連線時，先看它命中了哪一條規則、被送往哪個標籤，通常比直接修改一大段 JSON 更有效率。

DNS 請求本身也應該有專門的路由規則。例如可用 inboundTag、network 或其他條件辨識 DNS 流量，再將其送往 dns-out。若只配置了一個名為 DNS 的出站，卻沒有任何規則把 DNS 請求送過去，那個出站可能只是「存在於設定裡」，實際上並沒有被使用。

DNS 出站與防洩漏的完整思路

防止 DNS 洩漏的重點，不是單純尋找一個「防洩漏」勾選框，而是讓 DNS 請求只能經過預期的出口。設定中可以建立一個 dns 類型的出站，並為它指定必要的解析伺服器或查詢模式；接著在路由規則中把 DNS 流量導向這個出站。這樣做的價值在於路徑明確，日後檢查日誌時也比較容易確認請求是否真的進入 DNS 出站。

如果使用者同時啟用了 v2rayN 的系統代理與 TUN，還要考慮作業系統和虛擬網卡是否會攔截 DNS。系統代理通常只影響遵守代理設定的應用，並不一定能接管所有 UDP 及 DNS 請求；TUN 則可能讓 Xray 接觸到更多流量，但也會引入虛擬網卡、權限、路由衝突和其他 VPN 軟體互相干擾等變數。不要因為開啟 TUN 就假設所有 DNS 已經自動安全。

在 Android 的 v2rayNG 或 v2flyNG 中，系統 VPN 權限與分應用設定也會改變 DNS 行為。如果把某個瀏覽器排除在 VPN 之外，它產生的 DNS 查詢可能同樣不會經過 Xray。檢查時要把「應用是否進入 VPN」和「DNS 是否由 Xray 處理」分開驗證。桌面端與 Android 端不能完全照搬同一份 JSON，因為外層 VPN 和網路接管方式不同。

完成設定後，應使用不只一種方式驗證。可以先查看 Xray 或用戶端日誌，確認 DNS 請求是否命中預期規則；再用瀏覽器檢查 DNS 解析結果，最後從系統網路資訊確認沒有其他代理、VPN 或安全軟體暗中接管。若只做其中一項，可能會把快取結果誤判成即時解析結果。

FakeDNS、sniffing 與 routeOnly 如何取捨

FakeDNS 的概念是先為網域分配一個虛擬 IP，等到連線真正抵達 Xray 後，再依照保存的網域對應關係還原名稱。它在 TUN 或透明代理場景中很有用，因為某些應用只把 IP 交給系統，若沒有額外資訊，Xray 可能無法使用網域規則進行分流。不過 FakeDNS 不是越早開越好，它需要搭配正確的 DNS、TUN 和路由設計，還可能與本地網路、IPv6 或某些硬編碼 IP 的應用產生相容性問題。

sniffing 則是從連線內容或協定資訊中辨識真實網域。常見設定會啟用 HTTP、TLS 或 QUIC 等協定的嗅探，並視情況使用 routeOnly。啟用嗅探後，Xray 可能在連線已經建立的階段取得更準確的網域名稱，這有助於網域分流；但嗅探也不是萬能，端到端加密、非標準協定、應用自訂傳輸或缺少 SNI 時，都可能無法得到完整結果。

routeOnly 的用途是只把嗅探到的名稱用於路由判斷，不把它改寫成後續連線所使用的目標。這通常是較保守的選擇，適合想利用 SNI 或 HTTP Host 改善分流、又不希望嗅探結果直接改變連線目的地的場景。若你正在排查某個服務的連線異常，可以先使用較保守的路由判斷，再逐步加入 FakeDNS 或更積極的目標覆寫，這樣比較容易知道是哪個選項造成副作用。

實務上的取捨可以簡化成幾個原則：只用系統代理時，先保持設定簡單，依賴一般網域規則；需要接管不遵守代理的應用時，再研究 TUN 與 sniffing；只有在明確需要以虛擬 IP 還原網域的情況下，才加入 FakeDNS。設定越複雜，越要保留可回退的基準配置，並且一次只改一組相關參數。

自訂規則集與實際部署檢查

大型規則集不適合全部硬編碼在主設定檔中。可以把常變動的網域與 IP 分成外部規則檔，再透過 Xray 支援的規則集方式載入。這樣能讓主設定檔維持清楚，也方便針對直連、代理與阻擋分別更新。不過，規則集來源必須可信，格式也要符合目前核心版本；規則檔下載失敗、格式不相容或內容過時，都可能造成啟動錯誤或分流結果改變。

自訂規則集至少要先規劃三個範圍：本地或區域服務的直連清單、需要代理的網域清單，以及明確不應連線的阻擋清單。規則集名稱要能反映用途，不要使用含義模糊的 rules1、test 之類標籤。每次更新後，應保留上一版設定，先確認 Xray 能正常啟動，再逐一測試常用網站、內地或本地服務、需要登入的應用，以及不應被代理的系統服務。

若 Xray 啟動失敗，先用核心提供的設定檢查功能驗證 JSON 格式。常見錯誤包括逗號多餘、括號不成對、同一標籤重複、引用了不存在的出站，以及把某個版本才支援的欄位放進舊核心。JSON 語法正確也不代表邏輯正確，所以通過語法檢查後，仍要看日誌確認實際命中結果。

建議按照下面順序部署：

  1. 先以最少 DNS 伺服器和兩個基本出站建立可啟動的基準配置
  2. 加入直連與代理網域規則，確認順序和出站標籤完全一致
  3. 再建立 DNS 出站，檢查 DNS 請求是否確實被導向指定路徑
  4. 需要 TUN 時先確認權限與其他 VPN 工具已關閉，再測試常用應用
  5. 最後才加入 FakeDNS、sniffing、routeOnly 與外部規則集

排錯時不要一次替換整份網路上找到的「完美配置」。不同版本的 Xray、不同用戶端包裝方式、不同作業系統和不同節點傳輸，都會讓同一份 JSON 出現不同結果。最可靠的做法是保留一份已能連線的設定，每次只調整 DNS、路由或嗅探其中一個層面，記錄變更後的日誌與測試結果。

最後要記住，防 DNS 洩漏並不等於保證所有網路資訊都完全隱藏。瀏覽器自身的安全 DNS、IPv6、WebRTC、應用內建解析器，以及作業系統的背景服務，都可能形成額外路徑。Xray JSON 能處理的是它實際接管到的流量；因此，正確設定之後仍應從應用、系統與網路三個層面檢查。把 DNS 路徑、分流順序和接管範圍說清楚，才是可長期維護的 Xray 配置，而不是堆疊選項後祈求它剛好有效。