如何进行 WebRTC 泄漏测试
按浏览器逐步进行 WebRTC 泄漏测试:候选地址列表的含义、在 Chrome 和 Firefox 中如何读取,以及出现公网地址时该调整什么。
阅读约 10 分钟更新于 2026年10月15日作者:XPASS Editorial Team

每隔几年,就会有某个浏览器功能对隐私的影响远超所有人的预期,WebRTC 就是其中之一。它让网页可以直接在浏览器里完成视频通话、屏幕共享或语音聊天,无需安装任何东西。为了做到这一点,浏览器必须弄清楚有哪些网络地址能够连到你的电脑,并且可以把发现的结果告诉网页。如果这份列表里包含网络运营商分配给你的公网地址,那么即使 VPN 隐藏了你的普通浏览流量,在这一项功能上看起来也像是被绕开了。
本文讲的是如何测试 WebRTC 泄漏:在 Chrome 和 Firefox 中怎样读取结果,怎样区分无害的私有地址与真正的暴露,以及出现问题时该调整什么。概念本身请看什么是 WebRTC 泄漏,这里重点放在测试。
WebRTC 泄漏测试到底在找什么
WebRTC 通过一个叫 ICE 的过程连接两端。简单说,浏览器会收集一份**候选地址(candidate)**列表,每一项都是一条可能连到它的途径。网页用几行脚本就能读到这份列表。
你可能看到四类候选地址:
- 主机候选(host)。 你设备或本地网络上的地址,比如私有地址 192.168.1.20。按互联网地址分配规则,它们属于私有段,离开你的家或办公室就几乎没有意义。
- 服务器反射候选(server-reflexive)。 浏览器联系辅助服务器(称为 STUN 服务器)时,对方看到的公网地址。这一项最关键。如果开着 VPN 时它是你运营商的地址,那就是泄漏。
- 中继候选(relay)。 直连失败时使用的中继服务器地址,只在部分配置下出现。
- mDNS 名称。 现代浏览器常用一个以 .local 结尾的随机名称取代你真实的本地地址,目的就是不暴露内网结构。
泄漏测试页面只是把这些候选地址收集起来再打印出来。测试并不能证明某个网站在窥探,而是展示任何网站都能读到什么。这一切背后的标准见 W3C WebRTC 规范,MDN 的 WebRTC API 指南则用开发者易读的方式讲了同样的概念。

