WebRTC 洩漏檢測
正在執行洩漏檢測...
IPv4 (HTTP) 檢測中...
IPv6 (HTTP) 檢測中...
已收集的 ICE 候選
未收集到任何 ICE 候選。
大致位置
正在定位你的網路…

標記顯示的是業者服務範圍的大致中心，而不是你的住所、街道或裝置。相差數十公里是正常現象。

如何阻止 WebRTC 洩漏
Chrome / Edge — 安裝可封鎖 WebRTC 的擴充功能（例如「WebRTC Leak Prevent」），或使用明確阻擋 WebRTC 流量的 VPN 用戶端——現代 Chrome 已不再內建相應開關。
Firefox — 開啟 about:config，搜尋 media.peerconnection.enabled 並設為 false，即可徹底停用 WebRTC。
Safari — WebRTC 無法全域關閉；請在 Safari > 設定 > 網站 中逐站取消攝影機／麥克風權限，或倚賴在網路層級阻擋 WebRTC 的 VPN。
Brave — 開啟 Shields 面板，把 WebRTC 網路限制設為最嚴格的「Proxied」模式，以防止區域網路 IP 洩漏。
關於 WebRTC 洩漏檢測

WebRTC 是為即時視訊通話與點對點檔案傳輸而生的瀏覽器技術。要把兩台電腦直接連起來，它必須找出雙方可能被連上的每一個網路位址，因此會向公開的 STUN 伺服器詢問「從外部看，這條連線是哪個 IP？」，並把答案當作 ICE 候選收集起來。這種候選交換通常在通話雙方之間悄無聲息地進行——但任何網站也能在背景靜默觸發它，讀取候選並從中擷取你的位址。

這對 VPN 使用者來說尤其是個隱私問題。VPN 會把你一般的 HTTP 流量改道經過它的通道，於是網站看到的是 VPN 的 IP 而不是你的。但 WebRTC 透過自己的連線與 STUN 伺服器通訊，在某些設定下這條連線會完全繞過 VPN 通道——即便網址列顯示你「受到保護」，真實的網際網路 IP 依然洩漏出去。現代瀏覽器還會把你的區域網路位址替換成以 .local 結尾、隨機且一次性的 mDNS 主機名稱，而不是 192.168.1.5 這樣的原始 IP；這種替換是實實在在的隱私改善，而不是出問題的跡象。

本工具執行的正是惡意網頁可能執行的同一套 ICE 收集流程，為求可靠使用了兩台彼此獨立的 STUN 伺服器，並把收集到的每一個公用候選與你真實的 HTTP IP 位址逐一比對。若兩者一致，代表 WebRTC 並未在所有網站已經能看到的內容之外額外暴露什麼。若你以為自己開著 VPN 卻出現不一致，那處差異就是洩漏——上方的處理方式說明了如何在你所用的瀏覽器中把它堵上。

本檢測只反映你自己的瀏覽器透過 WebRTC ICE 收集所暴露的內容；它無法發現發生在作業系統或路由器層級的洩漏。

WebRTC 洩漏檢測：你的 VPN 是否洩漏了真實 IP？

本 WebRTC 洩漏檢測工具採用與商業追蹤腳本完全相同的點對點連線機制，即時驗證瀏覽器所暴露的位址中，是否存在本應由 VPN 嚴格隱藏的真實網路資訊。本工具透過建立包含空白資料通道的 RTCPeerConnection（全程無需調用攝影機、麥克風，亦無授權彈窗），向兩個公共 STUN 伺服器發起探測以獲取外部連線視角，並將其與接收你常規 HTTPS 請求的 IP 位址進行嚴格比對。

如何看懂檢測展示的 ICE 候選位址

WebRTC 協定為了尋找兩端裝置能夠建立直連的所有網路通路，會自動收集並生成一份 ICE 候選位址（ICE candidates）清單。本頁面將展示完整的原始清單，標明每項的候選類型與傳輸協定，並在 5 秒探測視窗結束後自動停止監聽。

