WebRTC 泄漏：为什么用了代理还会暴露真实 IP

你开着 VPN，查了下 IP，显示的是代理的地址，看起来一切正常。但网站可能仍然知道你的真实 IP——通过一个叫 WebRTC 的浏览器功能。

这不是理论上的风险。很多人以为连上代理就万事大吉，却忽略了浏览器会从另一条通道把真实地址泄漏出去。这篇讲清楚它的原理，以及怎么自查。

WebRTC（Web 实时通信）是浏览器内置的一套功能，让网页无需安装插件就能实现音视频通话、屏幕共享、点对点文件传输。你用过的网页版视频会议、在线语音聊天，背后大多是它。

问题出在它的工作方式上。

要在两个浏览器之间建立直接连接，WebRTC 必须知道双方的网络地址——不只是公网 IP，还包括局域网内网地址。为此它会通过一种叫 STUN 的机制，主动向外部服务器查询"我的真实地址是什么"，然后把结果提供给对方。

关键在于：这个查询绕过了常规的代理设置。 很多 VPN 和代理只接管浏览器的 HTTP 流量，而 WebRTC 的地址发现走的是另一条路。结果就是——网页通过 HTTP 看到的是你的代理地址，但通过 WebRTC 拿到的是你的真实地址。

对网站来说，这等于同时看到了两个地址。而这种矛盾本身，就是一个强烈的风控信号。

直觉上，泄漏真实 IP 顶多是"代理白用了"。但实际情况更微妙。

如果你根本不用代理，网站只看到一个真实地址，一切自洽，没有异常。

而当 WebRTC 泄漏发生时，网站看到的是：一个来自 A 地的代理地址，同时暴露了一个来自 B 地的真实地址。 这种"一个人有两个地址、且分处两地"的状态，恰恰是风控系统重点标记的对象——它强烈暗示用户在刻意隐藏真实位置。

换句话说，一个泄漏的代理，可能比不用代理更容易引起注意。

具体来说，WebRTC 可能暴露：

公网 IP 地址：你真实的对外地址，即使代理正在运行。这是危害最大的一项。

局域网内网地址：类似 192.168.x.x 或 10.x.x.x 这样的地址。单独看似乎无害，但它能揭示你的网络结构，也可作为设备指纹的一部分。

IPv6 地址：如果你的网络支持 IPv6 而代理只处理了 IPv4，真实的 IPv6 地址可能直接暴露。这是一个很常见的疏漏。

打开环境检测，页面会列出 WebRTC 检测到的地址。判断方法很简单：

把 WebRTC 暴露的公网地址，和页面顶部显示的 IP 对比。

如果你没在用任何代理，两者一致是正常的，不必担心。这个检测的意义，主要在于使用代理时验证它是否真的把所有通道都接管了。

按有效性从高到低排列：

方案一：用防泄漏的代理工具。 质量较好的代理客户端会主动处理 WebRTC 泄漏，通常在设置里有相关选项。这是最省心的方式——如果你的工具支持，优先用它。

方案二：浏览器层面禁用 WebRTC。

方案三：用扩展精细控制。 一些隐私扩展允许你保留 WebRTC 功能但阻止它泄漏真实 IP，兼顾可用性。

代价要知道：完全禁用 WebRTC 后，依赖它的网站会失效——网页版视频会议、语音通话、部分在线协作工具都可能无法工作。如果你经常用这些，方案一或方案三更合适。

手机上也会泄漏吗？ 会。移动浏览器同样支持 WebRTC，原理一致。但移动 App 内置的 WebView 行为可能不同，需要单独测试。

用了 Tor 还需要担心吗？ Tor 浏览器默认对 WebRTC 做了严格限制，泄漏风险很低。但如果你是在普通浏览器里手动配置 Tor 代理，就仍然需要自查。

每次都要检查吗？ 更新浏览器、换代理工具、改网络配置之后值得重新测一次。平时如果工具稳定，不必反复检查。

禁用了 WebRTC 是不是就绝对安全？ 不是。WebRTC 只是泄漏真实地址的其中一条通道。时区不一致、DNS 泄漏、浏览器指纹等其他信号同样会暴露你，需要一并关注。

WebRTC 泄漏之所以值得单独讲，是因为它隐蔽——你查 IP 一切正常，却在另一条通道上暴露了。但它只是环境检测的一部分。

一个完整的自查还应该包括：时区与 IP 是否一致、浏览器语言与归属地是否匹配、是否存在虚拟机或自动化特征。这些信号任何一个对不上，都可能让"代理地址正常"这件事失去意义。

环境检测会一次性跑完这些项目，全部在你的浏览器本地完成，不上传任何数据。如果你想先搞清楚 IP 本身的类型和风控值，可以看这篇。

WebRTC 是个有用的功能，但它为了建立点对点连接而主动发现真实地址的机制，会在你使用代理时造成泄漏。判断方法就一条：对比 WebRTC 暴露的地址和你以为的地址是否一致。

一个泄漏的代理比不用代理更容易引起注意，因为"两个地址、分处两地"本身就是异常。定期自查，尤其在更换工具或网络之后。