即使網頁出口已切換，DNS 測試仍顯示本地電信業者時，應先分辨是瀏覽器、系統還是核心在解析，再決定要調整哪一層。本文以 Windows 版 v2rayN 為例，說明如何進行對照測試、檢查遠端 DNS 出站、確認 TUN 接管狀態，以及透過日誌排除問題。適合已匯入節點且連線正常，但想確認網域查詢是否依預期分流的使用者。
如何判斷 DNS 洩漏
DNS 的用途是將網域名稱轉換為 IP 位址。代理連線成功，只能代表某一條應用程式連線已經透過代理，不代表所有應用程式的網域查詢都走相同路徑。瀏覽器可能使用內建的加密 DNS，系統可能向路由器查詢，代理核心也可能為了連線節點或判斷路由而自行解析。這些路徑都需要分別檢查。
本文所說的 DNS 洩漏，是指原本應透過代理處理的網域查詢，卻意外送到本地網路的解析器。若設定原本就是讓中國大陸網域直連、其他網域走代理，則中國大陸網域使用本地 DNS 可能是預期行為。不能只因測試結果顯示本地地區，就認定整套設定失效。
v2rayN 是用戶端介面，實際的解析行為取決於所選核心、產生的設定檔，以及應用程式本身的設定。VMess、VLESS 等連線協定不會自動接管系統 DNS。測試頁顯示的通常是向測試網域權威伺服器發出查詢的遞迴解析器出口，不一定是代理節點位址；也不能只憑解析器所屬國家判斷查詢是否經過加密。
建立對照：先測出口，再測 DNS
先固定使用同一台電腦、同一個網路與同一個瀏覽器。在瀏覽器搜尋並開啟 DNSLeakTest 或 BrowserLeaks 的 DNS 測試頁；測試服務會收到查詢請求，若使用環境較敏感，請先閱讀其隱私權說明。請勿上傳訂閱網址、節點憑證或完整用戶端設定檔。
- 記錄直連基準。關閉 v2rayN 的系統代理與 TUN，並確認瀏覽器未手動設定代理。記下目前的公網出口、測得的解析器名稱，以及瀏覽器安全 DNS 的狀態。
- 只啟用系統代理。選擇可用節點，從系統匣選單點選「系統代理」→「自動設定系統代理」。確認網頁出口如預期改變後，再完整執行一次 DNS 測試。
- 一次只調整一個變數。保持節點與路由模式不變，只調整 DNS 或瀏覽器安全 DNS，然後重新測試。不要同時更換節點、切換網路及啟用 TUN，否則無法判斷問題來源。
- 建立 TUN 對照測試。確認並記錄系統代理狀態後，再啟用 TUN，使用相同測試項目重新測試。切換後請重新啟動瀏覽器，避免連線池沿用先前建立的連線。
| 觀察結果 | 可能原因 | 下一步 |
|---|---|---|
| 網頁出口沒有改變 | 瀏覽器未使用代理，或目標被路由規則設定為直連 | 先檢查系統代理與路由規則是否命中，不必急著修改 DNS |
| 出口已改變，解析器仍是本地電信業者 | 可能存在本地查詢路徑，也可能是符合預設的直連規則 | 確認測試網域的路由規則與瀏覽器 DNS 設定 |
| 出現多個公共解析器 | 瀏覽器、核心或上游服務可能走不同的解析路徑 | 對照日誌與封包擷取結果，逐一確認來源 |
| 解析器位址與節點位址不同 | 節點可能使用獨立的遞迴解析服務或公共 DNS | 不要單憑這點就判定發生洩漏 |
結論：依預期路徑判斷，不看位址數量
先釐清「哪些網域必須透過代理解析」，再檢查這些網域實際送出的查詢。測得多個解析器並不是獨立的洩漏證據；真正需要排除的是目標網域意外交由本地解析器處理。
系統代理與瀏覽器 DNS：先排除繞道
系統代理主要影響遵循系統代理設定的應用程式，並不會接管所有網路連線。有些程式會自行解析網域後再連線，有些則完全不使用系統代理。瀏覽器的安全 DNS，也就是透過 HTTPS 傳送的 DNS 查詢，是另一條需要確認出站路徑的連線；啟用安全 DNS 不代表查詢就會自動經由代理。
- 確認監聽位址與連接埠。在 v2rayN 主畫面查看目前的本機監聽資訊；若設定中有「設定」→「參數設定」→「基本設定」，請核對其中的本機監聽連接埠。不同版本的介面可能採用不同分類名稱，請勿直接套用範例連接埠。
- 固定瀏覽器的 DNS 解析方式。在瀏覽器設定中搜尋「安全 DNS」，記下服務提供者與啟用狀態。診斷時可暫時關閉此功能，讓瀏覽器改用系統或代理提供的解析路徑，再另外測試啟用後的行為。
- 檢查手動 SOCKS 設定。若應用程式提供「透過代理解析網域」選項，請確認已啟用。若應用程式先在本機解析，再將 IP 位址交給 SOCKS 代理，網頁雖然仍可能正常開啟，但網域查詢已在本地完成。
- 區分 WebRTC 與 DNS。WebRTC 位址暴露屬於不同的測試項目。同一個測試頁若顯示其他位址，不代表所有結果都與 DNS 有關。
不要將 Windows 網卡 DNS 設為 127.0.0.1，並把它當成通用修復方式。只有本機確實有 DNS 服務在該位址的 53 連接埠監聽時，這項設定才有用。v2rayN 的本機 HTTP 或 SOCKS 代理連接埠不是系統 DNS 服務連接埠，兩者不能互換。
v2rayN DNS 設定：伺服器與出站都要檢查
修改前請先備份目前的設定，並記下使用中的核心。進入「設定」→「DNS 設定」；部分介面會將相關選項放在參數設定中。若找不到同名選項，請依實際介面中的 DNS 設定操作，不要直接貼上其他核心的 JSON。欄位名稱、可用範本與 DNS 路由功能會因核心而異。
- 釐清直連解析與代理解析的用途。若保留分流，直連 DNS 服務應用於預期直連的網域，遠端 DNS 服務則用於需要走代理的網域。若目標是讓所有業務網域都透過代理解析，測試時就不能保留會將這些網域交給直連 DNS 的規則。
- 指定可用的遠端服務。DNS 伺服器可使用一般 DNS，或核心支援的加密 DNS。只填入公共 DNS 位址並不會改變出站路徑；例如將伺服器改成
1.1.1.1，但查詢仍從本地網路直接送出，就沒有達成「透過代理查詢」的目標。 - 確認 DNS 查詢的路由。確認連往遠端解析器的連線使用預期的代理出站，而不是被私有位址、地區位址或其他範圍過廣的規則提前設為直連。DoH 通常使用 443 連接埠，不能只新增一條針對 53 連接埠的規則，就認為已涵蓋所有 DNS 查詢。
- 處理首次解析的依賴關係。若代理節點位址是網域名稱，通常必須先解析出節點位址才能建立代理。若 DoH 伺服器位址也是網域名稱，也要先解決該伺服器的首次解析問題。請為必要的啟動解析指定明確路徑，避免陷入「建立代理需要 DNS，但 DNS 又必須依賴尚未建立的代理」的循環。
- 儲存設定並重新啟動核心。確認啟動日誌沒有異常，再使用新的網域進行測試。若只儲存設定而未重新載入，測試結果可能仍反映舊設定。
路由分流與 TUN：將系統查詢納入檢查
TUN 透過虛擬網卡接管符合路由條件的 IP 流量，適合不遵循系統代理設定的程式。不過啟用 TUN 不代表所有 DNS 查詢都會自動交由核心解析器處理。請確認目前使用的核心是否啟用 DNS 接管或劫持功能、接管範圍為何，以及是否存在排除路由。不同核心可能有名稱相同、意義卻不同的欄位，請勿直接照搬。
- 先確認 TUN 已成功啟動。依介面提示提供必要權限，並查看日誌是否出現虛擬網卡建立失敗、路由新增失敗等訊息。開關顯示已啟用，但虛擬網卡尚未建立，不能視為接管成功。
- 檢查傳統 DNS 接管。確認發往 UDP/TCP 53 連接埠的查詢是否進入預期的解析流程。只處理 UDP 會漏掉 TCP 查詢；只涵蓋 IPv4 也可能遺漏 IPv6 路徑。
- 另外檢查加密 DNS 的出站路徑。瀏覽器內建的 DoH 屬於 HTTPS 流量，不是傳統的 53 連接埠查詢，應依其伺服器網域或位址檢查路由。
- 檢查規則順序。規則通常依核心規定的順序比對。範圍過廣的直連規則可能早於遠端 DNS 規則命中；請以產生的設定檔與日誌為準，不要只確認介面中是否列有某條規則。
- 檢查 IPv6 與多張網卡。無線網卡、有線網卡及其他隧道介面可能同時存在。請確認目前使用介面的 DNS 伺服器與路由；不要把停用 IPv6 當成永久通用解法，應優先補齊相應的接管路徑。
FakeDNS 並不是必須啟用的防洩漏開關。它會回傳虛擬位址並保留網域對應關係，以配合後續流量處理；解析入口與後續連線都必須進入相應的核心處理流程。若系統快取保留了虛擬位址，但流量離開這條處理路徑，反而可能無法連線。若一般遠端解析已能滿足需求，可先維持簡單設定。
Windows 驗證指令與常見錯誤排除
在 PowerShell 執行下列指令，可查看介面 DNS、檢查本機快取並清除系統快取。清除快取會影響本機其他應用程式下次的查詢，但不會清除瀏覽器的所有快取，也不會自動中斷既有連線。建議清除後完全結束瀏覽器，再重新開啟測試頁。
Get-DnsClientServerAddress
Get-DnsClientCache
Clear-DnsClientCache
Resolve-DnsName example.comResolve-DnsName 和 nslookup 不是用來測試瀏覽器代理的工具。只啟用系統代理時，這些工具的查詢通常不會因此改走 HTTP 或 SOCKS 代理；在 TUN 模式下是否會被接管，則取決於 DNS 接管設定與路由。指令成功只代表解析完成，不能證明查詢路徑符合預期。
錯誤：i/o timeout
原因：要求在期限內沒有收到回應。若此錯誤出現在 DNS 日誌中，可能是上游無法連線，或相關出站路徑不通。
處理方式：先查看同一筆日誌中的目標位址與出站路徑，再分別測試代理連線和 DNS 服務；不要一遇到逾時就不斷調高逾時值。
錯誤：no such host
原因：網域名稱解析失敗，可能是網域拼字錯誤、上游回覆不存在，或啟動解析路徑設定不正確。
處理方式：確認錯誤對應的是節點網域、DNS 服務網域還是存取目標，再檢查該網域使用的解析器；不要把所有解析失敗都歸咎於節點故障。
錯誤：connection refused
原因：目標連接埠拒絕連線。常見情況包括將 DNS 指向本機，但本機沒有 DNS 服務監聽，或填錯本機代理連接埠。
處理方式：對照介面顯示的實際監聽資訊，分清 DNS 的 53 連接埠與代理連接埠；若回送位址上沒有對應的監聽服務，請撤銷該設定。
若需要更進一步確認，可在實體網卡擷取傳統 DNS 流量，查看 UDP/TCP 53 的目標位址與測試網域。只檢查虛擬網卡上的請求，容易忽略最終出站。實體網卡上看見加密的代理流量是正常現象；沒有 53 連接埠流量，也不能排除查詢直接送往 DoH 服務的可能，因此仍須搭配瀏覽器設定與核心日誌判斷。
常見問題與修復後的複測標準
更換遠端 DNS 後，為什麼測試結果仍顯示原本的電信業者？
先確認瀏覽器是否使用獨立的安全 DNS，再確認 DNS 設定已儲存並重新啟動核心。接著檢查測試網域是否符合直連規則。只更換伺服器位址而不調整查詢的出站路徑，通常無法改變查詢經過的網路。
系統代理測試正常，其他程式還是可能發生 DNS 洩漏嗎？
有可能。測試頁只涵蓋目前瀏覽器發出的查詢。不遵循系統代理設定的程式，應分別檢查其代理與 DNS 選項，或啟用並驗證 TUN 接管；不要用一次瀏覽器測試代表所有應用程式。
測試頁顯示多個國家的解析器，代表設定一定有問題嗎？
不一定。公共解析服務可能使用分散式出口，位址資料庫也可能不準確。先關閉瀏覽器額外的解析路徑進行對照，再依出站日誌與實體網卡流量判斷；不要只因國家標籤不同就移除伺服器。
啟用 TUN 後所有網頁都無法開啟，應先調整什麼？
先關閉 TUN，恢復原本連線，再檢查虛擬網卡、路由權限與啟動解析循環。恢復到可正常運作的設定後，每次只調整一個項目；不要同時加入 FakeDNS、全域路由和新的 DNS 範本。
修復完成後，請分別記錄「系統代理測試、TUN 測試、實際應用程式測試」的結果。每次都確認網頁出口、解析器、瀏覽器安全 DNS 狀態與核心錯誤日誌。若保留中國大陸直連，請分開記錄預期直連與必須透過代理的查詢，避免將正常分流誤判為 DNS 洩漏。
- 必須透過代理的測試網域，沒有意外出現在本地明文 DNS 查詢中。
- 遠端 DNS 連線使用預期的出站路徑，日誌沒有持續逾時或啟動解析循環。
- 重新啟動用戶端與瀏覽器後，測試結果仍可重現；切換網路後請再次驗證。
- 若要恢復瀏覽器安全 DNS，請個別啟用並重新測試其連線路徑。