StageVPN 開始使用 ↗
科技

如何檢查 DNS 洩漏和 WebRTC 洩漏：6 步驟診斷和按原因解決方案

DNS 洩漏是指僅 DNS 查詢離開 VPN 隧道的現象，而 WebRTC 洩漏是指 STUN 要求離開代理程式、洩漏真實 IP 的現象。我們總結了僅使用瀏覽器的6步驟診斷、8個原因的解決方案以及StageVPN應用程式和Chrome擴充功能的處理方法。

StageVPN團隊閱讀時間 22 分鐘

3D 插圖描繪了從管狀藍色通道洩漏的一小片光。

如果即使在開啟 VPN 後仍看到以下任何症狀，請懷疑 DNS 洩漏或 WebRTC 洩漏。洩漏是指應透過 VPN 路徑的資訊離開該路徑（也稱為滲漏）。

  • IP驗證頁面顯示VPN伺服器IP，但DNS測試顯示電信公司或路由器的DNS伺服器。
  • IPv4 位址已更改，但 IPv6 位址與關閉 VPN 之前相同。
  • 在WebRTC測試頁面上，公用IP顯示為關閉VPN之前的狀態。
  • 原始IP只有在從Wi-Fi切換到行動數據或從睡眠模式喚醒後立即可見。
  • 我為 Chrome 打開了 StageVPN，但其他瀏覽器和 PC 程式使用原始 IP 連線。
  • 即使開啟了 VPN，網站也會根據原始區域顯示語言和內容（這可能是由於帳戶/cookie 設定所致）。

DNS 洩漏是指在 VPN 開啟時，Web 通訊經過隧道，但只有 DNS 查詢走出隧道，網域名稱對電信公司或 Wi-Fi 的 DNS 伺服器可見的現象。 WebRTC 洩漏是指瀏覽器的 WebRTC 直接從 VPN/代理程式發送 STUN 請求，從而使網頁發現實際的公共 IP 的現象。這兩種現像都意味著頁面內容正在洩漏。然而，它揭示了“誰正在訪問哪裡”。本文從症狀入手，經過診斷、找出原因、複查六個階段。

儘管網路流量受到保護，但只有 DNS 查詢會發出。
儘管網路流量受到保護，但只有 DNS 查詢會發出。

診斷：如何透過 6 個步驟檢查洩漏

洩漏檢查的原理是比較VPN關閉和開啟時的值。比較網站上顯示的 IP、接收 DNS 查詢的伺服器以及 WebRTC 候選位址。如果即使打開VPN後仍可以看到原始值，則表示有洩漏。測試僅在您實際使用的裝置和瀏覽器上才有意義。即使您沒有特定的測試站點，您也可以僅使用瀏覽器檢查大多數內容。 IP驗證頁面是在螢幕上顯示連接者的公用IP位址的網頁。您可以在搜尋引擎中透過「檢查 IP」找到它。用同樣的方法找到DNS洩漏測試頁面和WebRTC測試頁面。無論您使用哪個頁面，原理都是相同的，因此您不必依賴特定網站。

  1. 關閉VPN並記錄您的IP。 開啟 IP 驗證頁面並記下公用 IPv4 位址和 IPv6 位址（如果有）。該值是後續所有比較的基礎。
  2. 打開您的 VPN 並比較 IP。 檢查 StageVPN 應用程式上的連線完成指示燈或 StageVPN for Chrome 圖示上的綠色 ON 指示燈後，再次開啟同一頁面。 IPv4 應替換為您的 VPN 伺服器位址。
  3. 檢查您的 DNS 伺服器。 開啟 DNS 洩漏測試頁面。這些頁面查詢隨機子網域，然後顯示傳送查詢的 DNS 伺服器。如果您可以看到電信業者或路由器的伺服器，則表示有 DNS 洩漏。
  4. 開啟 chrome://webrtc-internals。 在 Chrome 網址列中輸入此位址將顯示正在進行的 WebRTC 連線和候選位址。如果您在另一個標籤中開啟 WebRTC 測試頁面或視訊通話頁面，則會出現該項目。
  5. 檢查候選IP。 如果 srflx（伺服器反射）候選者的位址與步驟 1 中的原始公用 IP 相同，則這是 WebRTC 洩漏。如果是 VPN 伺服器 IP 或僅可見 .local 名稱和私人 IP，則不會公開公用 IP。
  6. 檢查 IPv6。 如果您在步驟 1 中擁有 IPv6 位址，請開啟 VPN 並查看該位址是否已消失或變更。如果是這種情況，則 IPv6 將離開隧道。切換Wi-Fi和行動數據，重新啟動瀏覽器後重複查看結果是否相同。
