WebRTC 泄漏是什么？怎么判断真实 IP 有没有暴露

你已经连上 VPN，网页显示的 IP 也变成了目标地区。

但打开 WebRTC 检测后，又出现了一个 IP。

很多人的第一反应是：

“完了，真实 IP 泄漏了。”

先别急着下结论。

WebRTC 能检测到网络地址，不等于真实公网 IP 一定泄漏。

真正需要看的是：

WebRTC 有没有暴露出一个与你当前 VPN 或代理出口不一致的公网地址。

如果你现在就在排查这个问题，可以先打开 EnvTrace WebRTC 泄漏检测。下面这篇文章不教你背协议，而是直接告诉你结果应该怎么看。

先看结论：什么情况才算 WebRTC 泄漏

假设你的网络是这样：

VPN 前公网 IP：A
VPN 后公网 IP：B

那么 WebRTC 检测结果可以这样判断：

最重要的一句话就是：

不要问“WebRTC 有没有显示 IP”，要问“它有没有显示不该出现的公网 IP”。

3 步检测真实 IP 有没有通过 WebRTC 暴露

最容易理解、也最不容易误判的方法，是做一次前后对比。

第一步：先记下 VPN 前的公网 IP

暂时断开 VPN 或代理，打开 EnvTrace IP 地址查询。

记下当前公网 IP。

例如：

198.51.100.8

这就是之后要拿来对比的基线。

第二步：连接 VPN，再查一次公网 IP

连接你真正准备使用的 VPN 或代理线路，然后刷新 IP 查询。

例如：

203.0.113.20

如果公网 IP 已经变化，说明普通网页请求看到的是新的出口。

第三步：运行 WebRTC 泄漏检测

现在再打开 WebRTC 泄漏检测。

重点不是看页面上有没有地址，而是找：

VPN 前那个公网 IP 有没有重新出现。

例如：

VPN 前：
198.51.100.8

VPN 后：
203.0.113.20

WebRTC：
198.51.100.8

这种情况才是非常明确的风险信号。

因为你本来希望 VPN 隐藏的公网出口，又通过另一条 WebRTC 网络路径暴露了出来。

如果 WebRTC 显示的仍然是：

203.0.113.20

也就是当前 VPN 出口，那么不能因为“WebRTC 显示了 IP”就直接判定泄漏。

WebRTC 为什么会看到不同的 IP

到这里你其实已经知道怎么判断结果了。

下面再解释为什么会出现这些地址。

WebRTC 是浏览器用来做实时通信的一套能力，比如：

• 视频通话；
• 语音聊天；
• 屏幕共享；
• 浏览器之间的数据传输。

为了让两个设备真正连起来，浏览器需要先找到一条能用的网络路径。

你可以把它理解成：

“我从哪条线路出去，才能连到对方？”

WebRTC 会收集几种可能的路径，技术上叫 ICE candidates（ICE 候选）。

其中常见的有三类。

1. 本机地址

这是设备当前网络接口上的地址。

比如：

192.168.1.25

它属于你的局域网，不是互联网网站平时看到的公网出口。

2. STUN 映射出来的公网地址

STUN 可以帮助浏览器知道：

“从互联网另一边看，我是从哪个公网地址出来的？”

如果 VPN 正确接管了 WebRTC 的这条网络路径，那么这里通常应该反映 VPN 出口。

如果这里又出现 VPN 连接前的公网 IP，就需要重点排查。

3. TURN 中继地址

有时候两个设备没办法直接连接。

WebRTC 会把通信交给一个 TURN 中继服务器转发。

这时检测到的是中继路径，并不是浏览器直接把本机真实公网 IP 交给了另一端。

所以：

看到 TURN / relay 地址，也不能直接等同于泄漏。

为什么开了 VPN，WebRTC 还可能出现另一条线路

“网页已经走代理”与“浏览器里所有网络能力都只走同一个出口”不是完全相同的事情。

常见原因有几种。

代理只接管了部分流量

有些代理主要处理网页的 HTTP / HTTPS 流量。

WebRTC 可能使用不同的网络路径。如果这些流量没有被同一套代理规则接管，就可能出现额外地址。

VPN 开了分流

很多 VPN 支持 split tunneling，也就是分流。

某些应用或流量走 VPN，另一些继续走原来的网络。

分流本身并不是错误。

但如果你希望整个浏览器环境都只使用 VPN 出口，而 WebRTC 恰好走了原线路，那么检测结果就会出现冲突。

设备同时连着多张网卡

一台电脑可能同时存在：

• Wi-Fi；
• 有线网络；
• 手机热点；
• VPN 虚拟网卡；
• 其他虚拟网络接口。

