v2rayN DNS 洩漏怎麼檢測：三種排查方法與防洩漏設定步驟

先確認 DNS 洩漏的判定標準

DNS 負責將網域名稱轉換為 IP 位址。應用程式存取尚未快取的網域時，通常會先送出解析請求，再連線至解析出的位址。代理連線正常，不代表解析請求一定經過代理：系統代理主要接管支援 HTTP 或 SOCKS 的應用程式流量，Windows DNS Client 發出的 UDP 53 查詢仍可能交由目前網路介面卡使用的 DNS 伺服器處理。

判斷是否洩漏不能只看檢測頁面列出幾台伺服器。先記錄未啟用代理時的 DNS 提供者、城市與伺服器數量，再啟用 v2rayN 重複測試。若啟用代理後仍持續出現相同電信商、相同地區的解析伺服器，且日誌確認查詢未進入 Xray，才有充分理由按洩漏處理。

瀏覽器內建的安全 DNS 也會改變測試結果。瀏覽器可以直接向指定的 DoH 服務傳送 HTTPS 查詢，此時檢測頁面看到的解析伺服器不一定是系統 DNS，也不一定來自 v2rayN。排查期間請開啟瀏覽器的「設定」→「隱私權和安全性」→「安全性」→「使用安全 DNS」，記錄目前選項；為建立一致的基準，可暫時關閉此功能，完成檢測後再恢復原設定。

方法一：使用瀏覽器檢測網站進行兩輪比對

先退出其他代理工具，只保留 v2rayN。開啟 v2rayN 主視窗，在底部確認目前已選取伺服器，並將系統代理切換為「自動設定系統代理」。瀏覽器測試適合快速發現出口位置與 DNS 位置明顯不一致的問題，但無法單獨證明是哪個程序發出了查詢。

1. 清除舊快取

   關閉所有瀏覽器視窗，以系統管理員身分開啟終端機並執行 ipconfig /flushdns，看到「已成功刷新 DNS 解析快取」後重新開啟瀏覽器。

2. 記錄直連基準

   將 v2rayN 系統代理切換為「清除系統代理」，造訪 dnsleaktest.com，執行 Standard test，記錄伺服器名稱、國家或地區及結果數量。

3. 啟用系統代理

   返回 v2rayN，選擇「自動設定系統代理」，確認延遲測試正常，再開啟新的瀏覽器隱私視窗，避免舊連線與 DNS 快取影響結果。

4. 重複檢測兩次

   連續執行兩輪 Standard test，每輪間隔約 30 秒。若代理出口已變更，而 DNS 仍顯示直連基準中的電信商名稱，請繼續執行命令列檢測。

檢測頁面可能同時列出多個公共解析節點。公共 DNS 常採用 Anycast，同一服務會被調度至不同城市，因此「DNS 城市與代理出口城市不同」本身不等於洩漏。重點是比對提供者是否屬於本地寬頻或行動網路，以及關閉代理時出現的伺服器是否原樣保留。

如果只有某個瀏覽器出現異常，而其他瀏覽器的測試結果正常，應優先檢查該瀏覽器的安全 DNS、擴充功能設定與背景連線。此時不要立即修改 v2rayN 全域設定，否則可能把瀏覽器自身的解析行為誤判為核心問題。

方法二：使用 nslookup 區分系統 DNS 與代理 DNS

nslookup 預設會直接呼叫系統設定的 DNS 伺服器，不會因為啟用一般 HTTP 系統代理就自動改走代理。因此，只啟用「自動設定系統代理」時，命令仍顯示路由器位址或電信商 DNS 並不意外；這正好表示系統層級的 UDP 53 未被一般代理接管。

開啟 Windows 終端機，先執行不指定伺服器的查詢。輸出頂端的 Server 與 Address 是目前的系統解析器，常見位址包括家用路由器的 192.168.1.1、區域網路閘道或網路介面卡取得的 DNS。接著指定解析伺服器再次查詢，用來確認本機網路是否允許該路徑。

ipconfig /flushdns
nslookup example.com
nslookup example.com 1.1.1.1
nslookup -type=AAAA example.com

