使用 VPN 並不代表瀏覽器的每項連線都會經過同一條加密通道。網頁內容可能透過 VPN 代理傳輸，但 DNS 查詢、IPv6 連線、WebRTC 的 STUN 探測，或用戶端重新連線期間的短暫流量，仍可能採用另一條路徑。這類情況通常被稱為 DNS 洩漏或 WebRTC 洩漏，實際風險取決於洩漏的是哪一項資訊，以及使用的網站、瀏覽器與網路環境。
檢查時不要只看 VPN 用戶端是否顯示「已連線」。較可靠的方法是先記錄未連線時的出口 IP、DNS 服務與瀏覽器行為，再連接 VPN，切換不同線路並重新檢測。本文會分別說明 DNS 與 WebRTC 的工作方式、常見誤判、桌面與行動裝置的設定方向，以及修正後如何再次驗證。
3
主要檢查面向
90+
可選國家覆蓋
200+
可選線路
不限
同時在線裝置
先分清 DNS 與 WebRTC 洩漏是什麼
DNS 是把網域名稱轉換成 IP 位址的系統。當你在瀏覽器輸入一個網址時，裝置需要先詢問 DNS 解析器，才能知道應該連接哪個伺服器。VPN 正常運作時，DNS 查詢通常應由 VPN 用戶端指定的解析器處理，或透過 VPN 通道轉送。如果查詢仍然交給本地寬頻供應商、行動電信商或路由器提供的 DNS，就可能暴露你正在查詢的網域，即使後續網頁內容是透過 VPN 傳送。
DNS 洩漏不一定會顯示你的完整瀏覽內容，也不等同於帳戶密碼直接外洩，但它可能讓網路服務商、公共 Wi-Fi 管理者或其他能觀察 DNS 流量的設備知道你查詢過哪些網域。若瀏覽器啟用了 DNS over HTTPS，查詢內容會被包在 HTTPS 中傳送；然而，若 DoH 指向瀏覽器預設的第三方解析器，而不是 VPN 的 DNS 設定，則仍可能出現「瀏覽器繞過 VPN DNS」的情況。
WebRTC 則是瀏覽器支援即時音訊、視訊與點對點資料傳輸的技術。為了建立連線，瀏覽器可能透過 STUN 伺服器探索可用的網路位址。某些瀏覽器或設定可能讓網站取得本地網路位址、虛擬網卡位址，甚至觀察到未經 VPN 代理處理的連線候選項。現代瀏覽器通常會使用 mDNS 或其他隱私機制降低暴露程度，但不同版本、權限與網站實作仍可能造成結果差異。
因此，DNS 檢查主要看「名稱解析由誰完成」，WebRTC 檢查則看「瀏覽器向網站提供哪些連線候選位址」。兩者都不是單靠更換節點就能永久解決的問題，還需要配合用戶端、作業系統與瀏覽器設定。
DNS 洩漏的正確檢查流程
檢查前先關閉 VPN，記下目前的出口 IP 與 DNS 服務名稱。接著連接 VPN，等待用戶端顯示連線完成，再開啟 DNS 檢測網站。檢測頁面可能列出解析器的 IP、服務商名稱與大致地區。不要只看解析器所在國家是否與 VPN 出口相同；更重要的是確認結果是否仍包含本地網路供應商、公司網路或家庭路由器的 DNS。
完成第一次檢查後，切換另一條線路再測試一次。若每次結果都只出現 VPN 服務所使用的解析器，通常表示基本 DNS 路徑符合預期。若結果時而顯示 VPN DNS、時而顯示本地 DNS，則可能是用戶端重新連線、IPv6 路徑、瀏覽器獨立 DoH，或系統中同時存在多個網路介面所造成。
- ✅ 先在未連線狀態記錄出口 IP 與 DNS，再在 VPN 連線後進行對照。
- ✅ 連線完成後重新整理檢測頁面，避免沿用瀏覽器快取或舊工作階段。
- ✅ 切換 Wi-Fi、行動網路或另一條線路，確認結果不是單一環境的偶然狀態。
- ✅ 同時檢查 IPv4 與 IPv6；只確認 IPv4 並不能代表所有查詢都經過 VPN。
- ❌ 不要把 DNS 服務名稱與 VPN 出口地區完全相同，當成唯一合格標準。
如果仍看到本地 DNS，可以先檢查 VPN 用戶端是否啟用「使用 VPN DNS」、「防止 DNS 洩漏」或相近選項。Windows 可查看網路介面與 DNS 設定，macOS 可在網路設定中核對目前解析器，Linux 則要留意 NetworkManager、systemd-resolved 或其他網路管理服務是否重新覆寫 DNS。修改系統 DNS 時，不應只填入一個公開解析器就宣稱已完成防護，因為 DNS 伺服器位置與流量路徑仍需要再次驗證。
WebRTC 洩漏應該怎麼測試
WebRTC 檢查需要使用能顯示連線候選位址的測試頁面。開啟頁面後，先在未連線 VPN 的狀態記下結果，再連接 VPN 並重新整理。理想情況下，測試頁面不應顯示可辨識的本地真實 IP，也不應出現與預期 VPN 出口不一致的公開位址。不過，測試頁面顯示的候選項可能受到瀏覽器版本、作業系統、mDNS 隱私處理與網站腳本影響，因此不能只看到一組內部位址就直接判定發生嚴重洩漏。
需要特別區分三種位址。第一種是本地區域網路位址，例如家庭路由器分配的內部位址，通常不能直接定位到網際網路出口，但仍可能揭示網路結構。第二種是虛擬網卡或 VPN 介面位址，這類位址本身可能只是通道路由的一部分。第三種是公開可路由位址，若它與 VPN 出口不同，且能被網站在 VPN 連線期間觀察到，就值得進一步檢查。
WebRTC 只有在網頁實際呼叫相關 API、瀏覽器允許建立候選連線，以及網路條件符合時才會呈現特定結果。關閉一個測試頁面的權限，不代表所有網站都會使用同樣方式；同樣地，測試頁面沒有顯示公開本地 IP，也不等於瀏覽器在所有即時通訊場景中都完全不交換網路資訊。
瀏覽器與用戶端的處理方向
桌面瀏覽器可先檢查 WebRTC 隱私選項、網站權限與瀏覽器更新狀態。部分瀏覽器允許限制非代理 UDP、控制 WebRTC 暴露的網路介面，或要求網站先取得相應權限。若使用擴充功能，應確認它是否仍維護、是否需要讀取所有網站資料，以及它的設定是否隻影響瀏覽器頁面而不影響其他應用程式。
VPN 用戶端方面，應優先使用具備斷線防護、DNS 防洩漏與 IPv6 處理能力的官方版本或相容客戶端。若透過 Clash Verge、sing-box 或 Shadowrocket 等客戶端匯入訂閱，需注意系統代理、TUN 模式、規則分流與瀏覽器本身的代理設定並非同一層。只開啟瀏覽器代理，可能只保護瀏覽器流量；只開啟系統代理，也不代表所有 WebRTC UDP 流量一定會依照同一路徑處理。
發現問題後的修正順序
修正時最好一次只改動一項設定，否則很難知道哪個選項真正有效。第一步是更新 VPN 用戶端與瀏覽器，確認時間、憑證與訂閱內容沒有過期或損壞。第二步是在 VPN 用戶端中開啟 DNS 防洩漏、斷線防護與適合目前網路的 IPv6 選項。第三步才處理瀏覽器的 WebRTC 政策與 DoH 設定，避免同時修改系統 DNS、瀏覽器 DNS 和代理規則而造成新的衝突。
- ✅ 先確認只有一個主要 VPN 或代理用戶端接管系統路由。
- ✅ 斷線防護啟用後，觀察 VPN 暫時中斷時瀏覽器是否停止外連。
- ✅ 若不使用 IPv6，可在作業系統或用戶端中採取一致的 IPv6 政策，再重新測試。
- ✅ 使用分流時，把 DNS、瀏覽器與即時通訊流量的規則分開核對。
- ❌ 不要同時啟用兩個 VPN、兩個 TUN 服務或多個會改寫系統 DNS 的工具。
- ❌ 不要只清除瀏覽器快取就把結果當成路由問題已經解決。
如果問題出現在手機，還要檢查系統的私人 DNS、VPN 設定檔、應用程式分流與省電限制。Android 的私人 DNS 可能由系統單獨處理名稱解析；iOS 的 iCloud Private Relay、應用程式 VPN 或其他網路隱私功能，也可能改變瀏覽器看到的出口。不同功能不一定能同時疊加，遇到結果不一致時，應先暫停非必要的網路過濾與加密服務，再逐一恢復。
| 現象 | 可能原因 | 優先檢查項目 |
|---|---|---|
| DNS 結果出現本地電信商 | 系統 DNS 未被接管、IPv6 繞過通道或瀏覽器使用獨立 DoH | VPN DNS 選項、IPv6、瀏覽器安全 DNS |
| 切換線路後結果沒有改變 | 快取尚未更新，或 DNS 由另一個常駐服務處理 | 重新連線、重新整理、檢查常駐網路工具 |
| WebRTC 顯示內部位址 | 瀏覽器展示本地介面資訊，未必等於公開出口洩漏 | 位址類型、公開可路由性與瀏覽器版本 |
| WebRTC 顯示未預期公開位址 | 代理未處理相關 UDP、瀏覽器政策過寬或分流規則遺漏 | WebRTC 設定、TUN 模式、分流與斷線防護 |
| VPN 斷線後仍可開啟網頁 | 斷線防護未啟用，或瀏覽器使用了未受 VPN 管理的路徑 | Kill switch、系統代理與其他網路介面 |
修正後如何完成二次驗證
完成設定後，不要只在同一個瀏覽器分頁中按重新整理。先完全關閉瀏覽器，再重新連接 VPN，等待用戶端完成路由設定，然後分別進行 DNS、IP 與 WebRTC 檢查。測試過程中應至少切換一次線路，也可在 Wi-Fi 與行動網路之間更換環境，觀察結果是否一致。
接著模擬幾個常見情境：手動中斷 VPN、等待用戶端自動重連、讓裝置從休眠狀態恢復、切換網路，以及重新開啟瀏覽器。這些時刻容易發生路由暫時回復系統預設、DNS 服務尚未完成切換，或舊的瀏覽器連線繼續存在。若測試只在穩定連線後進行，可能忽略真正發生問題的短暫窗口。
驗證結果應記錄檢查日期、作業系統、瀏覽器、VPN 用戶端、使用的線路類型與發現的位址類別。不要把某次測試結果寫成永久保證，因為瀏覽器更新、作業系統網路政策、VPN 訂閱配置與電信路由都可能改變行為。對經常使用代理規則的使用者，也應分別檢查全域模式、規則模式與直連模式，避免把某一種模式的結果套用到其他模式。