故障排查 預計閱讀 12 分鐘

DNS 洩漏檢測與修復實作：讓網域解析與流量走同一條鏈路

說明什麼是 DNS 洩漏、代理已連線為何仍可能洩漏 DNS 查詢，並提供線上檢測及 v2rayN/v2rayNG DNS 設定修復方法，逐項確認結果。

代理用戶端顯示連線成功，只能證明節點握手和部分出站流量可用，不能直接證明網域解析也進入同一條代理鏈路。瀏覽器存取網站前，通常要先將網域解析成 IP 位址；如果這一步仍交由本機網路、路由器或電信業者 DNS 處理，雖然存取內容經過代理，查詢過哪些網域的 DNS 請求卻可能從另一條路徑送出。

排查 DNS 洩漏不能只看檢測頁面顯示哪個國家或地區，也不能把所有本地解析器都視為異常。需要同時確認應用程式流量接管方式、系統 DNS、瀏覽器安全 DNS、用戶端遠端 DNS 與路由規則，最後透過修改前後的對照結果判斷鏈路是否真正收斂。

本文速覽

本文適合已能連線 VMess、VLESS 等節點，但 DNS 檢測結果仍顯示本地解析器、網頁偶爾解析失敗或分流結果異常的使用者。操作從建立檢測基準開始，分別處理 v2rayN 與 v2rayNG，再用日誌、系統指令和重複測試確認修復結果。

DNS 洩漏發生在哪一段鏈路

一次常見的網頁請求至少包含「應用程式發起網域請求、DNS 回傳位址、應用程式連線目標位址、路由規則選擇出站」幾個階段。系統代理主要接管支援 HTTP 或 SOCKS 代理的應用程式連線，作業系統產生的 UDP 53 查詢不一定會自動進入代理。即使 Xray 核心設定了遠端 DNS，如果應用程式仍直接呼叫系統解析器，核心可能根本看不到這次查詢。

TUN 模式透過虛擬網卡接管更廣泛的 IP 流量，能將不讀取系統代理設定的程序以及 DNS 封包納入路由。Android 上的 v2rayNG 通常透過系統 VPN 介面完成類似接管。接管只是第一步，後續仍需確保 53、853 或 443 連接埠上的解析流量沒有被直連規則提前放行。

應用程式查詢網域 系統解析請求 用戶端接管 DNS 規則比對 代理鏈路出站
53
傳統 DNS 的 UDP/TCP 連接埠
853
加密 DNS 常見的 DoT 連接埠
443
DoH 常用的 HTTPS 連接埠
3 輪
基準、修復、重新啟動後複測

瀏覽器內建的安全 DNS 是另一個變數。瀏覽器可能繞過系統 DNS，直接向指定的 DoH 服務傳送 HTTPS 請求；這類請求在檢測頁面上會顯示為另一個解析服務。是否洩漏取決於這條 HTTPS 連線最終走直連還是代理，而不是取決於頁面上是否出現熟悉的 DNS 名稱。

建立可重複的 DNS 檢測基準

先不要急著修改設定。記錄修復前的狀態，才能區分實際改善與檢測頁面快取。建議使用同一個瀏覽器、同一個網路和同一個節點完成三輪測試，每輪之間關閉檢測分頁並等待約 30 秒。標準測試用於快速觀察解析器，擴充測試則會觸發更多隨機網域查詢，更容易發現本地 DNS 與遠端 DNS 同時存在的情況。

  1. 記錄目前模式

    記錄用戶端名稱、核心類型、節點協定和接管模式。例如 v2rayN 7.x、Xray 核心、VLESS 節點、系統代理模式；不要只寫「代理已開啟」。

  2. 暫停其他網路工具

    退出同時執行的其他代理、企業網路連線和獨立 DNS 工具，避免多個虛擬網卡或本機監聽連接埠共同影響結果。

  3. 檢查瀏覽器 DNS

    在瀏覽器的隱私權或安全性設定中記錄「使用安全 DNS」的開關與提供者。首次建立基準時可暫時關閉此功能，用於判斷系統與用戶端路徑。

  4. 執行擴充檢測

    開啟可信任的 DNS 洩漏檢測頁面，完成標準測試與擴充測試，記錄解析器名稱、位址數量、地區及首次查詢耗時。

  5. 中斷後對照

    中斷用戶端並重新整理網路連線，再測試一次。如果連線前後的解析器完全一致，而網頁出口位址明顯變化，DNS 很可能沒有跟隨代理鏈路。

Windows 可使用系統指令輔助確認目前網卡取得的 DNS 位址。這只能說明系統準備向哪裡查詢，不能單獨證明封包最終經過哪個出站，但適合用來定位路由器位址、舊虛擬網卡和手動填寫的解析器。

Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName example.com
ipconfig /flushdns

