V2Ray DNS 分流設定：國內外網域分開解析與 DNS 防污染

本文重點

DNS 分流需要同時安排「由誰解析」以及「查詢經過哪個出口」。本文適合已能正常連線至節點、準備細分中國大陸與其他地區網域規則的使用者：先分清系統 DNS 與核心 DNS，再了解伺服器選擇、路由策略和設定片段，最後透過記錄確認結果。一般系統代理情境不必急著啟用 FakeDNS；先建立可重現的基本設定，會更容易找出問題。

1. DNS 分流的前提：請求必須進入核心

在 V2Ray 中設定 DNS 位址，不代表電腦上的所有應用程式都會改用該位址。內建 DNS 主要處理核心需要執行的解析，例如路由依目標 IP 判斷、部分出站連線的網域解析，以及設定 DNS 入站轉送的情境。應用程式自行送出的 DNS 查詢，只有經過相應的接管或轉送流程，才會套用這些規則。

應用程式存取網域代理接收目標路由觸發解析選擇解析服務符合出站規則

這個流程描述的是「應用程式將網域交給代理，且路由需要解析」的其中一種情況。如果網域規則已決定使用代理出站，核心可能會直接將網域交給遠端，不在本機查詢目標 IP。若應用程式先完成解析，再將 IP 傳給代理，核心收到的可能就不再是網域。

連線方式	常見 DNS 行為	檢查重點
瀏覽器使用 HTTP 代理	代理請求通常會帶上網域；瀏覽器也可能自行解析或預先解析	安全 DNS、代理略過清單
應用程式使用 SOCKS5	應用程式可傳送網域，也可能先在本機解析	是否啟用遠端網域解析
桌面 TUN 接管	取決於虛擬網卡路由與 DNS 接管設定	DNS 是否確實進入接管流程
Android VPN 模式	用戶端可接管流量；遭排除的應用程式仍可能使用原本網路	個別應用程式清單、私人 DNS 設定

v2rayN 是桌面用戶端，v2rayNG 使用 Xray 核心，v2flyNG 使用 V2Fly 核心。不能只因為介面上都出現「DNS」，就照搬所有參數。本文範例採用 V2Ray/V2Fly 常見的傳統 JSON 結構；實際能否載入，仍須以目前的核心版本及用戶端產生的設定為準。

2. 內建 DNS 如何選擇解析伺服器

dns.servers 可包含字串位址，也可包含帶有 domains 的伺服器物件。網域符合某個物件的規則後，該伺服器就會成為優先查詢對象；若同時符合多個物件，還須考量它們在清單中的順序。不能單純將整個陣列理解為「第一項永遠是主要伺服器，第二項永遠是備援伺服器」。

檢查靜態對應與快取。 設定中的 dns.hosts 和現有快取都可能影響結果，因此更換伺服器後，不一定會立即看到新的網路查詢。
選擇符合網域的伺服器。 例如 geosite:cn 指向規則資料庫中的一組網域，而不是依網域後綴即時判斷所在地。
處理失敗與回退。 優先伺服器未取得可用結果時，若設定允許回退，就會再嘗試可參與回退的伺服器。標記為 skipFallback: true 的伺服器不會列入一般回退候選。
傳回解析結果。 結果也可能受到查詢的 IP 位址族、expectIPs 篩選和版本行為影響；是否會重試，應參照該版本文件並檢查記錄。

expectIPs 可篩選解析結果的位址範圍，但不是驗證結果真實性的機制。共用 CDN、跨境部署及規則資料庫分類差異，都可能導致有效結果遭到篩除。初次部署時建議先不設定，等查詢流程穩定後再單獨測試。

3. 國內外分開解析：DNS 與出口一併設定

以下提供一段可合併使用的設定片段：中國大陸網域優先查詢 223.5.5.5，其他網域則使用 https://1.1.1.1/dns-query。後者透過一般 DoH 位址交由核心路由處理，再以目標 IP 規則選擇代理出口。這不是可直接啟動的完整設定，也不包含節點資訊。

