VPN 安⁠全嗎？DNS 與 WebRTC 洩漏檢查及修復方法

VPN 顯示已連線，為什麼仍可能洩漏資訊

VPN 用戶端顯示「已連線」，通常只代表加密通道已經建立，並不等於裝置上的每一種網絡請求都必然經過同一條通道。瀏覽器、作業系統、網絡卡、IPv6 設定，以及應用程式自己的 DNS 或代理設定，都可能影響實際的流量路徑。當部分請求繞過 VPN，網站看到的來源位址、DNS 解析服務或瀏覽器網絡特徵，就可能與預期不同。

常見的檢查項目包括出口 IP 位址、DNS 解析服務與 WebRTC 候選位址。IP 檢查主要確認對外連線所使用的出口；DNS 檢查則確認網域名稱由哪一組解析服務處理；WebRTC 檢查關注瀏覽器在建立即時通訊連線時，是否向網頁提供本地或公開網絡位址。這三者用途不同，不能只做其中一項便宣佈所有設定安全。

還要分清楚「資訊洩漏」與「服務故障」。如果檢查頁顯示的是 VPN 服務所使用的出口位址，這本身不一定是問題；如果 DNS 服務屬於你目前的網絡供應商，或 WebRTC 顯示了不應公開的本地網絡資訊，才需要進一步調整。檢查時應先記錄結果，再逐項修改，避免同時更改太多設定而無法判斷原因。

如何檢查 DNS 洩漏

每次開啟網站時，裝置通常先將網域名稱交給 DNS 解析服務，取得對應的 IP 位址。VPN 啟動後，理想情況是 DNS 請求也按照用戶端的設定經過加密通道，或交由 VPN 所指定的解析服務處理。如果瀏覽器或作業系統繼續使用公共 WiFi、寬頻供應商或其他本地網絡提供的 DNS，網站內容雖然可能透過 VPN 載入，網域查詢來源卻未必一致。

檢查前先關閉其他代理工具，連接一條穩定線路，並暫停瀏覽器中不必要的擴充功能。開啟可靠的 DNS 洩漏測試頁面後，執行標準檢查或完整檢查，查看結果中的服務商名稱、所在區域與伺服器列表。不要只看頁面頂部顯示的 IP；DNS 結果通常位於另一個區域，而且可能同時列出多個解析伺服器。

如果結果同時出現目前本地網絡供應商的 DNS，以及 VPN 連線預期使用的解析服務，便應視為需要調查的訊號。也要注意 IPv6：有些環境的 IPv4 請求已經進入 VPN，但 IPv6 DNS 或 IPv6 流量仍沿用原本的網絡介面。部分瀏覽器還會啟用加密 DNS，例如 DoH 或 DoT；這能改善傳輸保護，卻不代表一定會按照 VPN 用戶端的分流規則處理。

從結果判斷問題位置

• ✅ VPN 連線後重新整理檢查頁，確認結果沒有混入本地供應商的 DNS
• ✅ 同時查看 IPv4 與 IPv6 相關結果，避免只檢查其中一種網絡協議
• ✅ 逐一暫停瀏覽器自訂 DNS、代理擴充功能，再比較測試結果
• ❌ 不要把 DNS 測試頁顯示的每一個伺服器都直接判定為洩漏，先確認其服務商與路由關係

若問題只在開啟瀏覽器的安全 DNS 後出現，先記下原本的伺服器設定，再暫時改回「跟隨系統」或關閉自訂解析功能進行對照。若所有應用程式都出現同樣結果，則應檢查 VPN 用戶端的 DNS 選項、分流模式、IPv6 處理方式與系統網絡介面優先順序。修改 DNS 後，最好斷開並重新連接 VPN，再清除本機 DNS 快取，最後重開測試頁。

WebRTC 洩漏是什麼，應該怎樣檢查

WebRTC 是瀏覽器支援的即時通訊技術，常用於語音、視訊、螢幕分享及點對點連線。為了建立連線，瀏覽器會收集候選網絡位址，再與對方協商可用路徑。這些候選資訊可能包含本地網絡介面、路由器映射後的公開位址，或其他連線能力資料。VPN 可以改變一般網頁請求的出口，但不一定會自動限制 WebRTC 收集與展示候選位址的方式。