表 1. 如何讀取診斷結果
觀察結果意義下一個原因
VPN 伺服器 IP 現場可見Web 通訊透過 VPN 路徑正常，下一步
IPv4變了，但IPv6還是原來的位址IPv6離開隧道原因2
DNS伺服器來自電信公司或路由器。DNS 洩漏原因 1、3、4、5
DNS 伺服器是公共 DNS 供應商VPN 設定中的 DNS 或您自己指定的安全 DNS。不要只根據公司名稱就認為是洩漏，檢查原因 4
原始公網IP在WebRTC中可見WebRTC 洩漏原因 6 和 7
WebRTC 僅可見 .local 名稱或私有 IP公網IP不暴露一般正常
僅在網路切換後立即使用原始IP過渡時刻的間隙原因8

結果可能因測試地點而異。有的地方只查看IPv4，有的地方查看IPv6，找DNS伺服器的方法也不同。在多個地方進行比較並切換到多個網路。

DNS 查詢揭露什麼？

DNS 查詢包含網域名稱。不包括頁面內容或輸入的值。 DNS 是網際網路的通訊錄系統，它將人類讀取的網域名稱轉換為電腦使用的 IP 位址。每次您在瀏覽器中輸入位址或應用程式聯絡伺服器時，您的裝置都會先詢問 DNS 伺服器「該名稱的位址是什麼？」因此，只需查看查詢歷史記錄，您就可以了解有關您嘗試存取的時間和服務的大量資訊。

  1. 我的設備應用程式/瀏覽器
  2. 純文字 DNS 查詢
  3. 公共無線網路咖啡廳路由器
  4. 純文字 DNS 查詢
  5. 電信商 DNS現有伺服器
  • 可能暴露的區域
圖 1. 當出現 DNS 洩漏時：Web 通訊會通過隧道，但 DNS 查詢會傳送到目前網路。
  1. 我的設備應用程式/瀏覽器
  2. 隧道中的 DNS
  3. 公共無線網路咖啡廳路由器
  4. 隧道中的 DNS
  5. VPN伺服器StageVPN
  6. 透過VPN伺服器IP查詢
  7. DNS伺服器在 VPN 設定中指定
  • VPN加密
圖 2. 沒有洩漏：DNS 查詢也會進入隧道，且 DNS 伺服器會看到 VPN 伺服器的 IP。

傳統的 DNS 查詢會傳送至未加密的 UDP 連接埠 53。為了彌補這一點，創建了將查詢包裝在 HTTPS 中的 DoH (RFC 8484) 和將查詢包裝在 TLS 中的 DoT (RFC 7858)。但是，即使您使用加密的 DNS，如果網站和瀏覽器不支援 ECH（加密用戶端 Hello），透過 HTTPS 連接到網站時發送的伺服器名稱 (SNI) 也可能在網路上可見。

表 2. 透過 DNS 轉送方法在何處尋找網域名稱。
交貨方式同一 Wi-Fi 下的觀察者Wi-Fi 電信商/通訊公司DNS伺服器接收查詢
純 DNS（明文）可以看到可以看到可見，用我的公網IP
DoH/DoT（加密 DNS）看不到不可見，DNS伺服器位址可見可見，用我的公網IP
VPN 隧道內的 DNS看不到不可見，只看到它正在與VPN伺服器通信可見，有VPN伺服器IP
DNS 洩漏狀態如果是純文本，就可以看到。可以看到可見，用我的公網IP

安全 DNS (DoH) 和 VPN 有不同的目的。 DoH 僅加密 DNS 查詢；網站存取權本身和網站所看到的 IP 保持不變。 VPN 會對您的裝置或瀏覽器與 VPN 伺服器之間的整個通訊進行加密，並變更網站看到的 IP。隱身模式也無法阻止洩密。隱身模式是一種不會在裝置上留下歷史記錄或 cookie、也不會更改 DNS 查詢或 WebRTC 路由的功能。

WebRTC 如何決定 IP 位址？

WebRTC透過多種方式找到自己的位址，透過最短路徑連接兩個設備，並將結果傳遞給網頁上的腳本。 WebRTC 是一種網路標準技術，可讓您無需在瀏覽器中安裝外掛程式即可進行視訊通話、語音通話和檔案傳輸。收集地址的過程稱為 ICE (RFC 8445)。即使不進行視訊通話的頁面也可以使用腳本啟動此程序。

  1. 建立連接對象網頁腳本建立 RTCPeerConnection
  2. 聚集當地候選人您的瀏覽器收集您裝置的網路設備的位址
  3. STUN查詢使用 UDP 詢問 STUN 伺服器“我的地址是什麼樣的”
  4. 候選人交付包含 STUN 伺服器提供的公共位址的候選清單會傳送到該頁面。
