文章 · 2026-10-01

WebRTC 泄露是什麼？怎麼檢測，各瀏覽器怎麼處理

WebRTC 是瀏覽器裏做影音通話和點對點傳輸的功能。為了找到能連通的路徑，它會向 STUN 伺服器發 UDP 請求，問「你看到我的地址是什麼」。如果這個 UDP 請求沒有經過代理，STUN 伺服器看到的就是你本地寬頻的公網 IP，網頁可以直接讀到它，這就是 WebRTC 泄露。現在的瀏覽器預設會隱藏內網 IP，但不會隱藏 STUN 返回的公網 IP。人在中國大陸時，漏出來的通常是一個大陸 IP，和代理出口對不上。

網頁流量和 WebRTC 的 UDP 走的是兩條路。只有 UDP 也經過代理，STUN 看到的才是代理出口。

WebRTC 為什麼能拿到 IP

WebRTC 用 ICE 協議收集「候選地址」，再逐個測試哪條路走得通。RFC 8445 定義了幾類候選，和泄露有關的是兩類：

host：本機網卡上的地址，包括 VPN 這類虛擬網卡的地址。通常是 192.168.x.x 這樣的內網 IP。
srflx（server reflexive）：本機向 STUN 伺服器發包後，STUN 伺服器看到的地址和端口。RFC 8489 寫明，STUN 可以讓終端知道 NAT 給它分配的 IP 和端口。

候選以文本形式交給網頁，格式見 RFC 8839，行末的 typ host、typ srflx 就是類型。網頁收集這些候選不需要攝像頭或麥克風權限：WebKit 的說明文章寫到，沒有獲得攝像頭、麥克風權限時，Safari 仍會給出 srflx 和 TURN 候選。

mDNS 保護的是內網 IP，不是公網 IP

內網 IP 可以用來追蹤用户，所以瀏覽器改用隨機的 .local 名字代替 host 候選裏的地址，這就是 mDNS 候選。對應的 IETF 草案規定名字由一個隨機 UUID 加 .local 組成；草案已過期、沒有成為 RFC，但做法已被瀏覽器採用：

Chrome：2019 年 Chrome 76 起逐步啓用，公告寫明對所有網站生效，已獲得攝像頭、麥克風權限的網站除外。
Firefox：首選項 media.peerconnection.ice.obfuscate_host_addresses 預設為 true；源碼裏，頁面正在採集或已有攝像頭、麥克風權限時不做隱藏。
Safari：沒有攝像頭、麥克風權限時不給出 host 候選，獲得權限後才給出。

關鍵在於同一份草案的另一句話：無論地址是公網還是內網，srflx 候選照樣生成，而且是真實 IP。mDNS 管不到 STUN 看到的公網地址。

開了代理為什麼還會漏

RFC 8828（WebRTC IP 地址處理要求）列了三種情況：分流隧道的 VPN 會讓 WebRTC 同時發現 VPN 地址和電訊商地址；NAT 後面的內網地址會被看到；使用代理、又允許直接上網時，STUN 檢測會繞過代理，暴露客户端的公網 IP。它還寫到，所有 HTTP 代理和多數 SOCKS 代理都不支援 UDP。

放到常見的代理軟件上：

系統代理模式：軟件把自己設成系統的 HTTP / SOCKS 代理，瀏覽器的網頁請求走代理。WebRTC 的 UDP 按系統路由表發出，直接走本地寬頻，STUN 看到的就是你的真實公網 IP。
TUN 模式（也叫虛擬網卡、增強模式）：軟件創建一塊虛擬網卡（Linux 內核文檔對 TUN 設備的說明是由用户態程式收發數據包），UDP 也會先進入代理軟件。之後走哪條路，取決於線路能不能轉發 UDP，以及分流規則怎麼判：發往國內 STUN 伺服器的請求可能命中直連規則。

任何網頁都能用幾行 JavaScript 讀到 srflx 地址。ChatGPT、Claude、Gemini 是否讀取、怎麼使用，沒有公開說明；但網頁請求來自海外出口，WebRTC 卻顯示一個大陸 IP，本身是一組對不上的信號。

IP 判官怎麼檢測

首頁和 Claude、ChatGPT、Muse 專項檢測頁都會跑這一項，結果在「瀏覽器與連接檢查」的 WebRTC 一行：