在檢查頁面中，先記錄未連接 VPN 時的結果，再連接 VPN 後以同一瀏覽器重新檢查。比較時不要只注意「是否顯示本地 IP」，也要查看候選位址的類型、是否出現原本的公共出口，以及瀏覽器是否以 mDNS 名稱隱藏本地位址。現代瀏覽器可能已經使用 mDNS 處理部分本地位址，因此看不到完整內網 IP 不代表 WebRTC 完全不會暴露其他候選資訊。

WebRTC 檢查最好在沒有進行語音或視訊通話時完成，並分別測試一般視窗與無痕視窗。某些瀏覽器設定、擴充功能及企業管理政策會影響結果。手機瀏覽器與桌面瀏覽器的可調整項目也不完全相同，不能直接把桌面端的設定名稱套用到 iOS 或 Android。

降低 WebRTC 暴露的方式

1. 在 VPN 用戶端中確認是否提供 WebRTC 防護、漏洩防護或阻止本地網絡請求的選項。
2. 在瀏覽器的網站權限或隱私設定中，限制不必要網站使用攝影機與麥克風。
3. 檢查瀏覽器擴充功能是否修改 WebRTC 行為；不明擴充功能應先停用或移除。
4. 重新啟動瀏覽器及 VPN 連線，再用同一檢查頁比較結果。

不建議隨意安裝來源不明的「防洩漏」擴充功能。這類擴充功能可能取得瀏覽資料、修改網絡請求，甚至與 VPN 用戶端的代理規則互相衝突。若使用的是官方 VPN 應用程式，應優先採用其內建的漏洩防護、網絡鎖定或啟動時自動連線功能，再處理瀏覽器層設定。

動手修復：按順序完成一次完整檢查

修復的重點不是把所有隱私功能一次全部打開，而是建立可重複的測試流程。先確認 VPN 用戶端版本及訂閱設定正常，再處理作業系統和瀏覽器。Windows、macOS、iOS、Android 與 Linux 的網絡權限不同；Clash Verge、sing-box、Shadowrocket 等兼容用戶端的分流、TUN、DNS 及規則設定也各有名稱，應以目前用戶端的說明為準，不要照搬另一個軟體的選項。

1. 建立基準：在未連接 VPN 時記錄出口 IP、DNS 服務商及 WebRTC 測試結果。這些資料只作前後比較，不要將真實帳戶、完整訂閱連結或裝置識別資訊上傳到公開頁面。
2. 確認通道：開啟官方用戶端或相容用戶端，匯入有效訂閱，選擇線路後確認系統已授予 VPN、網絡延伸或 TUN 所需權限。
3. 檢查分流：查看目前是否為全局、規則或分流模式。若 DNS、瀏覽器或測試頁被設定為直連，結果可能與全局模式不同。需要本地服務正常運作時，可保留必要的本地規則，但要理解哪些請求不會經過 VPN。
4. 重新測試：連線成功後依次檢查 IP、DNS 及 WebRTC。若只有某一項異常，先針對該層調整，不要立即更換所有協議或重裝系統。

如果使用 WireGuard、OpenVPN、Shadowsocks、VMess、Trojan 或 Hysteria2 等不同協議，表現會受到用戶端核心、路由方式與網絡環境影響。協議名稱本身不是「一定不洩漏」的保證；更重要的是用戶端是否正確接管 DNS、路由及 IPv6，以及系統是否仍存在第二個代理程序。使用多個代理工具時，尤其容易出現端口、DNS 或路由互相覆蓋的情況。

完成設定後，可先關閉 VPN，再重新開啟，觀察是否會自動套用漏洩防護。再切換一次 WiFi、行動數據或其他網絡，檢查連線中斷期間是否短暫回到直連。若用戶端提供網絡鎖定或阻止無 VPN 流量的功能，可按需要啟用；但啟用後，VPN 斷線時部分應用程式可能完全無法上網，這是保護策略生效的表現，不一定是軟體故障。

不同平台的設定重點