範例中國大陸 DNS 的 UDP 連接埠

443

範例 DoH 的 HTTPS 連接埠

2 組

範例解析服務

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

先確認出站標記。 這裡的 direct 和 proxy 必須對應到現有 outbounds 的 tag。直連出站通常使用 freedom；代理出站則沿用已確認可用的節點。
確認預設出口。 傳統設定中，未符合規則的連線通常會使用第一個出站。此片段未定義預設出口，須在現有設定中明確指定，不能假設未分類的目標一定會走代理。
保留既有規則。 合併至用戶端設定時，應保留區域網路、封鎖及必要的系統規則，並確認規則順序。路由會套用第一條符合的規則。
準備規則檔案。 geosite:cn、geosite:geolocation-!cn 和 geoip:cn 都需要相應的規則資料。若分類缺漏或檔案無法讀取，請先修正載入錯誤。

結論：先確認解析請求的出口，再調整網域分類

若記錄顯示 DoH 連線仍走直連，請先修正 1.1.1.1:443 的路由與出站標記。單純將 DNS 位址換成加密位址，不能取代出口設定，也無法解決代理節點本身無法連線的問題。

範例中的 IP 規則也會比對其他連往相同位址與連接埠的連線，不會只辨識 DNS。在核心支援的情況下，複雜設定可使用 DNS 查詢標記進一步區分。一般的 https:// 與帶有本機處理語意的 https+local:// 位址不可直接互換，兩者的路由行為不同。

4. domainStrategy：何時觸發解析，何時保留網域

routing.domainStrategy 控制路由判斷階段如何使用 IP，不是「所有 DNS 查詢都走代理」的開關。尤其要區分路由模組的同名欄位，與 freedom 出站中的 domainStrategy：前者決定如何比對規則，後者涉及直連出站如何處理目標網域，兩者支援的值不可混用。

routing.domainStrategy	路由階段的行為	適用情境
`AsIs`	不主動解析網域目標以進行路由判斷	主要依據網域規則，減少額外查詢
`IPIfNonMatch`	網域未符合路由規則時，再解析並比對 IP 規則	優先套用網域規則，再以 IP 規則補充
`IPOnDemand`	比對規則時，遇到需要 IP 的規則才觸發解析	需要較早使用 IP 分類時採用

以上範例使用 IPIfNonMatch：明確屬於中國大陸或非中國大陸分類的網域，會先依網域規則分流；未分類的目標才可能進行解析，再交由 geoip:cn 判斷。這也說明了為什麼「開啟境外網站卻沒看到本機 DNS 查詢」不一定代表設定失效。

想減少本機解析：先補齊可靠的網域規則，不要一開始就改用更積極的解析策略。
發現規則分流錯誤：先檢查符合的第一條規則，再確認解析結果，別只更換 DNS 伺服器。
已收到 IP 目標：這三個選項不會憑空還原原始網域；能否還原，取決於嗅探資訊、FakeDNS 對應等條件。

5. FakeDNS：虛擬位址對應需要完整的接管流程

FakeDNS 傳回的是由本機維護對應關係的虛擬 IP，而非網站的實際伺服器位址。應用程式連線至該位址後，核心會依據對應關係還原網域，用於路由或後續代理。它解決的是「應用程式先解析，代理只收到 IP」造成的資訊遺失問題，不會自動加密 DNS 查詢。

確認 DNS 請求已被接管。 應用程式的查詢若未進入 FakeDNS，就不會建立對應關係；只在設定中加入位址池並沒有實際作用。
確認虛擬 IP 的流量會回到核心。 桌面 TUN 或 Android VPN 的路由必須涵蓋該位址池，不能將流量送往實體網路。
確認網域還原功能。 對應的入站設定必須符合核心支援的 FakeDNS 嗅探設定；常見的相關欄位是 sniffing.destOverride 中的 fakedns。
確認直連路徑能取得實際位址。 還原網域後，直連目標仍需適當解析，不能把虛擬位址當成實際伺服器來連線。