表格上方清晰列出了透過 HTTP 協定獲取的標準 IPv4 與 IPv6 位址 — 其數值與我的 IP 位址是什麼頁面的結果完全一致。這構成了比對基準，最終結論正是源於兩者的異同。

host、srflx 與 relay — 標籤代表什麼含義

  • 本地（host） — 本機網路卡自身擁有的位址：通常為區域網路 IP（如 192.168.1.14）或隨機混淆的 .local 網域名稱。
  • 公網（透過 STUN） — srflx（Server Reflexive）候選，即 STUN 伺服器觀測到封包抵達的公網入口。這是使用 VPN 時最關鍵的判定點。
  • 中繼（TURN） — 經由第三方中繼伺服器轉發的通訊；因本頁面僅配置 STUN 伺服器，正常情況下極少出現此類候選。

各項檢測結論的具體解讀

  • 檢測到洩漏 — STUN 捕獲的公網候選位址與你的 HTTP IP 不一致；在開啟 VPN 時，這意味著 WebRTC 封包繞過了加密通道。
  • 無洩漏 — 兩側測得的公網 IP 完全一致，隱匿通道運作正常。
  • 本地 IP 暴露 — 清單中直接顯露了明文區域網路私網 IP，未啟用 mDNS 混淆。
  • 受保護 — 本地內部網路位址已被隨機生成的 .local 網域名稱完全匿名化。
  • 無公網 IP / WebRTC 已阻斷 — STUN 伺服器不可達，或瀏覽器已徹底停用 WebRTC 協定。

為什麼 WebRTC 會洩漏本已被 VPN 隱藏的 IP

WebRTC 標準制定的初衷是為了實現瀏覽器與瀏覽器之間低延遲的影音通話及檔案 P2P 直傳。在跨越不同路由器 NAT 裝置時，它必須獲知連線從外部視角來看來自哪個具體公網位址。STUN 伺服器專職解答這一疑問，且任何網頁均可透過 JavaScript 在背景無感發起此類探測。

當你希望隱匿真實網路身分時，這便構成了致命盲區。全系統 VPN 會將主流 HTTP 流量導入虛擬網路卡通道，然而 WebRTC 會向 STUN 獨立發射專屬 UDP 封包；一旦遭遇分流或分流機制不健全，UDP 往往直接直連預設閘道。瀏覽器外掛程式類 VPN 是最為典型的重災區：它們通常僅充當網頁代理，根本無法接管作業系統底層的 UDP 協定堆疊 — 這正是檢測結果可能與純 HTTP 方式的 VPN 檢測結論相互矛盾的根本原因。

隨機的 .local 主機名稱並非洩漏

若 host 候選列中顯示類似 7b3f9c21-4d0a-48e7.local 的字串而非明文 192.168.1.14，這完全屬於正常且安全的現象。這是主流瀏覽器推行的 mDNS 混淆機制：瀏覽器為本地網路卡生成臨時單次多播 DNS 網域名稱予以替代。Chrome、Edge、Brave、Firefox 與 Safari 均已預設集成此防護 — uBlock Origin 亦因此在 v1.38 版本中移除了自建 WebRTC 選項。需要明確的是：mDNS 僅能保護區域網路私網位址，無法阻止公網 VPN 洩漏；且一旦使用者授予了攝影機或麥克風權限，網頁依然可依法讀取真實的區域網路私有 IP。

如何在 Chrome 與 Edge 中修復 WebRTC 洩漏

