DNS 洩漏怎麼檢測：V2Ray 防洩漏 DNS 設定實作步驟

先確認檢測結果是否為 DNS 洩漏

DNS 的作用是將網域名稱轉換為 IP 位址。瀏覽器造訪網站時，通常會先詢問解析器，再與解析結果對應的伺服器建立連線。代理連線正常，不代表這次詢問也經過代理：網頁流量可能從節點送出，DNS 請求卻仍傳給路由器、電信業者解析器或系統預設的伺服器。

判斷洩漏不能只看檢測頁面列出幾個 DNS 位址。公共解析服務經常使用全球調度，頁面顯示的出口城市可能與節點城市不同；解析器名稱也可能屬於公共服務商或其上游網路。真正需要注意的是：連線前出現的本地電信業者解析器，在連線後是否仍然出現，以及解析請求是否繞過預期的代理或加密通道。

1. 完全結束客戶端，記錄目前的公網出口地區、DNS 提供者數量與解析器地區。
2. 啟動客戶端，選擇位置明確的節點，開啟系統代理或 TUN，再重新整理檢測頁面。
3. 改用新的網域名稱重新測試，避免瀏覽器與系統 DNS 快取直接回傳舊結果。
4. 比較兩次結果，不要只比較 IP；同時查看電信業者名稱、網路歸屬與地區是否仍指向本地接取網路。

DNS 為什麼會繞過 V2Ray 連線

系統代理主要接管支援 HTTP 或 SOCKS 代理的應用程式連線，並不會自然接管作業系統送出的所有 DNS 封包。有些應用程式會先呼叫系統解析介面取得 IP，再把連線交給代理；此時網域查詢已經從實體網卡送出。另一些應用程式支援 SOCKS 遠端解析，會直接將網域交給代理端處理，兩者結果並不相同。

瀏覽器內建的安全 DNS、路由器下發的 DNS、企業網路策略與虛擬網卡設定，也可能各自建立解析路徑。排查時必須分開確認「誰發起查詢」、「查詢交給誰」以及「封包從哪個出站送出」。只修改一個 DNS 位址，卻沒有改變查詢經過的出站，通常無法解決路徑問題。

最常見的四條旁路

• 系統代理只接管網頁連線：系統 DNS 仍會將 UDP 查詢送往路由器的 53 埠。
• 瀏覽器獨立解析：瀏覽器設定的安全 DNS 不遵循客戶端內建 DNS 規則，檢測結果會與其他應用程式不同。
• TUN 接管範圍不完整：實體網卡優先順序、排除路由或應用程式繞過設定，可能使部分 53 埠流量未進入虛擬網卡。
• 節點網域需要先解析：客戶端連線節點前必須取得伺服器 IP，這類引導解析通常發生在通道建立之前，需要另外設定可信任的直連解析器。

在 v2rayN 中設定內建 DNS 與分流

以下以 v2rayN 7.12.5、Xray-core 25.6.8 的測試介面為例。選單名稱可能在小版本間調整，但處理順序不變：先確定解析器，再讓中國大陸與遠端網域進入對應規則，最後檢查產生的設定與核心日誌。若目前只使用系統代理，v2rayN 的本機 SOCKS 入口通常是 127.0.0.1:10808；應用程式必須支援代理，或由系統代理接管，才會經過這個入口。

1. 開啟「設定」→「DNS 設定」，先備份目前內容，避免修改失敗後無法復原。
2. 將遠端解析器設定為支援加密查詢的位址，例如 https://1.1.1.1/dns-query，並確認該解析器的連線依規則進入代理出站。
3. 為中國大陸網域保留獨立解析器，例如 223.5.5.5，搭配 geosite:cn 與 geoip:cn 限定結果範圍。
4. 開啟「設定」→「參數設定」，確認核心類型為 Xray，並檢查路由模式沒有將所有 DNS 連線強制送往直連。
5. 儲存後重新啟動核心，在日誌中觀察是否出現解析逾時、節點網域無法解析或 DNS 出站遭拒。

自訂設定使用者可以參考以下結構，了解內建 DNS 分流方式。這不是所有訂閱都能直接套用的通用檔案；圖形介面可能會合併使用者設定與訂閱產生項目，因此應以最終產生的設定為準，而不只是查看輸入框。

{
  "dns": {
    "queryStrategy": "UseIPv4",
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"],
        "expectIPs": ["geoip:cn"]
      },
      {
        "address": "https://1.1.1.1/dns-query",
        "domains": ["geosite:geolocation-!cn"]
      }
    ]
  }
}

queryStrategy 決定優先查詢哪一類位址。只需要 IPv4 時，使用 UseIPv4 可減少雙協定堆疊環境中的不確定性；確認網路、節點與目標網站都能穩定使用 IPv6 後，再選擇包含 IPv6 的策略。它不會自動決定 DNS 連線走直連還是代理，出站仍由路由規則控制。

在 v2rayNG 中處理遠端 DNS

