V2Ray DNS 設定教學：依網域分流解析與防 DNS 污染

一、DNS 解析分流不等於連線分流

先說結論：在用戶端填入遠端 DNS，不代表所有應用程式都會使用它。瀏覽器可能自行啟用加密 DNS，作業系統有自己的快取，代理協定也可能將網域原樣交由伺服器解析。只有請求實際進入內建 DNS 模組時，下方的 servers 規則才會生效。

這個流程描述的是呼叫內建 DNS 時的處理過程，並不代表每條代理連線都會經過本機解析。用戶端收到網域後，若路由直接選擇代理出口，通常可以繼續將網域傳給伺服器；若路由需要依 IP 判斷，或直連出口需要目標位址，才可能觸發本機解析。實際行為取決於路由策略與出口設定。

• 解析分流：決定某個網域交由哪台 DNS 伺服器查詢，設定重點是 dns.servers。
• 連線分流：決定業務連線採用直連或代理，設定重點是 routing.rules。
• 查詢分流：決定連線至 DNS 伺服器時採用直連或代理，也需要檢查路由規則。

系統代理主要接管遵循代理設定的應用程式流量，不會自動接管整台裝置的 DNS。TUN 可以擴大接管範圍，但仍須設定 DNS 劫持、路由與排除項目，不能只看開關狀態就判定查詢是否進入核心。

二、servers、domains 與 queryStrategy 各自的用途

servers 是候選解析器清單；物件中的 domains 指定優先交由該解析器處理的網域範圍；queryStrategy 則控制查詢 IPv4、IPv6，或兩者都查。這些欄位位於不同規則層級，不能互相取代。

domains 不應視為嚴格的存取白名單。解析失敗後是否改用其他伺服器，還取決於備援相關設定。下文使用 skipFallback，避免本地解析器成為未比對網域的一般備援；但這不代表網域符合條件的解析失敗後，絕不會嘗試其他解析器。

geosite:cn 需要使用執行目錄中的網域規則資料，並非核心會自動辨識地區。若啟動記錄顯示規則檔案遺失，請先修復資源檔案。企業內部網域則應使用相應的 domain: 比對條件，並交由企業內網解析器處理；不要送往公共 DNS，再期待取得內網位址。

三、依網域分流的 DNS 設定範例

以下範例使用一個本地解析器和一個預設 DoH 解析器。設定目標是讓中國大陸網域集合優先使用本地查詢，其他網域則使用遠端查詢。請先備份設定，再將頂層 dns 物件合併至現有 JSON；若已有同名物件，請編輯原物件，不要重複新增第二個 dns 鍵。

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      {
        "address": "223.5.5.5",
        "port": 53,
        "domains": [
          "geosite:cn"
        ],
        "skipFallback": true
      },
      "https://1.1.1.1/dns-query"
    ]
  }
}

此處使用數字格式的 DoH 端點，避免先解析 DNS 伺服器網域而產生引導依賴。若改用網域格式的 DoH 位址，也要確認該網域由誰解析，以及解析請求是否反過來依賴尚未連線的 DoH 服務。

1. 確認核心：v2rayN 是用戶端介面，不等同於 V2Ray 核心。請先查看核心啟動記錄，確認目前執行的是 V2Ray 還是 Xray，再核對欄位支援狀況。
2. 確認規則檔案：啟動時不應出現 geosite:cn 載入失敗；否則比對所需的前提並未成立。
3. 確認產生的設定：透過介面產生設定時，重新啟動用戶端可能會覆蓋手動修改內容。請透過用戶端支援的自訂設定入口儲存，再查看實際交給核心的設定。
4. 確認位址類型：先保留 UseIP 作為一般雙堆疊設定；只有在排查 IPv6 問題時，才暫時改為 UseIPv4，並記錄比較結果。

此片段未定義入站、代理伺服器與出站，無法單獨啟動。Android 上的 v2rayNG 使用 Xray 核心，v2flyNG 使用 v2fly 核心；即使介面都顯示「DNS」，仍應分別確認欄位覆寫關係與執行模式。

