WebRTC 泄漏:浏览器如何绕过 VPN 暴露你的真实 IP
WebRTC 是浏览器内置的实时通信技术,网页版视频会议、语音通话都靠它。问题在于:为了建立点对点连接,它会主动收集你设备的所有网络地址——包括 VPN 背后的真实 IP,而且网页脚本无需任何授权就能读取。
泄漏原理一分钟版
WebRTC 建立连接时使用 ICE 框架枚举所有可用网络路径:本地内网 IP、公网 IP、VPN 虚拟网卡 IP 全部在列。恶意网页只需几行 JavaScript 就能触发这个枚举并把结果发回服务器——你的 VPN 形同虚设。
自测与防护
- 检测:连接 VPN 后访问 browserleaks.com/webrtc,如果显示了你的运营商公网 IP,就存在泄漏;
- Chrome/Edge:安装 WebRTC Leak Prevent 类扩展,或在企业策略中限制;
- Firefox:地址栏输入 about:config,将 media.peerconnection.enabled 设为 false(代价是网页视频通话不可用);
- 正规 VPN 客户端的全局模式会接管所有网卡流量,能显著降低泄漏面,但浏览器层面的检测仍建议做一次。
延伸阅读
WebRTC 只是浏览器暴露身份的渠道之一,配合 DNS 泄漏检测和浏览器指纹一起了解,才能对“网站知道你是谁”这件事有完整认知。顺带一提:无痕模式对这些泄漏毫无帮助,原因见无痕模式误区。
两类地址,两种不同的暴露
WebRTC 枚举出来的地址其实分两类,危害并不相同。第一类是公网出口地址,也就是运营商分给你的真实 IP,一旦被网页读到,你的大致地理位置和运营商信息就暴露了,这是最需要堵住的口子。第二类是局域网内网地址,单独看危害不大,但配合浏览器指纹可以提高追踪精度,还可能暴露你所在的内网结构。
好消息是,近几年主流浏览器引入了 mDNS 混淆机制:对外呈现的内网候选地址被替换成一串随机的 .local 名称,真实内网地址不再直接暴露。坏消息是,公网地址的泄漏在特定配置下依然可能发生,所以自查这一步省不掉。
五分钟自查的分步操作清单
- 第一步:断开 VPN,访问检测页记下自己的真实公网 IP,这是后面判断泄漏的对照基准;
- 第二步:连接 VPN 后重新打开检测页,逐项查看 WebRTC 一栏列出的所有地址;
- 第三步:对比两次结果,只要第二次仍出现第一步记下的真实 IP,就说明存在泄漏,需要按浏览器分别处理;
- 第四步:换上你日常使用的每一个浏览器重复检测,不同浏览器的默认策略差异很大,一个安全不代表个个安全;
- 第五步:按下文的对照表完成设置或安装扩展后,再做一轮复测,确认真实 IP 不再出现;
- 第六步:把检测页加入书签,浏览器大版本更新或重装扩展后复查一次,设置有时会被更新重置。
主流浏览器的防护手段对照
不同浏览器关闭或限制 WebRTC 的路径完全不同,下表按桌面端整理,移动端浏览器可设置的项普遍更少,更依赖 VPN 客户端的全局接管。
| 浏览器 | 设置方式 | 副作用 | 适用建议 |
|---|---|---|---|
| Firefox | 在 about:config 中关闭 media.peerconnection.enabled | 网页端视频会议不可用 | 适合把 Firefox 当纯浏览工具的用户 |
| Chrome 与 Edge | 本体无开关,需安装防泄漏扩展限制候选地址 | 扩展默认不在无痕窗口生效,需手动允许 | 适合主力浏览器,兼顾会议与防护 |
| Safari | 默认策略较保守,泄漏面小,但没有彻底关闭的开关 | 可控项少 | 配合系统级全局接管使用即可 |
| 移动端浏览器 | 几乎没有可设置项 | 依赖系统层防护 | 以客户端全局模式为主,浏览器为辅 |
检测结果异常速查表
| 现象 | 原因 | 解决方法 |
|---|---|---|
| 检测页显示运营商公网 IP | 浏览器 WebRTC 直接暴露了真实出口 | 安装防泄漏扩展或关闭相关开关后复测 |
| 显示一串 .local 结尾的地址 | 浏览器启用了 mDNS 混淆,内网地址已被隐藏 | 属于正常防护表现,无需处理 |
| 装了扩展仍显示真实 IP | 扩展未覆盖无痕窗口,或与其他扩展冲突 | 在扩展详情里允许无痕模式运行,再逐个停用其他扩展排查 |
| 关闭 WebRTC 后网页会议打不开 | 会议产品依赖 WebRTC 建立媒体连接 | 改用会议软件的桌面客户端,或单独留一个浏览器专门开会 |
| 每次检测结果都不一样 | 多网卡环境或分流规则不一致 | 临时切到全局模式复测,先排除分流规则的干扰 |
桌面与手机的泄漏面差异
桌面端的泄漏面主要在浏览器,因为扩展生态和可配置项都集中在这里,按上表处理基本可控。手机端情况相反:浏览器可设置的项很少,但系统级 VPN 接管的彻底程度通常更高,App 内嵌网页的流量也会一并走隧道,所以移动端的实际泄漏风险反而低一些。
真正要留意的是「混合场景」:笔记本连手机热点、公司电脑装了远程办公软件、或者浏览器里同时开着多个代理扩展,这些组合会让流量路径变得难以预期。判断标准只有一个:以检测页的实测结果为准,而不是以「我装了什么」为准。理解了这一点,再回头看VPN 保护隐私的边界,会更清楚哪些暴露是工具能挡的、哪些要靠习惯。
高频问答
- 问:客户端开了全局模式,还需要管 WebRTC 吗?答:全局接管能显著收窄泄漏面,但浏览器扩展冲突、更新重置等因素依然存在,花五分钟按清单实测一次最稳妥。
- 问:关闭 WebRTC 会影响哪些日常功能?答:主要是网页版视频会议、网页语音通话和部分点对点传文件工具;桌面客户端形态的会议软件不受影响。
- 问:无痕窗口能避免这类泄漏吗?答:不能,无痕只是不留本地历史,WebRTC 的地址枚举照常工作,防泄漏扩展还需要手动授权才能在无痕窗口生效。
- 问:手机 App 里也有 WebRTC 泄漏吗?答:App 内嵌浏览器同样带 WebRTC 能力,但系统级隧道接管后风险可控,重点还是确认客户端处于全局接管状态。
- 问:检测页显示了内网地址要紧吗?答:单独暴露内网地址危害有限,主要用于提升指纹追踪精度;若显示的是 .local 混淆名,则说明浏览器已经在保护你。
按使用强度选择防护深度
普通用户做到两件事就够了:主力浏览器装一个防泄漏扩展,每季度按清单复测一次。把成本控制在几分钟,防住绝大多数被动暴露,遇到连不上或速度异常时按连接故障排查指南处理即可。
远程办公和自由职业者建议再进一步:把「开会的浏览器」和「日常浏览的浏览器」分开,前者保留 WebRTC 保证会议可用,后者彻底关闭;客户资料、后台管理只在关闭 WebRTC 的浏览器里操作。对隐私要求更高的用户,可以在此基础上启用浏览器的严格反追踪模式,并在公共网络环境下坚持先开加密通道再上网的顺序——泄漏防护从来不是单点开关,而是几层习惯叠出来的结果。