准备干净的测试:先记基准,再管扩展
只有能与某个参照对比,结果才有用。请在连接 VPN 之前完成下面的步骤。
- 关闭 VPN,等待十秒。
- 在想要检查的浏览器里,用普通窗口打开 WebRTC 测试页面。
- 抄下所有候选地址:公网地址、私有地址和 .local 名称。这就是你的基准,这里的公网地址应当是你运营商的。
- 查看有哪些扩展正在运行。 广告拦截器、隐私扩展和某些 VPN 扩展都会改变 WebRTC 行为。把它们列出来。第一次测试请用禁用了扩展的配置文件或隐私窗口,这样看到的是浏览器自身的行为。
- 记下浏览器版本。 不同版本行为不同,以后重测时会用到。
有了基准,主测试的规则就很清楚:VPN 连接期间,列表里不能出现你基准里的公网地址。
如果想同时做一次常规泄漏检查,可在同一次会话里按如何检测 VPN 的 IP 地址泄漏的步骤操作。WebRTC 泄漏与普通网页请求泄漏是两回事,其中一项干净并不能说明另一项。
在 Chrome 中测试
Chrome 与其他基于 Chromium 的浏览器,WebRTC 行为大体相同。按下面的顺序做。
- 连接 VPN,等应用显示已连接。
- 打开一个新的无痕窗口。除非你特别允许,扩展在那里默认是关闭的。
- 加载 WebRTC 测试页面,等它收集完成,可能需要几秒钟。
- 逐行阅读列表,对每一行问:这是私有地址、.local 名称,还是公网地址?
- 把所有公网地址与你记下的基准对比。
- 再刷新两次。每次收集的结果可能略有出入。
- 如果你使用扩展,就逐个启用后再测一遍。调整 WebRTC 的隐私扩展可能去掉浏览器原本会显示的某个地址。
在当前版本的 Chrome 里,常见情形是用 .local 名称取代你的私有地址,外加一个公网地址。VPN 正常工作时,那个公网地址属于 VPN。如果出现两个公网地址,一个 IPv4、一个 IPv6,请把两个都与基准对比,因为泄漏常常藏在第二个里。较早的短格式地址在 RFC 791 中定义,IPv6 的行为在IP 泄漏的配套文章里有说明。
Chrome 没有为普通用户提供关闭 WebRTC 的内置开关。限制地址暴露的设置是留给扩展使用的,所以 Chromium 浏览器上的许多修复方案都以扩展形式出现。对待它们要像对待任何扩展一样谨慎:看清它们索要的权限,参见浏览器扩展与应用的对比。
在 Firefox 中测试
Firefox 开放了更多自身设置,对理解行为很有帮助。
- 连接 VPN 并确认它处于工作状态。
- 打开一个隐私窗口。
- 加载测试页面,等待候选地址收集完成。
- 像 Chrome 那样读取列表并与基准对比。
- 如果想做实验,在地址栏输入
about:config并接受警告,搜索media.peerconnection.enabled。 - 把该值设为
false会关闭浏览器的 WebRTC。重新加载测试页面,应当完全看不到候选地址。 - 实验完成后改回 true,除非你确定自己不需要浏览器内通话。关闭 WebRTC 后,视频会议网站、语音聊天和一些文件共享工具会无法使用。
Firefox 还有一些设置,能让浏览器在处理地址时更保守,而不必完全关闭 WebRTC。在高级页面搜索 media.peerconnection 即可看到。修改高级设置要小心:改前记下原值,如果浏览器行为异常,用同一页面的重置选项恢复。
由于 Firefox 可以开关该功能,它是证明因果关系的好办法:开着 WebRTC 时有泄漏,关掉就没有,说明问题出在 WebRTC,而不是整个 VPN 隧道。
读懂候选地址列表:判断表
下面是在 VPN 已连接时,对看到的内容进行分类的方法。
| 列表中的候选地址 | 示例 | 是否泄漏 | 原因 |
|---|---|---|---|
| 以 .local 结尾的随机名称 | a1b2c3.local | 否 | 浏览器正在隐藏你的本地地址 |
| 私有 IPv4 地址 | 192.168.1.20 或 10.0.0.5 | 通常否 | 只在你自己的网络内有意义 |
| 公网地址,与 VPN 出口相同 | 与普通 IP 检测结果一致 | 否 | 流量显示为来自 VPN |
| 公网地址,与基准相同 | 你运营商的地址 | 是 | 真实地址暴露给了网页 |
| 公网 IPv6 地址,与基准相同 | 很长的十六进制地址 | 是 | IPv6 线路绕过了隧道 |
| 完全没有候选地址 | 空 | 否 | WebRTC 被禁用或被阻止,通话可能无法使用 |
| 中继地址 | 不是你运营商的 | 否 | 属于某个中继服务 |
有两点要注意。第一,一个私有地址并非在所有场合都无关紧要:在共用的办公网络里,它会透露一点网络布局,有些人不愿意分享。第二,始终拿自己记录的基准去比,不要因为一个数字看着陌生就轻信它。
测试真实通话,而不只是测试页面
测试页面显示的是“可以被读取的内容”,通话测试显示的是“实际发生的事情”。这一步多花五分钟,能发现另一类问题。
- 双人测试。 开着 VPN,请朋友和你一起加入一个浏览器内的视频通话。通话后再检查一次测试页面:有些浏览器在通话期间会暴露不同的候选地址。
- 通话中切换网络。 在 Wi-Fi 上开始通话,然后切换到移动数据。WebRTC 在切换期间可能重新协商线路,之后立即运行测试页面。
- 音视频质量。 开着 VPN 时通话卡顿并不是泄漏,但说明通话走了隧道。延迟的解释见为什么使用 VPN 网速会变化。
- 权限提示。 当网站请求摄像头或麦克风时,确认你认识这个网站。与向错误页面授权相比,WebRTC 泄漏的风险要小得多。
对远程办公的人来说,最稳妥的习惯是在重要客户通话之前快速测一遍,而不是在通话中才发现问题。

