V2Ray DNS 設定詳解：中國大陸與海外網域分流解析及防污染實務

先釐清 DNS 查詢經過哪條鏈路

應用程式存取網域時，通常首先發生的不是代理連線，而是將網域轉換成 IP 位址。若應用程式直接呼叫系統 DNS，查詢可能在進入 V2Ray 前就已完成；此時只修改設定檔中的 dns 區段，不一定會改變應用程式取得的結果。只有在查詢由內建 DNS、DNS 入站、透明代理攔截鏈路，或用戶端提供的相應功能接管時，內建規則才會參與處理。

另一個容易混淆的地方是，「DNS 伺服器的選擇」與「業務流量分流」是兩個步驟。dns.servers 決定某個網域交由哪台 DNS 伺服器解析，routing.rules 則決定 DNS 查詢及後續連線使用哪個出站。即使網域被分配給海外 DoH，若該 DoH 請求仍透過不適合的直連路徑送出，也可能發生逾時或連線遭重設。

完整鏈路應依序檢查：應用程式是否將查詢交給用戶端、網域是否命中預期的伺服器、解析伺服器的請求經過哪個出站、回傳位址是否通過驗證，以及最後的業務連線命中了哪條路由。只觀察網頁能否開啟，無法判斷問題發生在哪一層。

servers、domains 與 expectIPs 各自負責什麼

servers 是解析伺服器清單，項目可以是一般位址，也可以是附帶比對條件的物件。物件形式可為特定伺服器加入 domains、expectIPs、連接埠及回退控制。清單中的無條件伺服器通常負責預設或回退解析，不宜讓所有伺服器都使用相同的比對範圍。

domains 用來決定哪些查詢優先交給目前的伺服器。常見規則包括 geosite:cn、geosite:geolocation-!cn、domain:example.com 與 full:host.example.com。其中 domain: 可比對目前網域及其子網域，full: 則只比對完整主機名稱。地理分類取決於用戶端目前使用的資料檔，資料過舊時可能出現新網域尚未分類的情況。

expectIPs 不負責選擇解析伺服器，而是用來檢查回傳的 IP 是否符合預期。例如中國大陸網域的伺服器設定 geoip:cn 後，若回傳位址不屬於該集合，核心可以嘗試後續解析路徑。這個欄位適合找出明顯不合理的回覆，但不能取代網域分類，也不能保證跨區域服務始終回傳固定歸屬的位址。

queryStrategy 控制查詢的位址族群。UseIPv4 只請求 IPv4，適合本地 IPv6 不完整或代理節點沒有 IPv6 出站能力的環境；UseIPv6 只請求 IPv6；UseIP 允許同時使用兩類結果。位址族群的選擇必須與節點、系統網路及路由規則一致，否則可能出現 DNS 有結果但連線持續逾時的情況。

一份可調整的中國大陸與海外分流解析設定

以下範例展示核心結構，不包含節點憑證與完整出站設定。中國大陸分類交由 UDP 53 解析伺服器，海外分類交由基於 HTTPS 的解析伺服器，並以本機解析作為最後回退。範例採用 IP 形式的 DoH 位址，目的是減少解析 DoH 主機名稱時再次觸發 DNS 查詢的依賴。

{
  "dns": {
    "queryStrategy": "UseIPv4",
    "servers": [
      {
        "address": "223.5.5.5",
        "port": 53,
        "domains": [
          "geosite:cn"
        ],
        "expectIPs": [
          "geoip:cn"
        ],
        "skipFallback": true
      },
      {
        "address": "https://1.1.1.1/dns-query",
        "domains": [
          "geosite:geolocation-!cn"
        ],
        "expectIPs": [
          "geoip:!cn"
        ],
        "skipFallback": true
      },
      "localhost"
    ]
  },
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "223.5.5.5"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "1.1.1.1"
        ],
        "outboundTag": "proxy"
      }
    ]
  }
}

範例假設現有設定中已存在名為 direct 與 proxy 的出站標籤。若實際標籤是 freedom、main 或其他名稱，必須依現有設定修改，不能直接照抄。路由規則也要放在適當順序：更具體的 DNS 伺服器位址規則應位於寬泛的中國大陸 IP 直連規則之前，否則會被前面的規則提前命中。

skipFallback 表示目前伺服器不參與一般回退流程，但不同核心版本對 DNS 回退細節及擴充欄位的支援可能不同。使用 V2Ray 5.x、Xray 25.x 或由用戶端附帶的其他核心時，應以實際核心啟動日誌為準。若日誌提示未知欄位，應先移除該欄位完成基礎驗證，再依目前核心文件補充回退控制。