圖 3. WebRTC 收集連接候選位址 (ICE) 的順序
表 3. WebRTC 連線候選的類型和可以顯示的訊息
候選人類型某物可能洩漏的訊息保護最新瀏覽器
主持人機器的網路設備位址私有IP（192.168.x等）使用隨機 .local 名稱 (mDNS) 進行屏蔽，但可以在授予攝影機和麥克風權限的網站上看到。
srflx（伺服器反射）STUN 伺服器看到的我的公用位址公網IP，如果繞過代理則為真實IP可以受WebRTC IP處理策略的限制
中繼TURN 中繼伺服器位址中繼伺服器IP如果你使用中繼，對方看到的將是伺服器位址而不是你的IP。

問題出在步驟 3 的 STUN 查詢。瀏覽器代理程式轉發 Web 請求，但在瀏覽器預設設定中，WebRTC 的 UDP 通訊不經過代理。所以STUN伺服器提供的位址並不是代理伺服器，而是我原來的公網IP。設備級 VPN 的情況有所不同。由於所有 UDP 通訊（包括 STUN 請求）都會進入隧道，因此 STUN 伺服器看到的位址也是 VPN 伺服器的 IP。

瀏覽器代理程式和預設策略

  • Web 請求透過代理
  • STUN 請求直接傳送至 UDP
  • 頁面可以看到真實的公網IP

瀏覽器代理程式和disable_non_proxied_udp

  • 阻止 UDP 透過代理
  • WebRTC僅使用代理程式路徑
  • 某些通話具有不同的連接方法或品質

設備範圍內的 VPN

  • STUN 請求也通過隧道。
  • 公用位址候選者是 VPN 伺服器 IP
  • 斷開連線和 IPv6 處理需要確認
圖 4. WebRTC 洩漏可能性取決於連接方法

Chrome 有一個“WebRTC IP 處理策略”，用於確定 WebRTC 將使用哪個位址，並且擴充功能可以變更此值。每個值對應於 IETF 的 WebRTC IP 位址處理建議 (RFC 8828) 中概述的四種方法。

表4. Chrome的WebRTC IP處理策略值（基於chrome.privacy API）
政策價值移動曝光範圍
預設從所有網路設備收集候選者最寬（被 mDNS 屏蔽的本地位址）
預設公用和私有介面僅使用預設路由上的設備，同時使用公用和私人位址不暴露其他設備的位址
僅預設公共介面只使用預設路由的公網位址私有地址不暴露
禁用非代理UDP沒有通過代理的 UDP，如果代理不支援 UDP，則透過代理使用 TCP不要暴露代理外部的路由位址
僅使用瀏覽器而不使用特定網站進行檢查的過程
僅使用瀏覽器而不使用特定網站進行檢查的過程

解決方法：如何根據原因進行檢查和修復

大多數洩漏都有八個原因之一： 這通常是由重疊設定引起的。首先檢查診斷表中指出的原因編號，每修復一個，就重複上圖的步驟6，看看結果是否有改變。如果您一次更改多個設置，您將不知道哪些設置有效。

原因1 · VPN 配置中沒有DNS 伺服器或設備使用不同的DNS。

查看 開啟 VPN 後，DNS 測試會顯示 Wi-Fi 路由器或電信業者的 DNS 伺服器。您裝置的 Wi-Fi 設定中通常有手動 DNS。

解決 StageVPN 應用程式在 VPN 設定中包含一個 DNS 伺服器，並將查詢傳送到隧道中。在裝置的網路設定中將手動 DNS 還原為自動，然後中斷 VPN 連線並重新連線。如果問題仍然存在，請檢查原因 3 和 5。

原因2 IPv6出隧道

查看 IPv4 已變更為 VPN 伺服器位址，但 IPv6 仍與步驟 1 中記錄的值相同。如果 VPN 僅隧道 IPv4，則 IPv6 查詢和通訊將走原始路由。

解決 StageVPN 應用程式也配置為向隧道發送 IPv6 通訊 (AllowedIPs 0.0.0.0/0, ::/0)，因此通常無需將其關閉。如果 IPv6 仍然以其應有的方式顯示，請先檢查其他 VPN 應用程式或裝置設定是否正在變更路由。有些測試站點不支援 IPv6，因此請在多個站點進行比較。

原因3 · 作業系統同時查詢多個網路設備的DNS。

查看 尤其是在 Windows PC 上進行 VPN 連線期間，DNS 測試會顯示 VPN 的 DNS 和電信業者的 DNS。這是由同時詢問所有網路設備的功能引起的，例如 Windows 的智慧多宿主名稱解析。