桌面系統通常能提供較完整的網絡控制，但也較容易殘留手動代理、虛擬網卡或自訂 DNS。Windows 使用者應檢查系統代理頁面、虛擬網路介面卡及防火牆提示；如果退出用戶端後仍然無法正常上網，可能是代理開關或路由沒有恢復。macOS 則應留意網絡延伸功能、系統代理與睡眠喚醒後的連線狀態。

iOS 會透過系統 VPN 設定管理連線，首次新增設定時需要授權。若使用瀏覽器的自訂 DNS 或內容阻擋功能，應確認它們沒有改寫連線方式。Android 通常需要允許 VPN 在背景運作，省電策略可能在螢幕關閉後停止用戶端；部分裝置也會將「始終開啟 VPN」與「未使用 VPN 時阻止連線」分開管理。

Linux 可使用圖形化用戶端、命令列工具或服務程序。除了查看用戶端狀態，也應檢查路由表、DNS 解析服務、TUN 裝置及環境變數。若瀏覽器採用獨立的 DoH 設定，系統層的 DNS 修復未必會影響它。對於 Clash Verge、sing-box 或其他兼容客戶端，建議先使用簡單的全局模式確認基礎通道，再逐步加入規則分流；這樣較容易分辨是節點問題還是規則問題。

連接公共 WiFi 時，還要注意哪些私隱風險

VPN 能在一定程度上保護裝置到 VPN 入口之間的傳輸，但不能替代所有網絡安全措施。公共 WiFi 可能存在錯誤的 DNS、需要登入的入口頁、裝置間互通設定或不穩定的 IPv6 廣播。連線後若 VPN 沒有自動恢復，瀏覽器可能在短時間內使用直連；因此不應只因為曾經成功連線，便假定更換熱點後仍維持相同保護。

第一次連接新的 WiFi 時，先完成網絡登入，再啟動 VPN 並進行三項檢查。若入口頁無法顯示，可暫時關閉阻止直連的網絡鎖定功能，完成必要的網絡認證後立即重新開啟 VPN。不要在公共網絡中將訂閱連結貼到陌生轉換服務，也不要在共用裝置上保存帳戶密碼。

• ✅ 關閉不需要的檔案共享、附近裝置探索與自動連線
• ✅ 連接新 WiFi 後確認 VPN 狀態，而不是隻查看上一個網絡的連線記錄
• ✅ 在處理帳戶、付款或重要文件前重新檢查出口與 DNS
• ❌ 不要把 VPN 當成防毒軟體、帳戶多重驗證或網站 HTTPS 的替代品

另外，VPN 不會消除瀏覽器指紋、登入帳戶識別、Cookie 或網站本身收集的資料。若目標是降低整體追蹤，還要管理瀏覽器權限、清理不必要的 Cookie、啟用多重驗證，並避免在不可信裝置上輸入敏感資訊。私隱保護應該是分層流程，而不是隻依賴某一個開關。

常見問題

DNS 顯示 VPN 服務的伺服器，就代表完全沒有洩漏嗎？

這通常表示 DNS 請求已交由該服務處理，但仍應確認 IPv4、IPv6、瀏覽器自訂 DNS 及分流規則。測試結果只能反映當下環境，切換網絡、用戶端或瀏覽器後需要重新檢查。

WebRTC 顯示本地位址一定是嚴重洩漏嗎？

本地位址多數只反映內部網絡介面，不等於公開出口位址，但它仍可能暴露網絡結構。應比較 VPN 前後的結果，並按照瀏覽器與 VPN 用戶端提供的 WebRTC 防護選項處理。

只使用官方用戶端，還需要檢查 DNS 和 WebRTC 嗎？

需要。官方用戶端通常能簡化連線與漏洩防護，但瀏覽器自訂 DNS、系統 IPv6、擴充功能、網絡切換及分流規則仍可能改變實際結果。檢查是確認設定，而不是懷疑某一個品牌。

檢查結果異常時，應該立即換線路或重裝用戶端嗎？

不必立即重裝。先截取不含敏感憑證的結果，確認問題是 IP、DNS、WebRTC 還是連線切換造成，再一次修改一個設定。只有在權限、設定檔或用戶端核心明顯損壞時，才考慮重新匯入訂閱或安裝相容版本。