四、讓 DNS 查詢走正確的出口

只有解析器位址、沒有指定查詢路徑，仍可能發生「遠端 DNS 實際走直連」的情況。標準的 https:// DoH 請求可以經過核心路由；某些核心支援的 https+local:// 則採用本機存取語意，不能視為完全相同的位址寫法來替換。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": [
          "223.5.5.5/32"
        ],
        "port": "53",
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "1.1.1.1/32"
        ],
        "port": "443",
        "outboundTag": "proxy"
      }
    ]
  }
}

這是另一段設定合併示意，假設現有出口標籤確實名為 direct 和 proxy。標籤只是設定中的參照名稱，不是核心自動建立的物件。請將範例名稱換成實際標籤，並將兩條查詢規則放在可能先行比對的廣泛規則之前；不要用這兩條規則覆蓋原有的業務分流規則。

AsIs 表示路由階段不會為了 IP 規則主動解析網域，並不代表業務連線永遠不需要解析。若改為 IPIfNonMatch，未符合網域規則的請求可能會先解析，再比對 IP；若使用 IPOnDemand，遇到需要 IP 的規則時就可能觸發解析。調整這些值之前，請先確認是否真的需要依賴 IP 規則。

也要檢查代理伺服器本身的網域解析方式。如果連線至代理伺服器前，必須先透過該代理查詢 DoH，就會形成循環依賴。可使用明確的引導解析路徑，或採用服務提供者確認過的伺服器位址；請勿任意替換訂閱中的伺服器資訊。

五、防 DNS 污染：一併檢查加密查詢、路徑與快取

DoH 可以保護用戶端與解析器之間的查詢傳輸，但無法保證解析結果一定符合預期。解析器的地區策略、網站的 CDN 調度、裝置快取與 IPv6 連線能力，都可能造成「位址不同」或「解析成功但無法開啟」。只比較兩個解析器回傳的 IP 是否一致，不能據此判定遭到污染。

• 先確認查詢入口：瀏覽器內建的安全 DNS 可能會繞過作業系統解析。排查時可先暫時關閉此功能，完成比較後再決定是否啟用。
• 再確認查詢出口：查看核心記錄中的 DNS 錯誤與連線出口，必要時在本機擷取封包，檢查是否仍有非預期送出的 UDP 53 請求。
• 區分系統快取：Windows 可執行 ipconfig /flushdns 清除系統解析快取，但這個命令不會清除瀏覽器與核心各自管理的所有快取。
• 一次只比較一個變因：在相同目標、節點與執行模式下，每次只更換解析器或位址類型其中一項，避免把代理路線變化誤認為 DNS 改善。

本例中的本地解析器使用一般 UDP 查詢，因此這部分沒有加密保護。若網路環境不適合明文查詢，可選用可連線的本地加密解析器，並重新規劃相應路由。不要只將位址改成 DoH，卻忽略連線能力、憑證驗證與出口策略。

六、解析問題的驗證步驟與常見問答

建議先儲存一份可正常連線的設定，再依序檢查「核心啟動、送出查詢、收到結果、業務連線」。可暫時提高記錄詳細程度，每次只重現一個目標，避免大量並行請求淹沒關鍵記錄；排查完成後請恢復日常記錄等級，分享記錄前移除訂閱網址與連線憑證。

nslookup -type=A example.com 223.5.5.5
nslookup -type=AAAA example.com 223.5.5.5
ipconfig /flushdns

example.com 是用於說明的保留示例網域。前兩個命令會直接向指定的一般 DNS 發出查詢，用來確認該查詢路徑是否可用；它們不會自動呼叫 V2Ray 內建 DNS，也無法證明 DoH 已透過代理傳送。若要驗證核心分流，仍須透過實際應用程式發出請求，並搭配核心記錄與實際設定判斷。

最後的驗收標準不是「填了幾台 DNS」，而是以下三件事同時成立：本地域名符合預期的解析器、遠端查詢使用預期出口、業務連線依原定路由完成。若要進一步確認介面入口與設定結構，請參閱用戶端設定教學與技術參考。