• 預設查詢顯示路由器位址：系統 DNS 仍交由區域網路閘道處理，一般系統代理未接管此請求。
• 指定伺服器查詢逾時：網路可能限制 UDP 53，或防火牆阻擋終端機請求；不能據此判定代理節點故障。
• A 記錄正常、AAAA 逾時：請檢查本地 IPv6 可用性與 v2rayN 的查詢策略，不要只修改 IPv4 DNS。
• 結果短時間內沒有變化：可能命中 Windows、瀏覽器或 Xray 快取，請清除快取並改用先前未造訪過的網域重新測試。

若要驗證 TUN 是否接管系統查詢，請先啟用 TUN，再重複執行預設的 nslookup。此時不能只觀察 Server 欄位，因為該欄位可能仍顯示原網路介面卡位址；還應同時開啟 v2rayN 日誌，確認 UDP 53 請求是否進入 TUN 入站、符合 DNS 規則並交由預期出站處理。

方法三：從 v2rayN 與 Xray 日誌確認路徑

日誌可以回答兩個關鍵問題：查詢是否進入核心，以及進入後經由哪個出站。開啟 v2rayN 的「設定」→「參數設定」→「基礎設定」，將日誌層級暫時調整為 info；儲存後重新啟動核心，再開啟「說明」→「檢視日誌」。不同小版本的日誌入口文字可能顯示為「日誌」或「檢視執行日誌」，但都應查看目前 Xray 執行個體的即時輸出。

1. 重新啟動核心

   在主視窗執行「伺服器」→「重新啟動服務」，確保剛修改的 DNS 與日誌層級套用至目前產生的設定。

2. 製造新的查詢

   執行 ipconfig /flushdns，再造訪一個先前未開啟的網域，避免快取使日誌中沒有查詢記錄。

3. 搜尋連接埠

   在日誌中搜尋 :53、udp、dns 與目標網域，檢查請求是否來自 TUN 入站或應用程式代理入站。

4. 核對出站

   確認日誌中的 outbound 或 detour 指向預期的代理標籤；若命中 direct，請返回路由設定，檢查 DNS 伺服器 IP 與連接埠規則。

在系統代理模式下，瀏覽器透過 SOCKS 或 HTTP 入站傳送網域名稱時，Xray 可以在核心端解析；但如果應用程式先在本機完成解析，再將 IP 位址交給代理，日誌只會看到目標 IP，無法從代理請求還原原始網域名稱。TUN 模式能涵蓋更多系統流量，但仍須正確設定 DNS 劫持與路由，否則 UDP 53 可能像一般流量一樣直連。

在系統代理模式下設定遠端 DNS 與 DNS 出站

如果主要使用瀏覽器與明確支援代理的桌面應用程式，可以保留系統代理模式。開啟 v2rayN「設定」→「DNS 設定」，選擇 Xray 對應的 DNS 設定頁。中國大陸網域與其他地區網域可以分開解析，但遠端解析伺服器必須同時符合可達性與路由方向要求，不能只填入位址而不檢查流量走向。

遠端 DNS 使用 DoH 時，通常會透過 TCP 443 建立 HTTPS 連線，比裸連 UDP 53 更容易納入代理路由。設定後還要檢查遠端 DNS 網域本身如何完成首次解析：如果該網域必須先經由本地 DNS 才能取得位址，就會形成引導依賴。可使用穩定可達的引導解析器，或讓相關 DNS 伺服器位址依明確規則出站。

• 查詢策略：網路沒有可用 IPv6 時，請選用優先 IPv4 的策略，避免 AAAA 查詢逾時拖慢首次連線；需要雙堆疊時保留 A 與 AAAA 查詢並分別驗證。
• 網域策略：路由依賴 geosite 規則時，盡量保留網域資訊，避免過早只依解析後的 IP 進行比對。
• DNS 出站：內建的 dns-out 用於將符合條件的 DNS 流量交給核心 DNS 模組，它不是任意公共 DNS 位址的別名。
• 連接埠規則：需要處理傳統查詢時，請比對 UDP/TCP 53；DoH 是 HTTPS 流量，應依目標網域、目標 IP 與 443 連接埠決定代理或直連。

進入「設定」→「路由設定」，檢查是否存在將 DNS 伺服器 IP 強制送往 direct 的高優先級規則。如果遠端 DNS 計畫透過代理存取，這類規則會造成設定目標互相衝突。規則會依目前核心與產生設定的順序進行比對，修改後應重新啟動服務，並在日誌中確認最終出站標籤。