一般系統代理情境下，若應用程式能傳遞網域，建議優先保留使用實際位址的解析方式。確實需要 FakeDNS 時，請先閱讀相應用戶端與核心的功能說明，一次只啟用一種接管機制。不要同時變更 TUN、DNS 劫持、嗅探和路由策略，否則難以判斷是哪一層造成網路中斷。

6. 設定驗證：先檢查載入，再確認解析與路由

排查 DNS 問題時，應先分清設定載入失敗、查詢逾時，以及解析成功但連線失敗。VMess 或 VLESS 節點無法使用時，透過該節點傳送的 DoH 也會逾時；反過來說，DNS 能傳回位址，也不代表節點握手、TLS 或目標連接埠正常。

記錄目前狀態。 保存目前可用的設定，記下用戶端版本、實際使用的核心及版本、系統代理或 VPN 模式，以及個別應用程式的排除項目。更新訂閱前後，也要確認目前使用的節點沒有變更。
修改後重新啟動核心。 在用戶端 DNS 或自訂設定入口儲存變更後，查看啟動記錄。若出現未知欄位、規則資料載入失敗或找不到出站標記，請先修正這些錯誤，再測試網頁。
暫時提高記錄詳細程度。 在用戶端提供的記錄設定中暫時選擇偵錯等級，觀察目標網域、DNS 連線位址和出站標記。測試完成後恢復常用等級，分享前請移除節點位址與瀏覽記錄。
分別測試不同分類。 選擇一個已確認符合中國大陸規則的網域、一個已確認屬於非中國大陸分類的網域，再測試一個未分類網域。每類連續存取 3 次，留意首次查詢與命中快取時的差異。
最後排除快取問題。 重新啟動應用程式或核心後再次測試，必要時清除系統 DNS 快取。不要每次都同時更換解析器、節點和規則檔案。

ipconfig /flushdns
nslookup www.baidu.com 223.5.5.5

以上是 Windows 的輔助檢查命令：第一行清除系統 DNS 快取；第二行直接向指定伺服器查詢。第二行不會經過本文介紹的內建 DNS 選擇流程，因此只能檢查該伺服器是否可連線，無法證明分流成功。若查詢失敗，也要考慮本機網路是否限制直連 UDP 53。

更改 DNS 後，為什麼瀏覽器仍取得舊位址？

先關閉並重新開啟測試頁面，再確認瀏覽器的安全 DNS 是否獨立運作。Windows 可執行 ipconfig /flushdns，接著重新啟動用戶端核心；核心快取與系統快取並不相同。若仍未改變，請確認應用程式是否略過系統代理。

中國大陸網站也改用遠端 DNS，是規則寫反了嗎？

先確認網域是否屬於目前的 geosite:cn 分類，再查看優先伺服器查詢失敗後是否發生回退。不要把 skipFallback: true 當成禁止回退；也要確認 DNS 連線的路由是否被更前面的規則攔截。

Android VPN 已連線，為什麼只有部分應用程式解析異常？

檢查 v2rayNG 或 v2flyNG 的個別應用程式代理清單，並記錄系統「設定」中的「私人 DNS」狀態；不同廠牌的系統選單名稱可能不同。可暫時排除應用程式本身的加密 DNS 干擾後再次測試，確認原因後再恢復需要的設定。

DoH 要求逾時，是否應該直接關閉憑證驗證？

先確認系統時間、代理節點是否可連線，以及 1.1.1.1:443 是否走代理出口。檢查記錄，區分連線逾時與憑證錯誤；請保持憑證驗證開啟，不要降低 TLS 驗證要求來掩蓋路由問題。

最終目標不是讓所有網域都由同一台伺服器解析，而是讓網域分類、查詢出口與業務出口彼此一致。防污染設定能降低不可信查詢路徑的影響，但無法保證規則分類永遠正確，也不能取代連線記錄、憑證驗證與定期維護。