同時建立 4 個 WebRTC 連接，每個只配一個 STUN 伺服器：Cloudflare（stun.cloudflare.com:3478）、Google（stun.l.google.com:19302），以及國內的小米（stun.miwifi.com:3478）、嗶哩嗶哩（stun.chat.bilibili.com:3478）。加國內伺服器，是因為分流規則常讓國內的 STUN 走直連，只問一個海外伺服器會漏報。
每個連接建一個數據通道並生成 offer，觸發候選收集，從中取第一個 srflx 地址和第一個 host 地址。收集完成就結束，STUN 沒有回應時最多等 4 秒。
把每個 srflx IP 和本頁查到的出口逐一比較：打開本站的 IP、claude.ai 和 chatgpt.com 看到的 IP、只走 IPv4 和只走 IPv6 的出口。比較的是 IP 本身，不是國家。

判定規則：

海外 STUN（Cloudflare、Google）拿到的 IP 和這些出口都不同：標紅「暴露了另一個 IP」。這說明 UDP 沒有經過代理，常見於系統代理模式。
只有國內 STUN（小米、嗶哩嗶哩）拿到另一個 IP：標黃「國內 STUN 走了直連」。海外 STUN 看到的是代理出口，說明 UDP 已被代理接管，是分流規則把國內的 STUN 域名判成了直連。這個 IP 只有刻意去問國內 STUN 的網站才拿得到，所以按一半扣分。
兩種情況下，頁面都會查出這個 IP 所在的國家和網絡，列進「誰看到了你的哪個 IP」，「怎麼改」裏按情況給出不同的處理辦法。
srflx IP 都在出口之中：「一致」。4 個 STUN 都沒有回應：「未暴露」。瀏覽器沒有 WebRTC 或已禁用：「不會暴露」。
host 地址是 .local 名字時，顯示「已被瀏覽器隱藏（mDNS），正常」；是真實內網 IP 時會顯示出來。這一條只作提示，不算泄露。

加國內 STUN，是因為分流規則常讓它們走直連，只問海外伺服器會漏報。

在 Claude 環境分裏，WebRTC 泄露在 20 分的「泄露」項中扣 12 分，只經國內 STUN 時扣 6 分；Muse 註冊環境分分別扣 10 分和 5 分。這是 IP 判官按常見風控信號定的權重，不是平台公佈的規則，見判定方法。

各瀏覽器怎麼處理

Chrome、Edge

Google 在 Chrome 應用商店發佈了官方擴展 WebRTC Network Limiter（開發者 Google Ireland, Ltd.，截至本文仍可安裝，最近更新於 2023 年 10 月）。裝上後預設不讓 WebRTC 使用內網 IP，以及不承載網頁流量的網卡上的公網 IP。使用系統代理時，還要在擴展的選項頁裏打開禁用未經代理 UDP 的設定，這一項預設關閉。商店頁寫明，多數代理不處理 UDP，打開後相當於關掉 UDP，影音通話可能變慢或質素下降。
受管理的設備可以用企業策略：Chrome 的 WebRtcIPHandling（Chrome 91 起）設為 disable_non_proxied_udp，只在代理支援時使用 UDP；WebRtcIPHandlingUrl（Chrome 133 起）可以按網站分別設定。Edge 對應的是 WebRtcLocalhostIpHandling（Windows、macOS 上的 Edge 77 起），選項 DisableNonProxiedUdp 表示除非代理支援 UDP，否則用 TCP；改完要重啓瀏覽器。
如果檢測頁在 Chrome 裏顯示了真實內網 IP，可能是策略 WebRtcLocalIpsAllowedUrls 放行了這個網站，或者 chrome://flags/#enable-webrtc-hide-local-ips-with-mdns 被關掉了。

Firefox

相關設定在 about:config 裏：地址欄輸入 about:config，確認警告頁後搜索首選項名，雙擊布爾值即可切換（見 Mozilla 的配置編輯器說明）。Mozilla Connect 上有用户在 2025 年提議在設定頁加一個 WebRTC 開關，目前狀態仍是「新想法」。

media.peerconnection.ice.default_address_only：只用預設路由所在的網卡收集候選。media.peerconnection.ice.no_host：候選裏去掉所有本地地址。兩項的說明見 Mozilla Wiki。
再把 media.peerconnection.ice.proxy_only_if_behind_proxy 設為 true。按 Firefox 的源碼，擴展介面裏的 disable_non_proxied_udp 就是同時打開這三項。
media.peerconnection.enabled 設為 false 會整個關掉 RTCPeerConnection（MDN），需要網頁通話的網站會用不了。

Safari

按 WebKit 的說明，Safari 不向普通網頁給出內網地址，但 srflx 仍然給出，所以系統代理模式下一樣會泄露公網 IP。我們沒有找到蘋果為普通用户提供的 WebRTC 開關說明。開發工具裏的「Disable ICE Candidate Restrictions」按 WebKit 的說明會取消 host 候選的過濾，只供開發測試，不要打開。Safari 用户主要靠下一節的網絡設定。