以 TUN 模式接管系統層級 DNS 請求

遊戲啟動器、命令列工具與部分桌面程式不會遵循 HTTP 系統代理。需要涵蓋這些程式時，請在 v2rayN 主視窗啟用「Tun模式」，再開啟「設定」→「參數設定」→「Tun模式設定」。以 v2rayN 7.13.3 為例，應檢查 TUN 實作、嚴格路由模式、MTU 與 DNS 接管相關選項，儲存後讓核心完整重新啟動。

1. 關閉衝突的網路介面卡

   先退出其他會建立虛擬網路介面卡的網路程式，避免預設路由、介面指標與 DNS 接管規則互相覆寫。

2. 啟用嚴格路由

   在「設定」→「參數設定」→「Tun模式設定」中啟用嚴格路由，讓受管理流量依 TUN 路由表處理，減少查詢從原實體網路介面卡繞出的機會。

3. 檢查 MTU

   先使用預設值；若網頁載入不完整，可從 1500 調整為 1400 後重新測試。MTU 會影響封包傳輸，不應作為排查 DNS 洩漏時的第一個修改項目。

4. 重建 TUN

   關閉後再開啟「Tun模式」，確認狀態區沒有啟動錯誤，並在 Windows 網路介面卡清單中看到目前的虛擬介面。

5. 驗證 UDP 53

   執行新的 nslookup 查詢，在即時日誌中確認 UDP 53 進入 TUN 入站並符合 DNS 處理規則。

啟用 TUN 後若完全無法解析，先不要頻繁更換節點。檢查防火牆是否允許 v2rayN 與 Xray 存取網路，確認虛擬介面已取得有效路由，並查看日誌判斷是查詢逾時、規則拒絕還是 TUN 啟動失敗。能連線至節點 IP、但節點網域無法解析時，應重點檢查引導 DNS。

如果 TUN 模式下瀏覽器正常而 nslookup 逾時，可能是 DNS 劫持只涵蓋部分協定，或查詢遭嚴格路由攔截。請分別測試 UDP 53、TCP 53 與 DoH 443，並確認 DNS 規則位於一般直連規則之前。完成修改後重新執行兩輪瀏覽器檢測，不能只依賴 TUN 狀態顯示。

根據結果定位快取、IPv6 與規則衝突

修改 DNS 後檢測結果沒有立即變化，最常見的原因是快取。Windows DNS Client、瀏覽器、Xray 核心與上游解析器都有獨立快取。請先關閉瀏覽器，執行 ipconfig /flushdns，重新啟動 v2rayN 核心，再使用未造訪過的網域測試。只重新整理網頁通常不足以產生新的 DNS 查詢。

IPv6 也需要單獨檢查。系統可能透過 IPv4 連線代理，卻繼續從實體網路介面卡傳送 AAAA 查詢；或者先取得 IPv6 位址，再因目前網路沒有完整的 IPv6 路由而等待逾時。使用 nslookup -type=AAAA 與日誌比對，確認查詢是否被接管以及回傳位址是否可達。

• 只有瀏覽器異常：檢查安全 DNS 與瀏覽器快取，不要先修改全域路由。
• nslookup 顯示本地 DNS、日誌沒有記錄：一般系統代理未接管系統查詢；需要全域涵蓋時請檢查 TUN。
• 日誌有查詢但命中 direct：調整 DNS 伺服器網域、IP 與連接埠所對應的路由優先級。
• 日誌有查詢且經由 proxy、檢測仍異常：檢查檢測頁面是否使用瀏覽器獨立的 DoH，並改用另一個瀏覽器進行比對。
• 啟用 TUN 後全部逾時：檢查虛擬網路介面卡、防火牆、嚴格路由與引導 DNS，不要把節點延遲當作唯一依據。

最終驗收應包含三項：瀏覽器檢測不再重複出現直連基準中的電信商解析器；新的 nslookup 查詢在 TUN 情境下可從日誌追蹤；Xray 日誌顯示 DNS 流量命中預期出站。三項結果一致後，再將暫時提高的日誌層級恢復，減少長期日誌容量。