WebRTC 洩漏怎麼關：Chrome、Firefox、Safari 設定
要關掉 WebRTC 洩漏：Firefox 在 about:config 裡調整 media.peerconnection 相關項；Chrome 裝 Google 官方的 WebRTC Network Limiter 擴充套件，或者用企業策略 WebRtcIPHandling 限制；Safari 預設已經比較收緊，一般不用改。改完開啟 cdnping 的 IP 與環境檢測，看 WebRTC 一欄裡還能不能看到你不想暴露的地址。
WebRTC 為什麼會洩漏 IP
WebRTC 是瀏覽器裡做實時音影片和點對點傳輸的介面。兩端要直連，瀏覽器得先收集自己可用的網路地址，這些地址叫 ICE 候選（candidate），主要有三類：
- host：本機網絡卡地址，例如
192.168.1.23這樣的內網地址，或者一個公網 IPv6 地址； - srflx：瀏覽器向 STUN 伺服器發一個 UDP 包，對方看到的源地址，也就是你在公網上的出口地址；
- relay：經 TURN 中繼伺服器轉發時分配到的地址。
網頁裡的指令碼只要建立一個 RTCPeerConnection，就能讀到這些候選，不需要使用者點任何授權。問題出在這裡：很多人用的是 HTTP 或 SOCKS 形式的瀏覽器代理，網頁流量走代理，但 WebRTC 發往 STUN 的 UDP 包不一定走代理，於是 srflx 候選裡出現的是本地運營商分配的真實出口 IP，和網頁看到的代理 IP 對不上。這就是通常說的 WebRTC leak。全域性 VPN 或系統級透明代理一般不會出這個問題，因為 UDP 也被接管了，但 host 候選裡的內網地址和 IPv6 地址仍可能暴露。
更完整的背景可以看站內的 DNS 洩漏與 WebRTC 洩漏；如果你用的是分流規則，也建議讀一下 分流（split tunneling），WebRTC 的 UDP 流量可能不在分流規則覆蓋範圍內。
怎麼確認自己有沒有 WebRTC 洩漏
改設定之前先留一個基線，改完才有對比。
- 關掉無關的瀏覽器擴充套件，開啟 /ip。
- 記下頁面頂部的出口 IP（網頁請求看到的地址）。
- 找到“WebRTC 洩漏”一項，看列出的候選地址：
- 只出現
xxxx.local形式的主機名，或者只出現與出口 IP 相同的地址：沒有洩漏； - 出現一個與出口 IP 不同的公網 IPv4 或 IPv6：有洩漏，這個地址通常就是你的本地真實出口；
- 出現
192.168.*、10.*、172.16–31.*等內網地址：暴露的是區域網資訊，風險較低，但可以一併收緊。
- 只出現
- 同一頁面的“DNS 洩漏”“大陸分流檢測”可以順便看，它們和 WebRTC 往往是同一個配置問題的不同表現。
/ip 可以生成帶水印的結果圖，生成前可以把 IP 隱藏掉，貼到工單或群裡時不用再手動打碼。頁面上的瀏覽器指紋在本地計算，不上傳。
Firefox 怎麼關：about:config 設定
Firefox 是三者裡可調項最多的。位址列輸入 about:config，接受風險提示，然後搜尋 media.peerconnection。
| 配置項 | 建議值 | 作用 |
|---|---|---|
media.peerconnection.enabled | false | 整體關閉 WebRTC，最徹底，網頁音視訊通話全部不可用 |
media.peerconnection.ice.default_address_only | true | 只使用預設路由對應的那個地址，不再列舉所有網絡卡 |
media.peerconnection.ice.no_host | true | 不暴露 host 候選（本機網絡卡地址） |
media.peerconnection.ice.proxy_only_if_behind_proxy | true | 配了代理時，WebRTC 只走代理，不直接發 UDP |
media.peerconnection.ice.relay_only | true | 只用 TURN 中繼，不做直連（需要網頁本身提供 TURN） |
兩種常見做法：
- 不需要網頁通話：只把
media.peerconnection.enabled設為false，其餘不用動。 - 還要用網頁會議：保留
enabled = true，把default_address_only、no_host、proxy_only_if_behind_proxy三項設為true。這樣大多數會議仍能連上，同時不會繞過代理發 UDP。
如果要在多臺機器上統一配置，可以寫進配置檔案目錄下的 user.js，Firefox 每次啟動都會讀取：
// user.js，放在 Firefox 配置檔案目錄（about:profiles 可以看到路徑）
user_pref("media.peerconnection.ice.default_address_only", true);
user_pref("media.peerconnection.ice.no_host", true);
user_pref("media.peerconnection.ice.proxy_only_if_behind_proxy", true);
// 完全不用 WebRTC 時再開啟下面這一行
// user_pref("media.peerconnection.enabled", false);
改完需要重啟瀏覽器，再回到 /ip 複測。
Chrome 怎麼限制：官方擴充套件或企業策略
Chrome 沒有提供關閉 WebRTC 的設定開關。從較早的版本開始，Chrome 預設會把 host 候選裡的內網地址替換成隨機的 .local 主機名（mDNS），所以內網 IP 通常已經看不到；需要處理的主要是 srflx 裡的公網地址。有兩條路。
方法一：WebRTC Network Limiter 擴充套件
這是 Google 在 Chrome 應用商店釋出的官方擴充套件，適合個人電腦。
- 在 Chrome 應用商店搜尋 “WebRTC Network Limiter”，確認釋出者是 Google，安裝；
- 開啟擴充套件的“選項”頁；
- 按需求選擇路由方式。要防止繞過代理，選擇“使用我的代理伺服器（如有）”這一類選項，對應的就是隻走代理、禁用非代理 UDP；
- 重啟瀏覽器，到 /ip 複測。
擴充套件的選項文字會隨版本調整，選擇時以“是否允許不經代理的 UDP”作為判斷依據。
方法二：企業策略 WebRtcIPHandling
團隊統一管理、或者不想依賴擴充套件時，用 Chrome 的企業策略更穩定。策略名是 WebRtcIPHandling，可選值如下：
| 值 | 含義 | 適用場景 |
|---|---|---|
default | 預設行為，可使用所有網絡卡 | 不做限制 |
default_public_and_private_interfaces | 只用預設路由的公網和內網介面 | 多網絡卡機器，減少列舉 |
default_public_interface_only | 只用預設路由的公網介面，不暴露內網地址 | 只關心內網地址 |
disable_non_proxied_udp | 禁止不經代理的 UDP，WebRTC 只能走代理（代理不支援 UDP 時改走 TCP，或無法建立連線） | 使用瀏覽器代理時防止公網 IP 洩漏 |
各平臺的寫法：
# Linux（Chrome），需要 root
sudo mkdir -p /etc/opt/chrome/policies/managed
echo '{ "WebRtcIPHandling": "disable_non_proxied_udp" }' | \
sudo tee /etc/opt/chrome/policies/managed/webrtc.json
# Chromium 的路徑是 /etc/chromium/policies/managed/
# Windows，管理員 PowerShell
New-Item -Path "HKLM:\SOFTWARE\Policies\Google\Chrome" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Google\Chrome" `
-Name "WebRtcIPHandling" -Value "disable_non_proxied_udp" -Type String
macOS 上正式做法是透過配置描述檔案（MDM）下發 com.google.Chrome 域的 WebRtcIPHandling。個人機器可以先用 defaults write com.google.Chrome WebRtcIPHandling -string disable_non_proxied_udp 試，但這種方式不一定被識別為強制策略，以複測結果為準。
寫入後在位址列開啟 chrome://policy，點“重新載入政策”，確認 WebRtcIPHandling 出現且狀態正常。如果還要限制 WebRTC 使用的本地 UDP 埠範圍，可以另外配置 WebRtcUdpPortRange，這和洩漏無直接關係，按網路管理需要決定。
Edge、Brave 等基於 Chromium 的瀏覽器也有對應策略或設定項，名稱和路徑以各自的官方文件為準。
Safari 需要改設定嗎
Safari 的預設策略比較保守：在網頁沒有獲得攝像頭或麥克風授權之前，不會把本機網絡卡地址作為 host 候選暴露給指令碼。因此在 Safari 裡，內網地址洩漏一般不成立。
有兩點要留意：
- 一旦你在某個網站授權了攝像頭或麥克風，該網站就可能拿到更多候選地址。可以在“Safari 設定 → 網站 → 攝像頭 / 麥克風”裡檢查哪些站點被設為“允許”，不需要的改成“詢問”或“拒絕”。
- Safari 沒有面向普通使用者的“關閉 WebRTC”開關。開發選單（設定 → 高階 → 顯示網頁開發者功能）裡有 WebRTC 相關的除錯選項，其中放寬 ICE 候選限制的選項會讓暴露更多，日常使用保持預設，不要勾選。
如果你在 Safari 上用的是瀏覽器級代理而不是系統 VPN，srflx 候選仍可能顯示本地出口，這時更可靠的做法是改為系統級的代理或 VPN，讓 UDP 一併被接管，然後到 /ip 複測。
關閉 WebRTC 後網頁會議還能用嗎
限制 WebRTC 的代價落在網頁版音影片應用上，例如瀏覽器裡開啟的視訊會議、網頁客服通話、線上白板的實時協作。桌面客戶端不受瀏覽器設定影響。
| 設定 | 網頁會議能否使用 | 可能的現象 |
|---|---|---|
Firefox media.peerconnection.enabled = false | 不能 | 頁面提示瀏覽器不支援，或一直卡在“正在連線” |
Firefox no_host / default_address_only | 通常可以 | 同一區域網內的兩人通話可能改走公網，延遲略升 |
Firefox relay_only / Chrome disable_non_proxied_udp | 視服務而定 | 走 TURN 中繼或代理，延遲和丟包增加；代理不轉發 UDP 且服務不支援 TCP 回退時會連不上 |
Chrome default_public_interface_only | 通常可以 | 基本無感 |
| Safari 預設 | 可以 | 授權攝像頭後正常使用 |
如果你只是偶爾開網頁會議，比較省事的方法是：日常用的瀏覽器配置收緊，另外準備一個不改設定的瀏覽器配置檔案（Chrome 的使用者資料、Firefox 的 about:profiles）專門開會。
改完以後怎麼確認已經修好
按順序過一遍：
- 瀏覽器已重啟，Chrome 的
chrome://policy裡能看到策略生效； - /ip 的 WebRTC 一欄裡沒有與出口 IP 不同的公網地址；
- IPv6 也檢查過：同一頁面的 IPv4/IPv6 檢測裡，如果本地有 IPv6 而代理不支援，WebRTC 可能單獨暴露 IPv6；
- DNS 洩漏一欄沒有出現本地運營商的解析伺服器；
- 常用的網頁會議試打一次，確認能接通；
- 需要留檔時，在 /ip 生成結果圖，並開啟“隱藏 IP”再分享。
背景說明：AGI Plan 是 cdnping 的商業合作方。/ip 是給開發者自查網路出口用的，不需要登入。
以上設定的目的是保護個人網路資訊。各類線上服務對訪問地區和使用方式有各自的條款，請遵守服務條款和當地法規，本文不涉及如何繞過平臺的地區限制或風控。
下一步
- 開啟 /ip 做一次完整檢測，把 WebRTC、DNS、大陸分流三項的結果對照著看；
- 如果 WebRTC 正常但 DNS 有問題，繼續讀 DNS 洩漏與 WebRTC 洩漏 的 DNS 部分；
- 想確認出口 IP 本身的型別（機房、家寬、移動）和歸屬，參考 原生 IP 與廣播 IP；
- 網路改動後想看看訪問各家 AI API 的延遲有沒有變化，可以在 首頁線上測速 跑一輪。