Android 上的關鍵差異在於，VPN 模式會透過虛擬網路介面接管更多流量。以下以 v2rayNG 1.10.31、Xray 核心為例：進入「設定」→「VPN 設定」，檢查「遠端 DNS」、「本地 DNS」及本地 DNS 啟用狀態。不同介面的翻譯可能略有差異，應以欄位用途為準。

1. 在「設定」→「VPN 設定」→「遠端 DNS」填入預計用於代理網域的解析器，例如 https://1.1.1.1/dns-query。
2. 在「本地 DNS」保留可直接存取的解析器，例如 223.5.5.5，用於中國大陸規則與節點連線前必要的解析。
3. 進入「設定」→「路由設定」，確認中國大陸網域規則位於兜底規則之前，避免先被全域代理規則命中。
4. 中斷後重新連線 VPN，不能只返回主畫面；舊的虛擬介面與 DNS 快取可能仍會保留。
5. 分別使用瀏覽器與另一個需要連線的應用程式測試。如果只有瀏覽器結果異常，再檢查瀏覽器自身的安全 DNS 設定。

v2rayNG 使用 Xray 核心，VMess 與 VLESS 節點都能搭配內建 DNS 與路由分流。協定名稱本身不會自動防止 DNS 洩漏；結果取決於 VPN 接管範圍、DNS 設定與出站規則。v2flyNG 使用 v2fly 核心時也是相同的排查思路，但設定欄位的支援範圍應以客戶端實際產生的結果為準，不要直接照搬只適用於 Xray 的擴充項目。

TUN 模式下還要檢查哪些位置

TUN 模式透過虛擬網卡接管不主動支援系統代理的應用程式，因此更適合統一處理 DNS，但也不是開啟開關就完成。虛擬網卡的路由優先順序、DNS 劫持規則、區域網路繞過範圍與 IPv6 路徑必須彼此匹配。尤其當實體網卡仍保留可用的 IPv6 DNS 時，IPv4 測試看似正常，部分查詢卻可能從另一條鏈路送出。

TUN 檢查清單

• 確認客戶端具備足夠權限建立虛擬網卡，且日誌中沒有寫入路由失敗。
• 檢查 UDP 與 TCP 的 53 埠是否都受到處理，不要只驗證常見的 UDP 查詢。
• 確認區域網路位址繞過規則只涵蓋私有網路，不要將公共 DNS 位址誤歸入直連網段。
• 暫時不使用 IPv6 時，讓客戶端 DNS 查詢策略與系統網路層保持一致，避免只關閉其中一側。
• 如果啟用 FakeDNS，確認網域嗅探與路由規則能將映射位址還原為原始網域。

FakeDNS 會先回傳一段保留位址，再由核心保存「虛擬 IP 與原始網域」的映射。這有助於接管只攜帶目標 IP 的連線，並讓網域分流持續生效，但不代表已真正完成遠端解析。存取目標前，核心仍須依規則取得真實位址；映射池衝突、應用程式快取時間過長或停用嗅探，都可能導致連線失敗。

從核心日誌定位 DNS 錯誤

檢測頁面只能告訴你結果，核心日誌才適合用來定位原因。先將日誌層級暫時調整為資訊或警告，重新連線後造訪一個之前未開啟過的網域。重點查看錯誤發生在解析節點位址、連線至遠端解析器，還是取得目標位址後的出站階段。

如果日誌沒有 DNS 錯誤，但檢測仍出現本地解析器，問題多半發生在核心之外：應用程式使用了系統解析、瀏覽器建立了獨立連線，或 DNS 封包沒有進入 TUN。此時應比較系統代理與 TUN 兩種模式，而不是反覆更換 VMess、VLESS 節點。

修復後如何進行最終驗證

最終驗證至少要涵蓋「首次查詢、重複查詢、斷線恢復」三種狀態。首次查詢用來檢查實際解析路徑，重複查詢用來觀察快取穩定性，斷線恢復則能發現客戶端重新連線後虛擬網卡或路由規則未重新載入的問題。

1. 結束客戶端，記錄基準結果，包括出口地區、DNS 網路歸屬與解析器數量。
2. 清除系統與瀏覽器 DNS 快取，啟動客戶端並造訪一個從未測試過的網域。
3. 連續執行 3 輪檢測，每輪至少間隔 10 秒，記錄本地電信業者解析器是否再次出現。
4. 中斷連線 15 秒後重新連線，再執行 3 輪檢測，確認設定在重新連線後仍然生效。
5. 切換一次 Wi-Fi 與行動網路，重新建立連線，檢查引導 DNS 與 TUN 路由是否能適應網路變化。

穩定的目標不是讓檢測頁面永遠只顯示一個位址，而是讓解析路徑可解釋、可重複。中國大陸網域依規則使用直連解析，遠端網域透過預定的解析器與出站處理，節點網域具備獨立的引導解析能力；這三部分同時成立，DNS 分流才算完整。