如果清單中同時出現實體網卡、虛擬網卡和已中斷連線的舊介面卡，先關注目前擁有預設路由的網卡。修改設定後執行快取清除，再重新解析隨機網域；反覆查詢同一個網域可能直接命中系統、瀏覽器或用戶端快取，無法觸發新的外部請求。

錯誤：DNS request timed out.

原因與解法：系統設定的 DNS 無法連線，或 53 連接埠遭目前網路封鎖。先恢復為可存取的解析器，再檢查 TUN 路由是否接管 DNS。

錯誤：server failed

原因與解法：解析器回傳 SERVFAIL，常見原因包括上游故障、網域驗證失敗或轉送鏈設定錯誤。更換遠端 DNS 後清除快取並重新測試。

v2rayN 修復路徑：分開處理系統代理與 TUN

v2rayN 使用系統代理時，瀏覽器的 HTTP/HTTPS 請求通常會進入本機代理連接埠，但 Windows DNS 仍可能直接傳送至網卡設定的解析器。常見的本機監聽組合是 SOCKS 10808 與 HTTP 10809，實際數值以「設定」→「參數設定」中的本機連接埠為準。連接埠正常監聽並不代表 UDP 53 已被接管。

如果目標只是讓支援代理的瀏覽器使用指定的解析路徑，可以同時調整瀏覽器安全 DNS，並確認該 DoH 請求透過代理傳送。如果目標是涵蓋更多桌面程式、命令列工具和系統解析請求，應使用 TUN，並檢查 DNS 劫持與路由規則。兩種方案的涵蓋範圍不同，不應將系統代理模式的檢測結果直接等同於 TUN。

  1. 確認核心類型

    進入「設定」→「參數設定」→「Core 類型」，確認目前設定使用的核心與節點協定相容。修改核心後重新啟動一次用戶端，避免舊程序繼續佔用設定。

  2. 設定遠端 DNS

    開啟「設定」→「DNS 設定」，在遠端 DNS 中填寫明確的解析服務。可先使用 1.1.1.1 或 8.8.8.8 進行單一變數測試，確認穩定後再依網路環境調整。

  3. 啟用 TUN 接管

    在主介面啟用 TUN 模式，並允許建立虛擬網卡所需的系統權限。啟用後確認虛擬介面卡存在，且預設路由沒有被其他網路工具覆寫。

  4. 核對 DNS 分流

    檢查路由規則中針對 DNS 伺服器位址、UDP 53、TCP 853 和所用 DoH 網域的規則。預期走代理的查詢不能被「區域網路直連」或過寬的 IP 規則提前命中。

  5. 清除快取後重新啟動

    關閉瀏覽器，執行 ipconfig /flushdns，重新啟動 v2rayN 核心後再開啟檢測頁面。使用新的隨機網域觸發查詢，避免讀取舊快取。

Xray 的 DNS 模組可以為路由判斷解析網域，也可以將查詢交給指定上游，但不會憑空接管所有系統請求。只有請求進入核心，DNS 設定才有機會生效。如果日誌中只有目標連線記錄，沒有對應的 DNS 查詢，應優先檢查接管模式，不要反覆更換上游位址。

錯誤：failed to lookup ip

原因與解法：核心無法從目前的 DNS 設定取得節點或目標位址。檢查伺服器位址拼寫、遠端 DNS 可達性和 DNS 出站規則，然後重新啟動核心。

錯誤：no such host

原因與解法：網域回傳不存在，或本機快取保留了失敗結果。確認訂閱中的伺服器網域完整，清除系統 DNS 快取後改用其他遠端解析器重新測試。

錯誤：context deadline exceeded

原因與解法：上游 DNS 在逾時期限內沒有回應，常見於 DoH 連線被直連規則阻斷。檢查 443 連接埠出站和網域規則，必要時先改用一般遠端 DNS 進行定位。

v2rayNG 修復路徑：VPN 接管與私人 DNS 協同

v2rayNG 使用系統 VPN 介面接管流量時，DNS 通常比桌面系統代理更容易進入隧道，但仍可能受到「私人 DNS」、分應用程式代理、繞過區域網路和路由規則影響。v2rayNG 使用 Xray 核心時，遠端 DNS、網域策略和 FakeDNS 屬於不同設定項目；排查洩漏時，先建立一般遠端 DNS 的穩定基準，再決定是否啟用 FakeDNS。

