甚麼是 WebRTC 洩漏？辨識候選地址與限制瀏覽器暴露

WebRTC 洩漏是瀏覽器即時通信功能意外暴露地址，例如你希望使用 VPN 出口，網站卻看到原始公網 IP。私網地址或 mDNS 名稱不是同一種發現；先分類候選，再判斷是否違反你的政策。

關鍵要點：

• 公網候選要與原始連接及 VPN 出口分開比較。
• 私網地址、mDNS 名稱和中繼地址的意思不同。
• 瀏覽器控制牽涉私隱與通話品質取捨，設定不能跨瀏覽器照搬。
• 限制後測一次真正需要的通話，失敗便還原。

WebRTC 洩漏會暴露甚麼？

WebRTC 支援即時音訊、影片及數據交換。ICE 為尋找可用路徑而收集候選端點，網站取得的地址資訊可能超出普通網頁請求所用地址。實際集合取決於瀏覽器、權限、網絡設定及政策。［1］

候選是一條可能路徑，不證明通話選用了它。即使中繼傳送媒體，診斷仍可能顯示多個候選。「地址已向網頁暴露」與「介面傳送了通話」是不同問題，都可能重要，但證據不同。

圖按候選含義分類，並非截圖或 VPN 實測。先用它標記觀察，再決定某個地址是否構成洩漏。

候選觀察	描述甚麼	解釋
本地私網地址	路由器後方或私網內端點	本地資訊，不自動等於原始公網 IP
mDNS 主機名稱	以名稱遮蔽本地主機候選	本身不是暴露的數字公網地址
公網地址匹配基準	原始連接的可能端點	連接 VPN 後出現時，調查意外公網暴露
公網地址匹配 VPN 出口	使用觀察到的 VPN 出口的可能端點	符合這次觀察，不證明全設備覆蓋
中繼地址	作為候選的中繼端點	不自動等於接入供應商地址

WebRTC 洩漏檢測前要記錄甚麼？

使用可信網絡及獲准設定的設備。記錄瀏覽器名稱與版本、系統、VPN 設定、代理、啟用介面，以及網頁有否麥克風或鏡頭權限。權限可能影響暴露；中途改變權限，就不是受控比較。

選擇會報告候選類別、不索取無關帳戶憑證或上載的診斷工具。不必因網站自稱私隱測試就授予鏡頭權限。若要復現日常通話確實需要某個權限，應有意識地選擇並記錄。

沒有候選可能是網頁被阻斷、工具故障或受限制，不等於所有程式已受保護。整體連接可先用完整 VPN 測試順序，再在此判讀候選。

如何檢測並分類地址？

1. 記錄原始公網出口。 斷開 VPN，查看公網 IP，記錄可用地址族。同一瀏覽器執行 WebRTC 診斷，私下保存候選類別，不公開完整地址或設備識別資料。
2. 建立 VPN 連接參考。 使用 AethoVPN 對照時，在 App 選目前可用位置，連接並驗證網頁出口，再收集候選。這提供兩個公網參考以辨識結果，不代表服務會過濾 WebRTC。Mac、iPhone、iPad 配置需要 Pro 或 Premium。［6］需要這個比較時，可開始 3 天 Pro 試用，每位用戶只限一次。［6］
3. 維持條件重做。 保持瀏覽器、網絡、權限和診斷工具相同，把每個結果分成本地私網、mDNS、公網或中繼。可用時按地址族記錄，再對照原始及 VPN 出口。
4. 調查相關差異。 連接後出現原始公網地址，應檢查路由和瀏覽器政策。只有本地私網地址或 mDNS 名稱，不能證明同一種暴露。不懂分類就記為不確定，查文件，而非一次改掉所有私隱設定。
5. 使用受支援限制。 保存舊值與範圍，一次改一個受支援控制；文件要求時重啟瀏覽器。依下面的瀏覽器差異操作，不能因另一款教程有開關，就認定本機也有。
6. 重測私隱和通信。 重做候選收集，再以真正需要的服務做非敏感通話，查看音訊、影片、建立連接及穩定性。限制破壞必要通信，便還原舊設定，與管理員討論受支援的中繼或網絡政策。

瀏覽器更新或網絡切換後再測。單一瀏覽器設定檔或 Wi-Fi 的結果，不是全設備認證。你要復現已定義的不期望暴露，再顯示特定受支援變更的影響。

Chrome、Firefox、Edge 與 Safari 有何分別？

Chrome 的控制屬於策略及擴充功能介面

Chrome 私隱 API 說明 webRTCIPHandlingPolicy，包括 disable_non_proxied_udp。這是面向擴充功能的控制，不代表每個版本設定頁均有同名選項。企業策略或其他擴充功能可以控制它，所以要求設定的值與生效值可能不同。［2］