解決 讓您的作業系統和 VPN 軟體保持最新並重複測試。這種現象主要出現在 PC 上的裝置範圍 VPN 中，由於結構不同，智慧型手機上的 StageVPN 應用程式和 Chrome 上的 StageVPN for Chrome 不會以相同的方式出現。

原因 4 · 在瀏覽器或裝置中單獨指定安全 DNS (DoH)

查看 DNS 測試顯示來自公共 DNS 提供者的伺服器。在這種情況下，可能不是洩漏，而是您自己指定的設定。如果您有裝置範圍的 VPN，則此查詢也將通過隧道，但將由指定的提供者而不是 VPN 設定中的 DNS 接收。

解決 如果這是預期的設置，您可以保持原樣。如果您想使用 DNS 進行 VPN 配置，它將自動變更您的瀏覽器和裝置上的安全 DNS 設定。重要的是，不要僅通過查看公司名稱就認為這是洩漏。

原因5·其他VPN、代理和安全應用程式也打開

查看 其他 VPN 應用程式、代理擴充功能、廣告過濾器或安全程式的網路功能會同時開啟。路由設定會相互覆蓋，導致某些查詢轉到原始路由。

解決 一次僅打開一個。關閉其他應用程式和擴充程序，斷開並重新連接 StageVPN，然後重複步驟 6。 Chrome 的代理設定一次只能控制一個擴充程序，因此如果另一個擴充功能正在使用代理，StageVPN for Chrome 將無法連接，並會告訴您原因。

原因6·僅使用瀏覽器代理，但期望在瀏覽器外部進行通信

查看 我為 Chrome 開啟了 StageVPN，但其他瀏覽器、PC Messenger 和郵件程式使用原始 IP 和原始 DNS 進行連線。這不是洩漏，這是設計範圍。此擴充功能僅涵蓋 Chrome 中的通訊。

解決 如果您需要保護 Chrome 以外的程序，請使用適用於整個裝置的 VPN。在智慧型手機上，StageVPN 應用程式就是這樣做的。兩種方法之間的範圍差異是 瀏覽器 VPN 與應用程式 VPN我把它組織在 .

原因 7 WebRTC 策略未套用

查看 我打開了 Chrome 的 StageVPN，可以在 WebRTC 測試中或 chrome://webrtc-internals 中的 srflx 候選中看到原始公共 IP。如果另一個擴充功能或公司/組織的管理策略首先控制 WebRTC 設置，StageVPN for Chrome 將不會更改策略並保持原樣。

解決 關閉控制 WebRTC 設定的任何其他擴充功能並重新連接 StageVPN for Chrome。如果管理策略是原因，請聯絡您的管理員。若要在無痕視窗中書寫，您必須在擴充功能管理畫面中開啟「允許在隱身模式下」。關閉後，隱身視窗中的通訊不會通過代理。

原因8·VPN連線遺失的那一刻

查看 原來的IP只有在切換網路或從睡眠模式喚醒後立即可見，過一會兒就正常了。在斷開連接期間，所有查詢和通訊都透過正常路由進行。

解決 在進行任何敏感工作之前，請檢查應用程式的連接完成指示燈或擴充功能圖示是否已開啟。 StageVPN 應用程式使用的 WireGuard 即使從 Wi-Fi 更改為 LTE 也不會重新建立隧道，但該協定無法補償網路本身的臨時斷開連接。 VPN 斷開連線時自動阻止通訊的功能不是 StageVPN 提供的功能。原理是 解釋 WireGuard 原理它是在

StageVPN 應用程式和適用於 Chrome 的 StageVPN 如何阻止洩密？

StageVPN 應用程式透過隧道傳輸所有通訊來減少洩漏，而適用於 Chrome 的 StageVPN 則代理名稱會尋找並調整 WebRTC 策略。由於保護範圍不同，處理方式也不同。

表 5. StageVPN 應用程式和 StageVPN for Chrome 的 DNS/WebRTC 處理（截至 2026 年 9 月）
物品StageVPN 應用程式（iPhone·iPad·Android）適用於 Chrome 的 StageVPN
保護範圍所有設備Chrome瀏覽器
透過 VPN 路由發送的通信IPv4·IPv6 全部（允許的 IP 0.0.0.0/0，::/0）Web 請求透過代理程式（不包括私有 IP 頻段和本機）
DNS 查詢在隧道內轉送至 VPN 設定中指定的 DNS 伺服器。透過代理的請求不會由 Chrome 查找，而是由代理伺服器查找。
網路RTC所有 UDP 通訊都通過隧道。在連線期間套用disable_non_proxied_udp，並在斷開連線時返回原始設定。
您目前在網路上看到的內容與 VPN 伺服器的加密通訊和資料量的事實代理伺服器位址的名稱查找、與代理的加密連接以及來自 Chrome 外部應用程式的通信
可能不適用的情況當 VPN 連線遺失時，當另一個 VPN 應用程式重新路由時當另一個擴充或管理策略控制代理程式/WebRTC 設定時，隱身視窗中允許隱身模式關閉
訪問歷史記錄（93天）查看的網域名稱不會被記錄記錄連線的目標主機名，但不記錄路徑或搜尋字詞。