系統私人 DNS 通常使用 DoT，也就是 TCP 853。若私人 DNS 保持指定主機名稱，系統會繼續嘗試連線至該服務。這條連線是否經過目前節點，取決於 VPN 接管範圍和分流規則。為了隔離變數，首次排查可將系統「設定」→「網路和網際網路」→「私人 DNS」暫時設為「自動」或「關閉」，完成 v2rayNG 驗證後再逐項恢復。

  1. 檢查執行模式

    確認 v2rayNG 已顯示 VPN 連線狀態，狀態列中存在系統 VPN 標誌。若只修改設定但沒有啟動連線，遠端 DNS 設定不會接管其他應用程式的請求。

  2. 填寫遠端 DNS

    開啟左上角選單「設定」→「遠端 DNS」，填寫一個明確可達的解析位址。測試階段不要同時填寫多個行為未知的上游，以免難以判斷結果原因。

  3. 核對本地 DNS

    在「設定」中檢查「本地 DNS」與「啟用本地 DNS」。本地 DNS 主要處理用戶端側的查詢入口，遠端 DNS 則決定進入核心後的上游解析路徑，兩者不能混為一談。

  4. 關閉分應用程式繞過

    排查期間暫時關閉分應用程式代理，或確保瀏覽器與檢測工具位於代理清單內。被排除的應用程式會直接使用實體網路，檢測結果自然會與節點出口不同。

  5. 重新連線並複測

    停止連線，等待約 10 秒後重新啟動。強制結束瀏覽器後重新開啟，完成兩輪擴充檢測，並與行動網路及無線網路分別記錄的結果進行對照。

v2rayNG 與 v2flyNG 的核心實作不同，設定名稱和可用功能也可能隨版本調整。v2rayNG 的 Xray DNS 設定不能原樣套用於 v2flyNG 的 v2fly 核心設定。遷移訂閱只會匯入節點資訊，不會自動複製裝置上的 DNS、路由與分應用程式設定；更換用戶端後應重新建立基準。

錯誤：Unable to resolve host

原因與解法：應用程式或核心未取得網域解析結果。先確認 VPN 已連線，再檢查遠端 DNS、系統私人 DNS 和目前網路是否封鎖對應連接埠。

錯誤：network is unreachable

原因與解法：DNS 上游被路由至不可用的介面，常見於無線網路切換後舊 VPN 路由未更新。停止 v2rayNG，切換一次網路後重新連線。

複測結果怎樣才算修復完成

修復完成不代表檢測頁面只能出現一個位址。公共 DNS 服務可能使用任播，同一服務在不同查詢中回傳多個出口；部分檢測頁面還會將解析器前端與實際遞迴節點分開顯示。更可靠的標準是：連線用戶端後不再出現家用路由器、目前網路業者或明確不在預期中的本地解析器，且重新啟動用戶端、瀏覽器和裝置後結果仍一致。

還要驗證分流。如果中國大陸網域依規則直連、其他網域走代理，DNS 也可能依網域分組使用不同上游，這是設計結果，不應一味追求「全部只有一個解析器」。關鍵是每組查詢都與對應出站一致，避免先用本地 DNS 取得受網路影響的位址，再將連線交給代理。

出口位址變了，DNS 結果為什麼沒變？

系統代理只接管網頁連線，系統 DNS 仍從實體網卡送出。v2rayN 可改用 TUN 並檢查 DNS 路由；修改後清除快取再測試。

檢測頁面顯示兩個遠端解析器，正常嗎？

可能正常。確認兩者都屬於所選上游或其遞迴節點，並重複三輪測試。若中斷代理後其中一個仍固定出現，再檢查本地網路設定。

啟用 FakeDNS 就一定能解決嗎？

不能直接下結論。FakeDNS 會使用假位址保存網域對應，適合搭配 TUN 與網域分流，但無法修復未被接管的查詢。應先確認 DNS 封包已進入核心。

更換節點後還需要重新檢測嗎？

需要。不同節點可能套用不同路由、出口地區和 DNS 上游。至少執行一次標準測試；若解析器出現異常變化，再執行擴充測試。

網頁正常但訂閱更新失敗，該怎麼辦？

訂閱更新程序可能使用獨立的網路路徑。檢查訂閱設定是否允許透過代理更新，並在核心日誌中尋找網域解析逾時或連線逾時記錄。

最終驗收清單

  • 重新啟動用戶端後節點可正常連線，VMess 或 VLESS 握手日誌中沒有持續出現解析錯誤。
  • 標準測試與擴充測試都未出現目前的家用路由器或非預期電信業者解析器。
  • Windows 的實體網卡、TUN 虛擬網卡和舊虛擬介面卡不存在互相衝突的預設路由。
  • Android 的私人 DNS、分應用程式代理和 v2rayNG 遠端 DNS 設定符合目前的接管目標。
  • 瀏覽器安全 DNS 的開關已完成記錄，恢復後再次確認其 HTTPS 請求經由預期出站。
  • 切換節點、切換無線網路與行動網路後至少各複測一次，結果沒有回到本地解析路徑。

如果複測仍不穩定，請依「應用程式是否被接管、DNS 請求是否進入核心、上游是否可達、路由是否命中、快取是否已清除」的順序檢查。不要同時修改 TUN、DNS、路由和瀏覽器四組設定；每次只改變一個變數並保存結果，才能找出真正影響鏈路的設定。

下載用戶端