不要只為取得開關而安裝陌生「洩漏阻擋器」。核對發佈者、權限、維護及目前文件。限制未代理 UDP 可能改變可用媒體路徑，要測實際通話，不能只信綠色測試標誌。

Firefox 有自己的網絡私隱 API

Mozilla 對擴充功能說明 WebRTC 網絡屬性，包括 IP 處理政策及對等連接控制。這些介面屬於 Firefox，需按已安裝版本查支援行為；不能據此照抄無文件的 about:config 做法，或把每個偏好設定視為穩定用戶選項。［3］

停用對等連接比隱藏地址影響更廣，可能令通話或瀏覽器數據通道失效。選符合需要的限制，保存原值，再試通信服務。

Edge 受管理策略有明確平台範圍

Microsoft 的 WebRtcIPHandlingUrl 讓管理員對匹配 URL 套用 IP 處理策略。官方列出桌面 Edge 135 起支援，Android 與 iOS 未列為支援；它是受管理部署控制，不是通用手機操作。［4］

組織管理的瀏覽器應向管理員確認有效策略與 URL 匹配。不要繞過管理，也不要假設 Chromium 家族原樣繼承 Chrome 每個介面。

Safari 要核對實際版本

WebKit 2017 年工程文章介紹候選暴露及權限差異，適合作歷史背景，不足以證明所有目前 Safari 預設行為。該來源沒有確立目前通用用戶開關，這裏也不虛構一個。［5］

測已安裝 Safari 並記錄權限。出現意外公網地址時，尋找目前平台或管理員指引。拒絕鏡頭權限，不等於所有候選收集都被阻擋，也不證明全設備 VPN 覆蓋。

何時限制 WebRTC，何時保留通話？

按工作需要選擇。某個設定檔完全不需要瀏覽器通話或數據通道時，受支援的嚴格政策可能合適。依賴會議時，全面停用可能比範圍清楚的路由或中繼政策更具破壞性。

VPN 與瀏覽器限制位於不同層次。修改瀏覽器政策，不證明提供方有 WebRTC 功能；網頁 IP 成功，也不證明瀏覽器政策。解析器觀察異常時，用DNS 路徑指南；涉及另一地址族時，用IPv6 檢查。

保存簡短紀錄：基準與連接後公網地址、候選類別、版本、權限、舊值、新值及通話結果。工具沒提供可用候選，要標為無結論，不是成功隱藏地址。找不到獲准的修正時，停止並求助。

把結果寫進試用決策紀錄，判斷剩餘暴露是否符合需要。隧道、瀏覽器及程式保安的關係，可參閱VPN 基礎概覽。

總結

• 先分類候選，再判斷原始公網地址有否暴露。
• 比較時維持瀏覽器、權限與網絡不變。
• 使用實際瀏覽器及平台支援的控制。
• 驗證候選和真實通話，記錄還原方法。

常見問題

私網地址等於公網 IP 洩漏嗎？

不是，它可能披露本地網絡資訊，但這不同於暴露原始互聯網連接的公網地址，應分別理解。

mDNS 名稱會直接暴露原始公網地址嗎？

單憑名稱不會。它用另一種形式代表本地主機候選，判定原始公網暴露前仍要分開比較公網候選。

中繼候選表示 VPN 失敗嗎？

不是，中繼地址表示中繼端點。先分類並比較相關公網參考，不要將每個陌生地址當作失敗。

拒絕鏡頭權限能解決所有 WebRTC 洩漏嗎？

不能，權限會影響行為，但不能證明所有瀏覽器的候選收集或每條網絡路徑均已阻擋。

應全面停用 WebRTC 嗎？

只在受支援控制和功能代價符合需要時考慮。全面限制可能令會議或數據通道失效，必須保留還原方法。

桌面與流動版私隱設定相同嗎？

不同，API 及受管理策略有平台與版本限制。按已安裝瀏覽器文件操作，不要把桌面配方直接套到手機。

為何地址檢查後仍要測通話？

私隱限制可能改變媒體路徑或阻止建連。診斷成功本身，不能說明需要的音訊和影片仍正常。

免責聲明： 只測試獲准設備與網絡。結果描述已記錄的版本、權限和設定，不代表設備上的每個程式。

來源

1. RFC 8828 — WebRTC IP Address Handling Requirements
2. Chrome — browser.privacy API
3. Mozilla — privacy.network
4. Microsoft Edge — WebRtcIPHandlingUrl policy
5. WebKit — A Closer Look Into WebRTC
6. AethoVPN — Official website

Sources checked 2026 年 10 月 5 日。

延伸閱讀

• 記錄是否付款的試用決定
• 分辨 DNS 路由症狀
• 比較兩個地址族的路徑
• 完成整體連接檢查