WebRTC 在寻找可用路径时，可能会看到不止一个网络接口。

所以“出现多个地址”首先意味着：

还有别的网络路径需要确认。

不是自动意味着“网站已经知道了你的真实身份”。

192.168.x.x 算不算 WebRTC 泄漏

这是最容易误判的一种情况。

例如检测页面显示：

192.168.1.25

或者：

10.0.0.8

这些都属于私有 IP。

它们可以在无数家庭、办公室和局域网里重复出现，所以不能像公网 IP 那样直接拿去判断你的互联网出口或大致地理位置。

因此：

本地私有 IP 暴露 ≠ 真实公网 IP 泄漏。

但这不代表它完全没有隐私意义。

本地地址可能让网页知道：

• 你处在怎样的局域网环境；
• 当前有哪些网络接口；
• 网络环境是否发生过变化。

这些信息还可能成为浏览器环境的一部分。

如果你想继续理解网站如何把网络信息与浏览器特征组合起来，可以看 什么是浏览器指纹。

.local 是什么？为什么看不到真实的 192.168 地址

现在的浏览器比早期 WebRTC 隐私模型严格得多。

所以你有时不会看到：

192.168.1.25

而会看到类似：

8f3c2a1b-xxxx-xxxx-xxxx.local

这通常与 mDNS 有关。

简单理解：

浏览器没有直接把本地私有 IP 交给网页，而是先用一个临时的 .local 主机名代替它。

所以看到 .local 时，不需要把它理解成：

“又发现了一个神秘真实 IP。”

它更像是一层本地地址保护。

WebRTC 检测不到 IP，就一定安全吗

也不能这么理解。

WebRTC 页面没有显示额外公网 IP，只能说明：

这次检测没有发现明显的 WebRTC 公网地址冲突。

它不等于：

• DNS 一定没有泄漏；
• IPv6 一定没有绕过；
• 浏览器指纹完全一致；
• VPN 一定无法被网站识别。

WebRTC 只是网络环境的一部分。

如果你的目标是检查当前出口是不是住宅、机房、代理，或者有没有黑名单和滥用风险，可以继续使用 IP 纯净度检测。

如果你关心的是网站能不能识别你正在使用 VPN，可以看 网站可以检测到 VPN 吗？。

发现 WebRTC 泄漏以后怎么处理

如果检测真的发现了 VPN 前的公网 IP，不要一上来就乱装插件。

按下面的顺序排查会更有效。

1. 先确认结果能重复

重新打开页面测试一次。

再确认：

• VPN 前公网 IP；
• VPN 后公网 IP；
• WebRTC 地址。

是否仍然出现同样的冲突。

一次偶发结果，不如稳定可重复的结果有判断价值。

2. 检查 VPN 或代理是否真的覆盖浏览器

重点看：

• 是否开启了分流；
• 浏览器有没有单独的代理设置；
• 当前使用的是系统 VPN，还是只代理网页请求；
• 是否还有其他网络接口保持连接。

3. 调整以后重新测试

修改网络配置后，不要凭感觉判断已经解决。

重新运行：

• IP 地址查询；
• WebRTC 泄漏检测。

确认两边的公网出口是否一致。

4. 最后才考虑限制 WebRTC

WebRTC 本身不是恶意功能。

彻底关闭它可能影响：

• 视频会议；
• 浏览器语音；
• 屏幕共享；
• 实时数据通信。

如果你确实不需要这些功能，可以根据浏览器或工具提供的隐私设置限制 WebRTC。

但如果你需要 WebRTC，更好的目标不是：

“让 WebRTC 消失。”

而是：

“让 WebRTC 使用正确的网络出口。”

WebRTC 泄漏和 DNS、IPv6 泄漏有什么区别

这几个词经常一起出现，但它们检查的不是同一个问题。

所以只查一次“我的 IP 是多少”，并不能覆盖整个浏览器网络环境。

最后怎么判断：记住这一条就够了

如果你只想记住一个判断方法，就是：

先记下 VPN 前的公网 IP，再连接 VPN，然后看 WebRTC 有没有把这个旧 IP 重新暴露出来。

不要因为检测页面出现：

• 192.168.x.x；
• .local；
• 当前 VPN 出口；
• TURN 中继地址；

就自动判断“真实 IP 泄漏”。

真正值得处理的是：

你原本想隐藏的公网线路，又从另一条 WebRTC 路径出现了。

现在可以直接运行 EnvTrace WebRTC 泄漏检测。

如果结果和当前公网出口不一致，再回到这篇文章按顺序排查。