這兩款 Chromium 瀏覽器均未在常規圖形介面中提供一鍵關閉開關，且 chrome://flags 與 edge://flags 也已刪除了相關實驗性停用選項。目前行業推薦以下三種行之有效的應對方案：

  • 使用系統級全量通道（Full-Tunnel）VPN 用戶端，摒棄單薄的瀏覽器代理外掛程式。只要確保作業系統全部 UDP 流量強制入軌，STUN 無論如何只能觀測到虛擬節點的 IP。
  • 安裝擴充功能強制鎖定 IP 路由策略。例如 WebRTC Leak Prevent 等擴充功能並不直接攔截協定，而是將底層 chrome.privacy.network.webRTCIPHandlingPolicy 參數鎖定為 default_public_interface_only 或 disable_non_proxied_udp，徹底杜絕內網旁路。
  • 透過登錄檔或策略組部署系統策略。Chrome 可配置 WebRtcIPHandling；Edge 則可在登錄檔 SOFTWARE\Policies\Microsoft\Edge 下指定 WebRtcLocalhostIpHandling 為 AllowPublicInterfaceOnly 或 DisableNonProxiedUdp。修改需重啟瀏覽器，可在 edge://policy 驗證。

如何在 Firefox 中徹底停用 WebRTC

Firefox 是主流桌面瀏覽器中唯一保留底層原生硬開關的軟體。在網址列輸入 about:config 並確認風險提示，搜尋設定項目 media.peerconnection.enabled 並按兩下將其修改為 false。修改立即全域生效無需重啟，此時所有網站的 WebRTC 通訊將全面阻斷，本頁面將提示連線被阻止。

注意該操作屬於全域一刀切方案：網頁版視訊會議（如 Google Meet、Teams、Discord 與 Zoom 直連）將無法工作。若需在保留即時影音通話的同時保障安全，建議將上述項保持為 true，轉而將 media.peerconnection.ice.default_address_only 設為 true — 這將限制 Firefox 僅回報預設路由出口（即 VPN 通道出口）。

如何在 Brave 中防範 WebRTC 洩漏

Brave 瀏覽器在使用者介面中直接還原了被 Chrome 隱藏的控制權。打開 brave://settings/privacy，捲動找到 WebRTC IP handling policy（WebRTC IP 處理策略）。在開啟 VPN 或代理時，關鍵設定項目如下：

  • Default（預設） — 列舉所有網路卡，可能暴露出真實的內網私有位址。
  • Default Public and Private Interfaces（預設公網與私網） — 雖僅用預設路由，但仍會呈現對應的內網私有 IP。
  • Default Public Interface Only（僅預設公網介面） — 僅採用預設出口網路卡，隱藏內網位址，影音正常工作。適合作為日常首選推薦。
  • Disable Non-Proxied UDP（停用非代理 UDP） — 強制要求走 TCP 代理；若代理不支援 UDP 則直接阻斷。這是最嚴苛的防護級（Brave Tor 視窗的預設行為），但可能影響 P2P 連通率。

Safari、iPhone 與 Android 裝置的特殊考量

在行動端和蘋果 WebKit 生態中，常規的 PC 端方案往往不再適用。

macOS 上的 Safari

現代 Safari 已取消了持久的全域停用開關。開發選單中的 WebRTC 相關選項僅在當前執行階段內臨時有效。Safari 預設對內網私有位址施加 mDNS 混淆，直到被賦予相機或麥克風權限。因此最有效的手段是在 Safari > 設定 > 網站 中收緊權限，並搭配全域系統級 VPN。

iPhone 與 iPad (iOS/iPadOS)

iOS 平台上的所有第三方瀏覽器（無論是 Chrome 還是 Firefox）底層均被強制使用蘋果 WebKit 核心，無法開啟 about:config，亦無擴充機制；內容阻擋器（Content Blockers）亦無法過濾 WebRTC。唯一的防護方案是在 設定 > VPN 中使用支援全量 UDP 代理的系統級 VPN 協定，並在 Safari 中重新測試。

Android 安卓系統

Android 版本的 Chrome 既無擴充功能也無 WebRTC 旗標；而 Android 版 Brave 則完整保留了前述的 IP 處理策略設定。Firefox 手機版僅在 Nightly 與 Beta 分支開放 about:config。系統層級方案是在安卓系統設定中打開 始終開啟的 VPN 並勾選 封鎖未使用 VPN 的連線。

本檢測工具無法探測的盲區與邊界