公网地址泄漏时应该调整什么
从干扰最小的选项开始,逐步往干扰最大的选项走。
- 重新连接 VPN 并重测。 有时收集地址发生在隧道完全建立之前。
- 更新浏览器。 新版本往往能更好地限制地址暴露。
- 在没有任何扩展的干净配置文件里重测。 如果泄漏消失,说明某个扩展是原因。
- 使用浏览器自带的隐私设置(如果有),例如上文提到的 Firefox 选项,用能阻止暴露的最窄形式。
- 使用专门的隐私扩展限制 WebRTC 的地址处理(Chromium 浏览器适用)。先检查它的权限和口碑,之后再重测。
- 完全关闭 WebRTC,仅限于你在该浏览器里完全不需要通话的情况。可以考虑另用一个浏览器开会。
- 使用覆盖整台设备的 VPN 应用,而不是浏览器插件,让隧道保护整个设备而不是单个浏览器。浏览器扩展与应用的对比解释了原因。使用 XPASS 时,就是免费的 VPNclient 应用,用 My Pass 页面上的信息登录,参见下载页面。
每次改动之后都要再测一遍。在列表证明有效之前,不要假定修复成功。
WebRTC 测试中的常见错误
- VPN 还在连接时就测试。 等到完全连接。
- 把每个私有地址都当成泄漏。 私有地址段无法从更广的互联网访问。
- 忘了 IPv6。 两种类型的地址都要在列表里找。
- 相信旧结果。 浏览器更新、新扩展、新网络都会改变情况。
- 关闭了 WebRTC 却忘了。 然后周一早上会议打不开,没人记得为什么。
- 安装搜索到的第一个扩展。 一个声称修复隐私、却要求读取所有页面权限的工具,风险比泄漏本身更大。
- 以为 WebRTC 测试干净就等于完全隐私。 它只涉及一项功能。Cookie、账号和浏览器指纹仍然能识别你,Cover Your Tracks 展示了浏览器除了地址之外还暴露多少信息。
小结
WebRTC 泄漏测试,就是收集浏览器提供给网页的候选地址,并检查其中有没有公网地址与你开启 VPN 之前的地址相同。先记基准,在干净的窗口里测试,在 Chrome 和 Firefox 中逐行读取列表,把私有地址和 .local 条目与公网条目区别对待。如果发现真实泄漏,采用有效的最温和修复,重新测试,并且不要关闭超出必要的功能,以保证通话仍能使用。
当你想要一个 VPN 来做这些测试时,可以在价格页面按自己的节奏比较一次性付费的套餐。
常见问题
WebRTC 泄漏测试究竟显示什么?
它显示浏览器愿意交给网页、用于通话等实时连接的网络地址列表。关键是这份列表里有没有一个与 VPN 地址不同的公网地址。
结果里出现 192.168.x.x 这样的本地地址算泄漏吗?
本身不算。192.168.x.x 或 10.x.x.x 这类私有地址只在你自己的网络内部有意义。真正的泄漏是在开着 VPN 时,出现属于你网络运营商的公网地址。
应该彻底关闭 WebRTC 吗?
只有在你从不使用浏览器内通话或会议时才这样做。在 Firefox 中关闭,或在 Chrome 中借助扩展关闭,可能让视频通话和部分网页应用无法使用。限制地址暴露的较窄设置往往是更好的折中。
更新浏览器后需要重新测试吗?
需要。浏览器更新可能改变地址暴露的方式。大版本更新后重测一次,用不了两分钟。
关于作者

Bob Kanokphon Thongdee
- XPASS VPN 创始人
- eSIMonline.asia 联合创始人
- 7 年以上网络营销经验
- Cojourney Visa 与 Cojourney Travel 创始人
继续阅读

VPN 安全
什么是 IP 泄漏?IPv4 与 IPv6 泄漏详解
VPN 已连接,网站却可能仍然看到你的真实 IP 地址。本文说明 IPv4 与 IPv6 泄漏是怎么发生的、如何测试,以及该怎么处理。
阅读约 9 分钟

VPN 安全
VPN 浏览器扩展与 VPN 应用有什么区别?
浏览器 VPN 扩展与完整的 VPN 应用名字相近,保护的流量却不一样多。本文对比覆盖范围、泄漏、权限与速度,帮你选出合适的一种。
阅读约 9 分钟


