WebRTC 泄露完全指南:原理、自测方法与各浏览器关闭方式

你挂着代理,网站显示的 IP 也确实是代理 IP,但某些平台还是准确识别了你的真实位置。凶手常常是浏览器里一项叫 WebRTC 的技术。

WebRTC 是什么,为什么会泄露 IP?

WebRTC(Web Real-Time Communication)让网页无需插件就能进行视频通话、语音聊天和 P2P 传输,Google Meet、腾讯会议网页版都靠它。问题出在建立连接的方式:为了让两台设备直连,WebRTC 会通过 STUN 服务器收集本机所有可用的网络地址——包括局域网 IP 和不走代理的真实公网 IP。恶意网页只需几行 JavaScript 就能发起这个探测,拿到代理背后的真实地址,全程无提示。

先自测:你的浏览器泄露了吗?

打开本站首页,查看"浏览器环境"板块中的"WebRTC 泄露"一项:显示"未泄露"说明浏览器已做防护;如果显示出 IP 地址,对比它与页面顶部检测到的 IP 是否一致——不一致(尤其挂代理时)就是实打实的泄露。好消息是,新版 Chrome 和 Firefox 默认用 mDNS 匿名地址(形如 xxx.local)替代局域网 IP,裸奔式泄露已比前几年少见。

三种"泄露"要分清

自测时一看到 IP 就紧张是没必要的。WebRTC 暴露出来的地址分三类,危险程度完全不同:

• 局域网地址或 mDNS 匿名地址:形如 192.168.1.5、10.0.0.3,或一串随机字符加 .local。这不构成泄露。现代浏览器默认用随机 .local 主机名替代真实内网地址,网站拿到它什么也做不了,更无法据此定位你。
• 与出口一致的公网地址:也就是你的代理 IP 本身。说明 WebRTC 流量走的是代理通道,这是理想状态。
• 与出口不一致的公网地址:这才是真正的泄露。网站同时拿到了代理 IP 和你的真实地址,两相对比,代理的意义就归零了。

所以判断标准不是"有没有出现 IP",而是**"出现的公网 IP 是否与页面顶部检测到的出口一致"**。这一点被误解得非常普遍,很多人看到 192.168.x.x 就以为自己在裸奔,其实完全无害。

IPv6 是最容易被漏掉的一条路

不少人堵住了 IPv4 方向,却忘了自己还持有 IPv6 地址。如果代理只接管 IPv4 流量,而系统同时有一个可路由的 v6 地址,WebRTC 完全可能把这个 v6 地址报给对方——它没经过代理,直接指向你的真实网络。

排查方式:在环境检测页确认 IPv4 与 IPv6 两个出口是否都落在代理侧。只要有一个不是,链路就是漏的。IPv6 带来的隐私变化不止这一处,展开可以看 IPv4 与 IPv6 的隐私差异。

各浏览器的处理方法

• Chrome / Edge:没有直接的关闭开关,推荐安装扩展 WebRTC Network Limiter(Google 官方出品),设置为"使用默认公共网络接口"或直接禁用非代理 UDP。
• Firefox:地址栏输入 about:config,搜索 media.peerconnection.enabled,改为 false 即可完全禁用 WebRTC。需要开视频会议时再改回来。
• 指纹浏览器:AdsPower、Multilogin 等工具提供"WebRTC 伪装"选项,可让 WebRTC 报告的地址与代理出口保持一致。相比整体禁用,这种做法保留了功能可用性,也避免了各项信号互相矛盾的情况。

禁用 WebRTC 的代价

一刀切禁用后,所有依赖 WebRTC 的服务都会失效:网页版视频会议、部分网页游戏的语音、P2P 文件传输工具。更隐蔽的影响是:对风控系统来说,"检测不到 WebRTC"本身就是一个信号,和"泄露真实 IP"只是不同方向的异常。所以结论是:

• 普通用户:保持浏览器更新即可,现代浏览器的 mDNS 防护已经够用。
• 代理用户:优先用"WebRTC 替换/限制"方案,而不是完全禁用。
• 多账号运营:用指纹浏览器统一管理,确保 WebRTC 显示的地址与代理 IP 一致。

别只盯着 WebRTC

WebRTC 只是浏览器可能"绕过代理直连"的通道之一。DNS 请求是另一条:代理生效、WebRTC 也正常,但系统仍在用本地运营商的 DNS 解析域名,同样会把你的真实网络暴露给解析方,原理和自查方法见什么是 DNS 泄露。

再往上一层,时区、语言、字体、硬件参数这些信号如果彼此矛盾,单独修好 WebRTC 意义有限。为什么一致性比任何单项设置都重要,可以看网络环境指纹一致性。

处理完之后,回到环境检测页再跑一次,确认"WebRTC 泄露"一项已是绿色,且时区、语言与你的 IP 所在地一致,环境一致性才算完整。

评论