StageVPN 不會引導您完成單獨的 DNS 洩漏保護設定選單作為其產品的功能。上述行為取決於應用程式的預設 VPN 配置和擴充功能的連接方法。提供範圍為 產品特點和範圍您可以在這裡查看。

無洩漏意味著查詢和通訊通過 VPN 路徑而不是運營商。這並不意味著不會保留任何記錄。 StageVPN 根據通訊秘密保護法保留存取記錄 93 天，不記錄通訊內容。該項目是 存取記錄儲存通知好吧，我透露它的原因是 我們為什麼要揭露我們的訪問記錄保留政策？解釋道。

應用程式和擴充功能如何防止洩漏
應用程式和擴充功能如何防止洩漏

重新檢查清單：更改後您會重新檢查哪些內容？

每次修復一個原因時，請從頭開始再次檢查以下項目。如果全部通過，則不存在洩漏。如果任何專案失敗，則返回相應的原因卡。

  • 斷開並重新連接VPN後，我檢查應用程式是否顯示連接完成或擴展圖標是否顯示ON。
  • 在 IP 驗證頁面上，您將看到 IPv4 和 IPv6 的 VPN 伺服器位址，或不會看到 IPv6。
  • DNS測試不會顯示電信公司或路由器的DNS伺服器。
  • chrome://webrtc-internals 中的 srflx 候選者沒有原始公用 IP。
  • 其他 VPN 應用程式、代理程式/VPN 擴充功能和安全程式的網路功能已關閉。
  • 如果您為裝置和瀏覽器設定了手動 DNS 或安全 DNS，則您已驗證這是否是預期的設定。
  • 您的作業系統、瀏覽器以及 StageVPN 應用程式和擴充功能都是最新的。
  • 即使在 Wi-Fi 和行動數據之間切換並重新啟動瀏覽器後，結果也是相同的。
  • 如果您需要保護 Chrome 以外的程序，可以使用裝置範圍的 VPN 而不是擴充功能。

確定何時需要重新檢查也是一個好主意。這是在對作業系統或瀏覽器進行重大更新之後、安裝新的擴充功能或安全應用程式之後、或在您首次連接的網路上執行任何敏感工作之前。如果設定相同但結果發生了變化，通常是這三件事之一造成的。一旦掌握了竅門，只需幾分鐘即可完成 6 個階段的診斷。

如果問題仍然存在，請整理裝置型號、作業系統和應用程式版本、發生時間和測試結果。 客戶支援請聯絡我們。請不要發送您的密碼或驗證碼。與洩漏檢查一起檢查的設備設定包括： 10 項智慧型手機隱私設置嗯，有些風險是僅靠 VPN 無法解決的。 VPN 能阻止什麼、不能阻止什麼那麼，您在公共網路上的習慣是 公共Wi-Fi安全規則我把它組織在 .

參考資料

  1. RFC 1034：網域 — 概念與設施 — DNS 結構與解析器的作用 (IETF)
  2. RFC 8484：透過 HTTPS 的 DNS 查詢 (DoH) — 如何透過 HTTPS 加密 DNS 查詢 (IETF)
  3. RFC 7858：基於 TLS 的 DNS — 如何使用 TLS 加密 DNS 查詢 (IETF)
  4. RFC 8445：互動式連線建立 (ICE) — WebRTC連線候選類型與收集程序（IETF）
  5. RFC 8828：WebRTC IP 位址處理要求 — 瀏覽器向 WebRTC (IETF) 公開的位址範圍
  6. chrome.隱私權 API — Chrome WebRTC IP 處理策略值（Chrome for Developers）
  7. chrome.proxy API — 擴展代理設定、繞過清單和控制優先權（Chrome for Developers）
  8. WebRTC API — RTCPeerConnection 與 ICE 候選者的概念（MDN Web 文件）
  • #DNS洩露
  • #WebRTC 洩漏
  • #DNS洩露
  • #IP洩漏測試
  • #VPN設定

好文章，一起讀