適合排查「網頁已走代理,DNS 檢測卻顯示本地網路業者」的情況。先分辨瀏覽器、系統與核心的解析路徑,再依序檢查一般代理、遠端 DNS、TUN 與 FakeDNS。每次只調整一個變數,最後用檢測網站、命令列與日誌交叉驗證,避免把正常的直連解析誤判為洩漏。
DNS 洩漏是什麼:分開檢視網頁出口與 DNS 解析出口
DNS 負責將網域名稱轉換為 IP 位址。網頁連線走代理,不代表網域查詢也走代理。如果原本應交由代理處理的網域,卻被應用程式提前送到本地網路的解析器,本地網路仍可能得知這些查詢。這種解析路徑不符預期,才是需要修正的問題。
v2rayN 是桌面用戶端,實際解析行為取決於目前使用的核心、入站方式與產生的設定。VMess、VLESS 等協定名稱無法直接判斷 DNS 是否洩漏;單純更換協定,通常也無法修正瀏覽器自行解析或路由順序錯誤的問題。
這個流程是用來排查的模型,並非所有要求都會嚴格依照相同順序執行。應用程式可能先在本機解析;核心也可能為了比對 IP 規則而先進行解析。排查時要確認兩件事:由誰發起查詢,以及查詢經由哪個出站傳送。
- 遠端 DNS:負責解析需要透過代理查詢的網域。伺服器位於遠端,不代表查詢就會自動經由代理傳送。
- 直連 DNS:負責解析明確允許直連的網域,目的是讓解析路徑符合本地連線方式。
- 瀏覽器安全 DNS:瀏覽器自行使用的加密解析通道,可能會略過系統 DNS 設定;是否也會略過代理,則取決於連線路徑。
- 代理節點網域解析:連線至代理伺服器之前,可能就必須先完成解析;不能依賴尚未建立的同一條代理連線來解析。
DNS 洩漏檢測:先記錄基準,再比較代理結果
開啟 DNSLeakTest 等檢測網站,執行標準或進階測試,記錄解析器的位址、網路業者與所在地區。檢測網站通常顯示的是最終遞迴解析器的出口,不一定是電腦直接連線的 DNS 位址;地區資料庫也可能不準,因此不能只憑「國家不同」就下結論。
- 建立基準:關閉代理與 TUN,重新啟動瀏覽器,前往不涉及敏感資訊的 DNS 檢測網站。記錄此時的公網出口與解析器所屬網路業者。
- 啟用一般代理:啟動已確認可用的節點,在 v2rayN 系統匣選單中選擇「系統代理」→「自動設定系統代理」。不同版本的選項名稱可能略有差異,請以實際介面為準。
- 重做相同測試:先確認網頁的公網出口已變更,再執行 DNS 檢測。盡量維持瀏覽器、節點與檢測網站不變。
- 排除瀏覽器設定影響:記下目前的「安全 DNS」設定,暫時關閉後再測一次。不要同時更換節點和路由,否則無法判斷是哪項變更造成影響。
- 測試其他應用程式:瀏覽器測試通過後,再檢查目標應用程式。系統代理不會接管全系統流量,單一瀏覽器通過測試不代表所有程式都正常。
用連接埠與命令驗證:區分本機解析和代理解析
先在「設定」→「參數設定」中查看目前的本機監聽連接埠與入站類型。以下以 10808 示範 SOCKS 入站;這不代表所有版本都使用此預設值。確認該連接埠支援 SOCKS 後,才能使用對應命令。
Windows 使用者可在 PowerShell 執行以下命令。第一條只確認本機連接埠能否建立 TCP 連線;後兩條才用來比較網域在哪裡解析。使用 curl.exe 可避免部分環境將 curl 視為其他命令的別名。
Test-NetConnection 127.0.0.1 -Port 10808
curl.exe --socks5 127.0.0.1:10808 --connect-timeout 10 -I https://example.com
curl.exe --socks5-hostname 127.0.0.1:10808 --connect-timeout 10 -I https://example.com
--socks5:由 curl 在本機解析目標網域,再將目標 IP 傳給 SOCKS 代理。--socks5-hostname:將網域交給 SOCKS 代理,由後續代理鏈路處理解析;這本身無法證明最後使用了哪一台 DNS 伺服器。- 只有第二條命令成功時,請優先檢查本機解析是否受阻;兩條都失敗時,先排查節點、監聽連接埠與出站連線。
nslookup example.com通常會查詢系統設定的 DNS,不會因為啟用系統 HTTP 代理就自動經由 v2rayN 傳送。不能只根據它的輸出,就否定瀏覽器測試結果。
結論:先確認要求已進入代理,再調整 DNS
如果本機連接埠無法連線,或應用程式仍直接建立連線,調整遠端 DNS 也不會接管這些要求。先修正入站與應用程式代理設定,再比較解析路徑,才能減少無效變更。
v2rayN 遠端 DNS 與直連 DNS:一併設定位址與出站路徑
修改前先備份用戶端設定,並記錄目前的節點、路由模式與 DNS 設定。前往「設定」→「DNS 設定」,查看目前核心提供的選項;若該版本將 DNS 設定放在參數設定頁,請使用實際頁面中的 DNS 分類進行調整。不同核心的設定結構並不通用,請勿將同一段 JSON 貼入所有核心。
| 用途 | 具體範例 | 需要確認的路徑 |
|---|---|---|
| 代理網域解析 | https://1.1.1.1/dns-query | 在支援此格式的遠端 DNS 欄位中填入位址,並確認查詢經由代理出站傳送。 |
| 允許直連的網域 | 223.5.5.5 | 僅用於明確規劃為直連的查詢;傳統 DNS 查詢通常未經加密。 |
| 代理節點網域 | 訂閱中伺服器位址所使用的網域名稱 | 準備一條能在代理建立前運作的解析路徑,避免形成循環依賴。 |
表格中的位址僅用來說明設定關係,並非必須採用的服務清單。遠端 DNS 選用 DoH 時,HTTPS 加密只能保護傳輸內容;如果 DoH 要求採直連,本地網路仍看得到你連線至哪個解析服務。若希望解析流量也離開本地出口,就必須一併確認路由設定。
- 先確定測試範圍:排查期間可暫時使用用戶端提供的全域代理路由模式,減少分流變數。測試完成後請恢復日常路由,不要將暫時模式當成最終設定。
- 設定遠端解析:填入目前核心支援的 DNS 位址格式。一般 DoH 與某些核心的本機直連解析模式並不相同,不能只看到 HTTPS 就認定查詢經由代理。
- 檢查規則順序:若有「境外 IP 直連」或涵蓋解析器位址的直連規則,先確認是否由該規則優先比對。規則通常由上而下比對;一旦符合直連規則,後續的代理規則便無法覆蓋。
- 處理節點的初始解析:節點使用網域名稱時,請保留獨立且可連線的解析方式。不要讓節點網域只能透過該節點解析。
- 儲存並重新啟動核心:確認日誌中沒有設定錯誤,再重做相同測試。若恢復分流路由後問題再次出現,請優先檢查網域規則與解析器的出站規則。
FakeDNS 與 TUN:解決以 IP 入站後無法識別網域的問題
FakeDNS 不會直接回傳網域對應的真實伺服器位址,而是配置一個合成 IP,並保存網域與合成位址的對應關係。後續連線到這個位址時,核心才能還原網域並繼續處理。它解決的是網域資訊傳遞問題,不是獨立的加密 DNS 服務,也不能取代代理出站規則。
Xray 常見的 FakeDNS IPv4 位址池為 198.18.0.0/15,但實際設定仍應以目前產生的設定為準。此範圍用於基準測試,並非真實網站的公網位址。只有要求與後續連線都由同一套支援 FakeDNS 的鏈路接管,對應關係才有作用。
- 先確認基本代理運作正常:尚未啟用 FakeDNS 時,先完成前述遠端 DNS 測試。節點仍無法連線時,不要同時開啟多項進階設定。
- 確認實作支援:檢查目前的 TUN 實作與核心是否支援對應的 FakeDNS 或 fake-ip 模式。名稱相近不代表設定通用;一般 SOCKS 情境也不必為了測試而強制啟用。
- 啟用 DNS 接管:依照目前用戶端提供的 TUN 與 DNS 接管選項操作。只啟用虛擬網卡,不代表所有 DNS 查詢都已交由核心處理。
- 確認網域能還原:檢查產生的設定是否能識別 FakeDNS 對應關係,必要時確認 FakeDNS 相關的嗅探設定。一般嗅探中只啟用 HTTP、TLS 識別,並不代表設定已完整。
- 清除快取後重新測試:重新啟動受測應用程式,並視需要執行下方的系統快取清除命令。瀏覽器可能另有快取,也請一併重新啟動。
ipconfig /flushdns
瀏覽器內建 DoH、應用程式內建 DNS 與 IPv6 都是常見的遺漏項目。只接管 UDP 53,無法自動處理所有 HTTPS 解析要求;若 IPv6 路由未納入接管,應用程式也可能透過另一條網路路徑連線。請依實際支援情況設定 IPv6,或在隔離測試時暫時關閉對應網卡的 IPv6,再比較結果;不要將暫時關閉視為通用解法。
設定 DNS 後無法開啟網頁:根據日誌找出故障層級
先查看日誌中的目標位址、使用的出站與失敗時間,再檢查錯誤關鍵字。以下列出常見錯誤片段,不代表每次都會出現完全相同的訊息。暫時提高日誌詳細程度有助於定位問題;分享日誌前,請遮蔽訂閱網址、節點憑證與個人瀏覽的網域。
錯誤:i/o timeout
原因:要求等待逾時,可能是 DNS 服務無法連線,也可能是代理連往解析服務的連線失敗。
解法:確認該行的目標是否為 DNS 位址;先還原上一組可用設定,確認節點正常後,再逐一檢查解析器位址與出站規則。
錯誤:no such host
原因:網域查詢未取得可用結果,可能與網域拼字、解析器回傳結果或節點網域的初始解析有關。
解法:先分辨失敗的是節點網域還是網站網域;若是前者,檢查建立代理前使用的 DNS;若是後者,則比較其他網域與其他解析器的結果。
錯誤:context deadline exceeded
原因:操作超過時限;若錯誤出現在 DoH 要求附近,請進一步確認連線、TLS 交握與代理路徑。
解法:檢查系統時間與相關日誌,確認解析服務可以連線。不要關閉憑證驗證來掩蓋憑證或時間問題。
修改後只有部分網站無法使用,優先檢查分流規則與 IPv6;所有網站都立刻無法使用,則優先檢查 DNS 位址格式、節點初始解析與 TUN 路由。若用戶端也無法正常載入設定,請先復原這次修改,不要繼續疊加規則。
- 復原順序:還原 DNS 備份,關閉新增的 FakeDNS 或 TUN 設定,重新啟動核心,再清除快取。
- 保留排查資訊:記錄故障發生於一般代理或 TUN 模式,以及當時使用的解析器。
- 控制變數:每次只修改 DNS 位址、出站規則或瀏覽器安全 DNS 設定中的一項。
常見問題:如何判讀檢測結果與防洩漏設定
公網 IP 已變,但 DNS 仍顯示本地網路業者,該怎麼查?
先記錄瀏覽器安全 DNS 的狀態,再暫時關閉並重新測試。接著使用透過 SOCKS 傳送網域的命令進行比較,確認要求是否進入代理;若只有 TUN 模式異常,再檢查 DNS 接管與 IPv6 路由。
DNS 檢測顯示多個國家的解析器,就一定是洩漏嗎?
不一定。公共解析器可能使用分散式出口,位址歸屬資料也可能不準確。請比較網路業者資訊與關閉代理時的基準結果,再檢查日誌;不能單靠位址數量判斷。
遠端 DNS 設定了 DoH,為什麼查詢仍走直連?
DoH 指定的是傳輸方式,不會自動決定出站路徑。請檢查解析服務位址是否符合直連規則,並確認目前核心是否採用略過路由的本機解析模式;修正後重新啟動核心再測試。
啟用 FakeDNS 後無法開啟區域網路裝置名稱,該怎麼辦?
為區域網路名稱與內部網域保留適當的本機解析和直連規則。先關閉 FakeDNS,確認問題是否隨之消失,再調整例外規則;不要把所有內部網域都交給公共 DNS。
Android 端也能直接套用這份 v2rayN 設定嗎?
排查方法可以沿用,設定則不能直接照搬。v2rayNG 使用 Xray 核心,v2flyNG 使用 v2fly 核心;請分別確認 DNS、VPN 接管範圍,以及目前版本提供的設定選項。
結論:使用同一組測試完成驗收
修復後恢復日常分流,重新啟動瀏覽器與目標應用程式,再次測試公網出口、DNS 解析與命令列結果。只有預期經由代理的查詢不再走本地解析路徑,而且直連網站與區域網路存取都正常,才算完成這次調整。