排查 v2rayN 與 v2rayNG 的 DNS 問題，必須同時確認「由誰發起解析」以及「DNS 連線從哪裡送出」。本文適合已能連上節點，但檢測結果出現本地電信業者的解析器，或遇到網域存取異常的使用者。先建立直連與代理的對照，再分別檢查桌面系統代理、Android VPN、遠端 DNS 與分流規則，最後透過日誌和重複測試確認結果。
一、DNS 洩漏的判定標準
DNS 洩漏是指 DNS 查詢未依預期的網路路徑傳送。例如，原本應透過代理存取的網域卻交由本地電信業者解析，查詢內容就可能暴露在本地 DNS 解析路徑中。網站顯示的對外 IP 是代理伺服器，只能代表該次網頁連線經過代理，無法證明 DNS 查詢也走了代理。
v2rayN 的系統代理只會影響遵循系統代理設定的應用程式，不會接管整台電腦的所有 DNS 流量。v2rayNG 的 VPN 模式可接管更多應用程式的流量，但排除的應用程式、瀏覽器的安全 DNS、系統私人 DNS 以及 IPv6 路由，都可能改變實際連線路徑。啟用 TUN 或 VPN 不是驗證的終點，而是開始檢查的起點。
| 檢測結果 | 代表的情況 | 接下來檢查 |
|---|---|---|
| 網頁 IP 已變更 | 網頁連線經由不同的出口 | 另外檢查 DNS 查詢路徑 |
| 出現本地電信業者的解析器 | 測試網域可能經由本地 DNS 解析 | 檢查瀏覽器、系統 DNS 與直連規則 |
| 解析器所在國家與節點不同 | 可能與公用 DNS 的 Anycast 或轉送機制有關 | 確認 DNS 服務業者與實際出口，不要只看國家 |
| 代理與本地解析器同時出現 | 可能存在多條解析路徑或回退機制 | 重複測試，並排除快取、應用程式分流與回退設定 |
結論：依網域用途判斷是否洩漏
分流設定可讓直連網域使用本地 DNS。需要優先修正的是代理網域意外經由本地 DNS 解析，而不是把所有本地解析紀錄都視為異常。
二、建立直連與代理的檢測對照
DNS 檢測網站通常會產生隨機子網域，再從權威 DNS 伺服器觀察遞迴解析器的來源。結果反映的是最後參與遞迴查詢的服務，不一定是用戶端設定的 DNS 位址。公用 DNS 的轉送與 Anycast 也會影響地理位置判定，因此應一併記錄服務業者、測試模式與目前的用戶端設定。
-
記錄基準結果
關閉用戶端的代理連線，使用同一個瀏覽器開啟 DNS 檢測網站，例如手動輸入
dnsleaktest.com。記錄網頁對外 IP、解析器服務業者、IPv4／IPv6 狀態，以及瀏覽器是否啟用安全 DNS。 -
啟用代理
啟動 v2rayN 或 v2rayNG，確認目前使用的節點與路由預設值。保持相同的網路、瀏覽器和檢測網站，再執行完整測試；兩次測試之間不要切換 Wi-Fi 與行動網路。
-
排除其他變因
暫時關閉瀏覽器自訂的安全 DNS 後重新測試，再單獨啟用安全 DNS 測試一次。每輪只變更一項設定，並分別標記「系統代理」、「TUN」或「VPN」，避免混淆不同連線方式的結果。
-
重複驗證
每種設定至少測試 2 次，並查看用戶端日誌。變更 DNS 設定後，請重新啟動核心或 VPN 連線；單純重新整理網頁可能仍使用舊快取，無法取代使用全新隨機網域進行測試。
在 Windows 上，可以使用以下命令查看實體網卡與虛擬網卡的 DNS 位址，並清除系統快取。清除系統快取不會同步清除瀏覽器快取，也不會自動改變應用程式選用的解析器。
Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClientServerAddress -AddressFamily IPv6
ipconfig /flushdns三、v2rayN：分開設定遠端 DNS 與直連 DNS
設定 v2rayN 時，必須區分三種用途：解析代理目標網域、解析直連目標網域，以及解析代理伺服器本身的位址。若代理伺服器使用網域名稱，必須先取得該伺服器的 IP 才能建立代理連線；若把這一步也強制送進尚未建立的代理，就可能形成 DNS 解析的循環依賴。
v2rayN 不同版本、介面類型與核心的 DNS 編輯介面可能有所差異。以下以提供「設定」→「DNS 設定」入口的介面為例；若畫面顯示 DNS 設定範本或 JSON 編輯器，請先備份原設定，再依用途修改對應核心的設定，不要直接貼上另一種核心使用的欄位。
-
備份目前設定
先記下主畫面目前的節點、路由預設值、系統代理狀態與 TUN 狀態，再前往「設定」→「DNS 設定」並保存原有內容。訂閱提供的是節點參數，不應預設為它已涵蓋本機所有 DNS 連線規則。
-
區分 DNS 解析用途
遠端 DNS 用於需要透過代理解析的網域，直連 DNS 則用於本地或直連網域。例如，
https://1.1.1.1/dns-query是 DoH 服務位址範例；它僅供參考，連線是否經過代理仍取決於實際路由設定。 -
檢查 DNS 解析的出口
檢查 DNS 設定與路由規則，確認遠端 DNS 連線會經由代理出口，直連 DNS 連線則使用直連出口。使用具有本地直連語意的 DNS 位址格式或特殊解析模式前，應先確認目前核心的處理方式，不要只憑「遠端 DNS」標籤判斷。
-
確認流量接管方式
若只有瀏覽器需要代理，先測試系統代理；若應用程式不遵循系統代理，再評估是否使用 TUN。啟用 TUN 後，請檢查 DNS 接管、網卡路由與 IPv6，避免同時保留多組互相衝突的虛擬網卡設定。
-
重新啟動後再次測試
儲存設定並重新啟動核心，再依照前一節重新檢測。若無法解析節點伺服器的位址，應先還原可用的引導解析路徑，而不是繼續增加代理規則。
| 解析方式 | 常見連接埠 | 需要確認的路徑 |
|---|---|---|
| 傳統 DNS | UDP 53、TCP 53 | 是否從實體網卡直接送出，或回退至 TCP |
| DoT | TCP 853 | 加密 DNS 連線是否依預期經由代理 |
| DoH | 通常使用 HTTPS 443 | DNS 服務位址、引導解析與 HTTPS 出口 |
DNS 加密與 DNS 代理是兩回事。DoH 可以加密用戶端與 DNS 服務之間的查詢，但若 DoH 連線直接透過本地網路送出，就不符合「DNS 流量經由代理出口」的目標。反過來說，傳統 DNS 若由代理通道承載，也不能據此認定查詢以明文從本地網路送出。
四、v2rayNG：檢查本地 DNS、VPN 與應用程式範圍
v2rayNG 使用 Xray 核心，並透過 Android VPN 介面接管應用程式流量。「啟用本地 DNS」中的「本地」通常是指用戶端內的 DNS 處理功能，不代表所有網域都會送交本地電信業者解析。實際流向仍由 DNS 設定、路由規則與 VPN 接管範圍共同決定。
-
檢查 DNS 設定
開啟側邊選單中的「設定」，尋找「遠端 DNS」、「直連 DNS」與「啟用本地 DNS」。這些項目可能分布在設定頁的不同區段；若目前版本沒有某個項目，請先確認用戶端版本與核心，不要尋找不存在的開關。
-
檢查應用程式範圍
前往「設定」→「應用程式分流」，確認瀏覽器與待測應用程式是否遭到排除。測試時可先關閉應用程式分流限制，確認 VPN 接管正常後，再逐一恢復排除項目。
-
排除私人 DNS 的影響
Android 常見的設定路徑為「設定」→「網路和網際網路」→「私人 DNS」，不同廠牌的名稱可能略有不同。記下原本的設定值，暫時關閉指定服務業者的主機名稱後進行對照測試；企業裝置或受管理的網路，請先確認管理政策。
-
重新建立 VPN 連線
中斷連線並重新啟動 v2rayNG 的 VPN，再檢查瀏覽器安全 DNS、IPv6，以及切換網路後的測試結果。只修改設定卻保留舊的 VPN 工作階段，可能無法套用最新設定。
排查 v2rayNG 的 IPv6 問題時，也應分層檢查。DNS 回傳 AAAA 記錄，只代表解析結果包含 IPv6 位址；真正需要確認的是後續 IPv6 連線是否由 VPN 接管。可以暫時停用 IPv6 進行對照，但最終應修正流量接管或路由策略，不要把所有異常都歸因於 AAAA 記錄。
五、DNS 路由與 TUN：避免規則互相抵銷
Xray 內建 DNS、路由網域策略與嗅探功能各有不同用途。內建 DNS 負責解析，路由規則負責選擇出口，嗅探則會嘗試從連線中補充網域資訊。將路由網域策略改為某個值，不會自動讓所有系統 DNS 查詢都透過代理；啟用嗅探也不會接管瀏覽器自行發出的 DoH 連線。
- 先檢查範圍過大的直連規則：如果 DNS 服務位址符合排在前面的直連 IP 規則，後續的代理規則可能就不會生效。請查看實際產生的核心設定，確認規則順序。
- 保留引導解析路徑：代理伺服器與 DoH 服務若都使用網域名稱，應先確認各自最初由哪個 DNS 解析，避免啟動時形成循環依賴。
- 檢查企業內部網域：內部網域可能只能透過企業 DNS 解析，不適合將所有查詢強制送往公用 DNS。請針對網域範圍與可連線路徑分別設定。
- 確認 TUN 是否接管 DNS：確認 DNS 查詢進入虛擬網卡後由誰處理，以及直連出口如何避免再次進入 TUN 而形成循環。修改前請先保留可還原的原始設定。
- 謹慎啟用 FakeDNS：FakeDNS 會回傳虛擬位址以保留網域對應關係，本身不是獨立的加密 DNS 服務。若流量接管不完整，應用程式可能取得虛擬位址，卻無法正常連線。
結論：先固定連線方式，再調整 DNS 路由
先讓單一瀏覽器在一種連線模式下穩定通過測試，再逐項恢復分流、應用程式規則與瀏覽器安全 DNS。每次只恢復一項，才能找出是哪條路徑改變了 DNS 出口。
六、常見錯誤與最終驗收
DNS 故障不一定會表現為「洩漏」。遠端 DNS 連線誤走直連、DNS 位址無法連線，或節點位址缺少引導解析，都可能導致網頁無法開啟。日誌內容會隨核心與系統而異，以下列出可能出現的實際錯誤訊息片段，請搭配前後日誌中的目標位址與時間判斷。
lookup example.com: i/o timeout
原因：解析作業在逾時前未取得結果，可能是 DNS 服務無法連線或出口路徑錯誤。解決方式：先檢查 DNS 服務位址與出口規則，再測試是否能連線至同一服務；不要只是不斷切換網頁的目標節點。
dial tcp: lookup example.com: no such host
原因：名稱解析沒有取得可用結果，可能是網域拼寫錯誤、網域不存在或解析策略異常。解決方式：檢查實際網域，並使用另一條可用的 DNS 解析路徑進行比對；不要直接判定為代理驗證失敗。
context deadline exceeded
原因：作業超過截止時間。這不是 DNS 專屬錯誤，連線至 DNS 服務或目標伺服器時也可能發生。解決方式：根據前後日誌判斷失敗階段，再分別檢查 DNS、TLS 連線與代理出口。
DNS 封包擷取可補充網頁檢測，但只篩選 UDP 53 會漏掉 TCP 53、DoT 與 DoH。檢查實體網卡時，應留意 DNS 服務的目標位址與連線方向；若發現 443 連線，也要確認目標，不能把所有 HTTPS 流量都當成 DNS。沒有發現 53 連接埠的流量，也不足以單獨證明 DNS 解析完全依預期運作。
- 解析器符合用途：代理網域不再意外使用本地 DNS 解析路徑，內部網域或直連網域仍可正常解析。
- 出口與連線方式一致：分別測試系統代理、TUN 與 Android VPN，不要以其中一種方式的結果代替其他方式。
- 已排除快取影響：使用新產生的測試網域，修改設定後重新啟動相關連線，並至少再次測試 2 次。
- 切換網路後仍有效：Android 從 Wi-Fi 切換至行動網路，或桌面裝置從休眠中恢復後，重新確認 VPN、虛擬網卡與 DNS 狀態。
- 保留還原紀錄：記錄遠端 DNS、直連 DNS、路由預設值與瀏覽器安全 DNS 的最終設定；發生問題時逐項還原。
v2rayN 與 v2rayNG 的防 DNS 洩漏設定，最終目標是讓 DNS 查詢與目標連線各自遵循明確的路由規則。網頁可以開啟、對外 IP 已變更、公用 DNS 顯示不同地區，這些都不能取代路徑驗證。完成對照測試並保留設定紀錄，之後更換節點或網路時，才能及早發現變化。