本頁面僅能如實反映瀏覽器內部 JavaScript 執行環境所能探知的資訊。它無法察覺作業系統底層引發的非瀏覽器流量外洩（如未被代理攔截的背景系統服務、或者 VPN 忽略的 IPv6 洩漏通路），亦不涵蓋 DNS 洩漏探測。若本地防火牆攔截了 STUN 封包，介面會提示「無公網 IP」，這並不代表絕對安全，僅表明探針未獲回執。此外，IP 位址僅是數位身分的一環：透過 我的瀏覽器是什麼 所揭示的螢幕參數、字型清單與系統特徵，即便處於潔淨的 VPN 環境下同樣能被高級指紋追蹤演算法識別鎖定。

常見問題解答

連上了 VPN 之後，WebRTC 還會洩漏真實 IP 嗎？

完全有可能。WebRTC 會向 STUN 伺服器自主發送專屬的 UDP 封包。在使用分流規則缺陷的用戶端或普通的瀏覽器外掛代理時，這些 UDP 流量會繞過代理直接走本地真實業者閘道。STUN 伺服器便會記錄並回傳真實 IP，網頁只需一段普通 JS 代碼即可無感讀取。系統級全域 VPN 用戶端能徹底解決此漏洞。

有沒有辦法在 Edge 瀏覽器中徹底關閉 WebRTC？

透過普通設定介面無法關閉：Edge 未設置總開關，早期的 about:flags 隱藏設定項目也已被官方移除。在 Windows 環境下，可在登錄檔 SOFTWARE\Policies\Microsoft\Edge 中部署群組原則 WebRtcLocalhostIpHandling 並設為 AllowPublicInterfaceOnly 或 DisableNonProxiedUdp。保存後重啟瀏覽器生效，可在 edge://policy 查看狀態。

在 Firefox 中應該去哪裡停用 WebRTC 和 PeerConnection？

在網址列輸入 about:config：檢索設定項目 media.peerconnection.enabled 並按兩下切換為 false。無需重啟瀏覽器即刻全域停用 WebRTC，但線上影音會議將無法連線。若希望兼顧通話功能，建議保持開啟，並將 media.peerconnection.ice.default_address_only 改為 true 即可。

如何能夠在 Safari 中永久關閉 WebRTC？

當前主流版本的 Safari 無法持久性完全關閉該功能。早年開發者選單下的實驗性開關已被移除，現有的選項在每次瀏覽器重啟後均會重設。鑑於 Safari 已原生對區域網路私有位址執行 mDNS 混淆，最實用的對策是在「Safari > 設定 > 網站」中封鎖權限，並搭配系統級全域 VPN 掩蓋公網痕跡。

在 Brave 瀏覽器中防止 WebRTC 洩漏的最佳設定是什麼？

進入 brave://settings/privacy，將 WebRTC IP handling policy 調整為「Disable Non-Proxied UDP」。此時 WebRTC 將透過代理走 TCP 通訊，STUN 伺服器絕無可能探知你的真實位址。若擔心 P2P 會話無法建立，「Default Public Interface Only」則是保障通話且隱藏內網的實用折衷之選。

我究竟應該選擇哪種 WebRTC IP 處理策略？

絕大多數使用者推薦選擇「Default Public Interface Only」：它完美封堵了內網私網位址，保留了 UDP 協定堆疊，影音呼叫不受任何影響。僅當身處不可靠網路、對匿名性有嚴苛需求且使用代理時，才建議選擇「Disable Non-Proxied UDP」。預設的兩項策略均存在洩漏風險，不建議維持預設。

為什麼我的私有區域網路 IP 位址會被 WebRTC 暴露在公網上？

在最新的主流瀏覽器中，明文暴露已成為歷史。Chrome、Edge、Brave、Firefox 與 Safari 均已將內網 IP 替換為以 .local 結尾的單次隨機 mDNS 主機名稱，網頁僅能讀取到混淆後的代碼。若本檢測工具直接抓取到了明文的 192.168.x.x，說明瀏覽器的安全機制異常或處於失防狀態。