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 的延迟有没有变化，可以在 首页在线测速 跑一轮。