從日誌驗證分流是否真正生效

驗證時不要一次修改 DNS、路由、節點及系統代理四個部分。先備份目前可用的設定，只替換 DNS 區段並重新啟動核心；確認沒有語法錯誤後，再加入解析伺服器的出站規則。分階段修改可以分開處理「設定無法啟動」與「解析結果不符合預期」兩類問題。

v2rayN 可從「設定」→「參數設定」檢查日誌層級，並在主介面開啟日誌視窗。需要診斷時可暫時使用資訊層級日誌，測試結束後恢復原設定。Android 上的 v2rayNG 或 v2flyNG 應先中斷連線、儲存設定，再重新連線，避免只修改介面而舊核心程序仍在使用快取設定。

1. 準備一個明確屬於中國大陸分類的網域、一個海外分類網域，以及一條自訂完整網域規則，避免只用單一網站判斷。
2. 清除系統及瀏覽器可控制範圍內的 DNS 快取，然後重新啟動目前的用戶端核心，記錄測試開始時間。
3. 每類網域連續存取三次，在日誌中確認查詢目標、命中的伺服器及最終出站標籤。
4. 分別測試開啟與關閉代理的狀態，確認失敗是否只發生在 DoH 請求需要經過代理的情境。
5. 暫時移除 expectIPs 後再測試一次；若問題消失，表示回傳位址與預期集合衝突，應調整分類，而不是盲目更換節點。

延遲也應分層記錄。一次完整存取包含 DNS 時間、TCP 或 UDP 建立連線時間、TLS 交握及伺服器回應時間。若日誌顯示 DNS 在 40 毫秒內完成，而頁面等待超過 3 秒，問題更可能位於業務連線或路由，而非解析。反過來，若 DNS 請求連續在約 5 秒後逾時，才應重點檢查伺服器可達性及出站選擇。

高頻故障與對應處理方法

DNS 分流最常見的問題不是 JSON 格式，而是規則彼此覆蓋。伺服器物件中的 domains 負責解析選擇，路由中的 domain 與 ip 負責連線分流；兩處都可能引用 geosite 或 geoip，但執行階段不同。排查時應先確認目前看到的是 DNS 查詢日誌還是業務連線日誌。

快取會讓修改結果看起來沒有生效。作業系統、瀏覽器、用戶端核心及上游解析伺服器都可能快取記錄。測試時應優先改用先前未存取過的子網域，或在可控制的環境中等待記錄有效期限結束。頻繁重新啟動用戶端只能清除其中一部分快取，無法強制所有上游立即回傳新結果。

另一項風險是同時啟用多套 DNS 接管機制。例如瀏覽器自行使用安全 DNS，而系統流量又由用戶端接管，這兩條查詢鏈可能得到不同結果。診斷階段應暫時統一入口，讓查詢明確經過目前的核心；完成驗證後，再依實際需求決定是否保留應用程式自己的解析功能。

• 中國大陸網域偶爾回傳海外位址：先檢查內容傳遞網路的調度，不要立即將結果判定為異常。
• DoH 長時間沒有回應：確認 443 連接埠連線命中代理出站，並檢查節點是否能存取目標解析服務。
• 只有 IPv6 位址的連線失敗：暫時將查詢策略改為 UseIPv4，再檢查節點及本地網路的 IPv6 能力。
• 訂閱更新正常但網頁解析異常：訂閱請求與業務 DNS 並非同一條鏈路，應分別查看日誌。

將設定套用到 v2rayN、v2rayNG 與 v2flyNG

v2rayN 桌面版適合進行完整設定檢查，因為日誌視窗及自訂設定編輯更方便對照。編輯前先匯出現有設定，在「設定」→「參數設定」確認核心類型，再將 DNS 物件合併至頂層 JSON。不要在同一個檔案中保留兩個同名的 dns 物件，後出現的內容可能覆蓋前面的設定。

Android 用戶端更適合在桌面版完成驗證後同步設定思路，而不是直接複製全部設定。v2rayNG 使用 Xray 核心，v2flyNG 使用 v2fly 核心，兩者對欄位支援、預設查詢策略及用戶端產生設定的方式可能不同。若用戶端透過訂閱自動產生執行設定，手動修改的暫時內容也可能在訂閱更新後被重建。

穩定方案應保留一條明確的回退路徑，但回退不能掩蓋主要伺服器長期失效。建議先讓中國大陸 UDP 53 與海外 DoH 各自準確命中，再加入本機解析作為最後兜底。若預設伺服器承擔大多數查詢，表示 domains 分類或資料檔仍有問題，不能把「最後能開啟」視為分流已正確。