WebRTC 泄漏到底泄的是什么
很多人以为挂了代理就安全了，结果打开浏览器随手一搜"IP检测"，发现页面上显示的还是自己家的宽带地址。问题往往就出在 WebRTC 上。
WebRTC 是浏览器里的一项实时通信技术，视频通话、网页会议、在线客服都靠它。它的设计初衷是"让两端尽快建立直连"，所以浏览器会在后台主动去探测本机有哪些可用的网络地址，包括局域网地址、经由路由器的公网地址，甚至 IPv6 地址。这些地址被称为 ICE 候选（candidate）。
关键在于：这套探测走的是 UDP 直连，常常不经过你设置的 HTTP 代理。也就是说，你的网页流量老老实实走了代理，但 WebRTC 的探测包却从真实的网卡直接发出去了。对方页面只要读一下候选列表，就能拿到你的真实出口 IP，甚至能推断出你所在的地区。
更隐蔽的是"本地候选"泄漏。就算公网地址被藏住了，页面依然可能读到类似 192.168.x.x 这样的内网地址。单看一个内网地址说明不了什么，但多个账号、多台设备如果反复出现同一组内网网段和相同的候选特征，就足以被风控系统归到同一个"人"身上。
哪些场景最怕 WebRTC 泄漏
不是所有人都在意这件事，但下面这几类工作，泄漏一次就可能前功尽弃：
1. 多账号运营。同一台电脑管理多个店铺、多个社媒账号，本来靠不同的代理 IP 做隔离。一旦 WebRTC 把真实 IP 吐出来，所有账号瞬间被串成一条线，前面的隔离工作等于白做。
2. 数据采集与抓取。采集端如果同时暴露代理 IP 和真实 IP，目标站点封禁时往往连真实出口一起拉黑，影响后续所有正常业务。
3. 广告投放与效果验证。需要从不同城市视角看落地页展示效果，结果看到的其实是本地出口，数据全是失真的。
4. 网络与开发测试。测试"某个地区用户看到的页面是什么样"，如果链路没真正切过去，测出来的结论就是错的。
各大浏览器关闭 WebRTC 的具体操作
不同浏览器入口不一样，下面这张表可以先收藏。
| 浏览器 | 设置入口 | 关键项 | 是否需要重启 |
|---|---|---|---|
| Chrome | 地址栏输入 chrome://flags | 搜索 WebRTC，把控制本地 IP 暴露的开关改为 Disabled | 是 |
| Edge | 地址栏输入 edge://flags | 同上，搜索 WebRTC 并停用相关开关 | 是 |
| Firefox | 地址栏输入 about:config | 搜索 media.peerconnection.enabled，改为 false | 是 |
| Safari | 设置 → 隐私 | 开启"隐藏 IP 地址"相关选项 | 是 |
| 手机浏览器 | 多数无对应开关 | 建议改用不带 WebRTC 能力的浏览器，或只在桌面端处理敏感操作 | — |
如果是公司统一管理的电脑，让每台机器手动改 flags 太麻烦，可以用浏览器策略统一下发：把 WebRTC 的 IP 处理策略设为"只允许通过代理的 UDP 之外的方式"，或者直接禁止非代理 UDP。这样即使员工换浏览器、重装系统，策略也能覆盖到。
Firefox 的 about:config 页面会弹一个"可能会失去保修"的提示，点接受风险即可。改完之后务必把浏览器完全退出再打开，只关标签页是不够的，很多设置要等进程重启才生效。
还有一个容易忽略的点：扩展插件也能开 WebRTC。某些网页会议插件、远程协助插件会在你不知情时重新拉起连接。排查时可以先用无痕窗口加禁用全部扩展的方式测一遍，确认干净之后再逐个开启，找出那个"捣乱"的插件。
链路验证：改完设置后怎么确认真的没漏
设置改完不代表万事大吉，必须自己验一遍。建议按下面这条链路走：
第一步，记录基准。断开代理，直接访问任意 IP 查询页面，把当前公网 IP 记下来，这是"真实身份"。
第二步，挂上代理再看一次。连上天启HTTP 的代理后再查一次 IP，这个地址应该和基准完全不同，而且归属地要符合你选择的节点城市。如果两次一样，说明代理压根没生效，先别急着怀疑 WebRTC。
第三步，专门查候选地址。打开在线的 WebRTC 泄漏检测页面，看它列出的候选地址里还有没有你的真实公网 IP 或内网网段。正常情况下应该只剩代理出口，或者干脆是空的。
第四步，检查 IPv6。很多人只盯着 IPv4。如果你本地有 IPv6 地址而代理只支持 IPv4，WebRTC 很可能顺着 IPv6 直接跑出去。最省事的做法是敏感操作时在系统里临时关闭 IPv6。
第五步，核对 DNS。DNS 解析如果还走本地运营商，解析结果同样会暴露你在哪个城市。检查一下解析出口是否和代理出口一致。
命令行验证也很直观，改完设置后跑一遍对比：
# 1. 不用代理，记录真实出口 IP
curl https://你的IP查询接口
# 2. 走天启HTTP 代理，出口 IP 应当完全不同
curl -x http://账号:密码@代理IP:端口 https://你的IP查询接口如果想直接看浏览器吐出来的候选地址，可以在控制台跑一小段代码，观察输出的 candidate 里有没有出现你的真实网段：
const pc = new RTCPeerConnection({
iceServers: [{ urls: "stun:你的STUN服务地址" }]
});
pc.onicecandidate = e => {
if (e.candidate) console.log(e.candidate.candidate);
};
pc.createDataChannel("t");
pc.createOffer().then(o => pc.setLocalDescription(o));改完设置后再跑这段，输出的候选里如果只剩代理侧的地址，说明这道口子已经堵上了。
代理链路怎么配合：天启HTTP 的使用建议
关掉 WebRTC 只是第一步，出口本身稳不稳、干不干净同样关键。天启HTTP 提供的是国内 IP 代理服务，覆盖国内多个城市的节点，支持 HTTP、HTTPS、SOCKS5 协议，可以通过 API 提取 IP，也支持账号密码和白名单两种认证方式，适合多账号运营、数据采集、本地化测试这类需要在国内不同城市切换出口的场景。
配合使用时，有几个细节值得注意：
协议要和场景匹配。普通的网页访问和接口请求，用 HTTP/HTTPS 代理就够了；如果工具有自己的网络栈，走 SOCKS5 兼容性更好。需要注意的是，代理通道一般不转发 UDP，而 WebRTC 恰恰依赖 UDP，这也是为什么"关了开关"这件事不能省。
IP 的存活时间要覆盖完整操作。短效 IP 适合快速、分散的请求；如果一个操作流程要持续几分钟，中途 IP 被换掉反而会触发异常，这时用长效 IP 或隧道代理更稳妥，出口在一段时间内保持不变。
别在一个 IP 上堆太重的活。再干净的 IP，短时间打出几百个请求也会被盯上。控制频率、加一点随机间隔，比不停换 IP 更有效。
把验证做成习惯。每次换节点、换工具之后，都重跑一遍上面那条验证链路。泄漏往往不是设置错了，而是环境变了没人复查。
常见问题
Q：关掉 WebRTC 之后，网页视频通话还能用吗？
大部分情况下不能正常建立连接，网页会议、在线客服的语音视频可能受影响。建议的做法不是全局关死，而是"分环境"：日常浏览用普通浏览器，做敏感操作时用单独配置好的浏览器或独立浏览器实例，两边分开。
Q：设置改完、也重启了，检测页上还是有 IP 怎么办？
先确认那个 IP 属于谁。如果它和代理出口一致，说明只是代理节点自己的地址，属于正常；如果它是你家宽带地址，那多半是某个扩展插件重新拉起了连接，或者 IPv6 没处理干净。用无痕窗口加禁用扩展再测一次，基本能定位。
Q：手机上有办法关吗？
主流手机浏览器基本没有这个开关。稳妥的做法是把需要隔离的操作放到电脑端处理，或者只在手机上做不敏感的事情。
Q：只挂代理、不关 WebRTC 行不行？
风险比较高。因为 WebRTC 的探测包很可能不走代理，等于你的真实地址一直挂在外面。关开关的成本很低，没必要省这一步。
Q：天启HTTP 的 IP 能用在国外网站吗？
不能。天启HTTP 是国内的 IP 代理服务，节点都在国内，适用于国内网站访问、多账号运营、本地化测试等场景，不适用于需要境外网络的用途。
Q：多久需要复查一次？
建议每次更换浏览器版本、安装新扩展、切换代理节点之后都复查一次。浏览器更新有时会重置实验性开关，这类变化不会有任何提示。
