WebRTC 泄露到底是什么
WebRTC 是支撑视频通话、语音聊天和点对点文件传输的浏览器技术。要让两个人直接连通，双方的浏览器都要先发现自己可被访问的 IP 地址并交换出去。这个过程叫 ICE：浏览器向 STUN 服务器发起查询，后者回复你的公网地址。
问题在于：这个发现过程可能发生在 VPN 隧道之外。你正在访问的网页可以悄悄执行同样的协商，并读取返回的公网 IP — 正是你的 VPN 本应隐藏的那个地址。没有权限弹窗，也不需要下载任何东西。这就是 WebRTC 泄露。
谁需要关注
- 专门用 VPN 隐藏真实 IP 和位置的所有用户。
- 身处某些网络、即便已有隧道，浏览器仍会暴露反射（公网）候选地址的人。
- 注重隐私、想确认自己的配置确实如预期工作的用户。
本测试的工作方式
页面向公共 STUN 服务器（stun.l.google.com）发起一个 RTCPeerConnection，打开一个临时数据通道，然后读取浏览器生成的 ICE 候选地址。类型为 srflx、prflx 或 relay 的候选携带其他机器可访问的地址 — 如果其中出现公网 IP，那就是泄露。被 mDNS 混淆的（.local）候选会被忽略，私有网段地址只报告为本地地址，绝不当作泄露。一切都在你的浏览器中运行；没有任何地址会发送到我们控制的服务器。
绿色结果表示这一项具体检查通过了 — 此刻、在这个浏览器里，WebRTC 没有暴露公网地址。它不能证明你是匿名的：DNS、IPv6、浏览器指纹和 Cookie 是各自独立的通道，有各自的测试。
如何修复 WebRTC 泄露
有两条实在的路线，选哪条取决于你的情况：
1. 加固浏览器
- Firefox：打开
about:config，将media.peerconnection.enabled设为false。这会彻底禁用 WebRTC — 简单，但浏览器内的通话功能也会失效。 - Chrome / Edge / Brave：没有原生的关闭开关。Brave 在隐私设置中提供 WebRTC IP 处理策略；Chrome 需要安装能将 WebRTC 限制在代理地址上的扩展。
2. 使用在网络层堵住泄露的 VPN
设计良好的 VPN 应用会阻止 WebRTC 接触你的真实地址，这样你就不必禁用一个真正在用的功能。这是免维护的路线，也是为什么上方红色结果会引导你去看经过验证、能正确处理 WebRTC 的 VPN — 并非每一款都能做到。
常见问题
绿色结果意味着我完全匿名了吗？
不 — 它只表示这一种具体泄露不存在。匿名性还取决于 DNS、IPv6、浏览器指纹、Cookie 和账号登录。运行套件中的其他测试才能看到全貌。
为什么测试显示了 192.168.x.x 这样的本地地址？
那是私有局域网地址，不是你的公网 IP，无法在互联网上识别你。现代浏览器还会用 .local 名称把它遮蔽起来。对泄露而言，真正要紧的是公网（反射）地址。
我没有在用 VPN，需要在意吗？
不太需要 — 不用 VPN 时，你加载的每个网站本来就能看到你的 IP，WebRTC 暴露不出新东西。当你依赖隧道来隐藏这个地址时，这项测试才最有意义。
为什么测试无法判定？
你的浏览器没有返回可用的 ICE 候选地址 — 通常是因为 WebRTC 被禁用、扩展干扰，或防火墙拦截了 STUN。这不构成任何方向的判定：如果 WebRTC 被彻底禁用，也就无从泄露，但我们只报告实际测量到的内容。
继续检查
WebRTC 只是一条途径。以下测试覆盖其他途径：