代理明明已经连上，网页里显示的也是代理 IP，为什么做浏览器检测时还能看到另一个地址？碰到这种情况，先别急着换代理，问题很可能出在 WebRTC。它是浏览器自带的实时通信功能，在特定网络和代理配置下，可能暴露本地网络地址，甚至让网站发现 WebRTC 使用的出口 IP 与网页出口 IP 不一致。
下面结合实际检测结果，聊清楚 WebRTC 为什么会暴露 IP、怎么判断当前浏览器有没有泄露，以及在启元指纹浏览器中该选哪种设置。
WebRTC 是什么，为什么可能泄露 IP？
WebRTC 的全称是 Web Real-Time Communication，主要用于浏览器里的视频通话、语音聊天、屏幕共享和点对点传输。很多在线会议、网页客服和直播连麦功能都离不开它。
为了建立实时连接，WebRTC 会通过 ICE 机制寻找可用的网络路径。这个过程中，浏览器可能收集几类候选地址：
- 本机的局域网地址；
- STUN 服务器探测到的公网出口地址；
- 通过 TURN 中继服务器使用的地址。
麻烦往往出在这里：普通 HTTP 或 SOCKS 代理主要接管网页请求，不一定会正确处理 WebRTC 的 UDP 流量。如果两边走的网络路径不同，网站看到的网页出口 IP 和 WebRTC 候选地址就可能对不上。这种不一致不一定等于真实 IP 已经完全暴露，但足以成为判断网络环境异常的一项依据。
现在的 Chromium 浏览器通常会用 mDNS 隐藏部分本地局域网地址，所以检测页面显示随机主机名并不奇怪。真正需要留意的是：WebRTC 检测出的公网地址，是否和当前代理出口一致。
如何检测 WebRTC 是否泄露 IP？
检测并不复杂。先连接准备使用的代理，再打开 WebRTC 检测页面，例如 BrowserLeaks 的 WebRTC Test。页面加载后，重点看下面两项：
- Public IP Address：是否与代理出口 IP 一致；
- Local IP Address：是否显示真实局域网地址，或已经被 mDNS 主机名替代。
如果网页查询到的是代理 IP，而 WebRTC 的 Public IP Address 显示了另一个公网 IP，说明两类流量没有走同一条线路，需要调整 WebRTC 策略或检查代理配置。修改后最好关闭当前页面，用新标签页重新检测一次；如果浏览器环境已经启动，也可以重启环境后再测，避免旧连接影响结果。
启元指纹浏览器的 WebRTC 怎么设置？
在启元指纹浏览器中新建或编辑浏览器环境，可以看到 WebRTC 设置。目前有基于 IP、真实、禁用和转发四种模式。它们没有绝对的好坏，主要看网站是否需要实时音视频功能。
基于 IP
这个模式会根据当前代理网络处理 WebRTC 地址，让检测结果尽量与代理出口保持一致。日常运营既要控制 IP 一致性，又可能用到网页语音、视频等功能时，可以优先选它。设置完成后仍建议实际检测一次，因为最终结果还会受到代理协议和网络环境影响。
真实
浏览器不额外干预 WebRTC，网站按当前真实网络环境获取候选地址。正常单账号使用、无需隐藏网络信息，或者专门调试 WebRTC 功能时可以选择；使用代理管理多个独立环境时，一般不建议这样设置。
禁用
关闭 WebRTC 相关能力，操作简单，也能避免 WebRTC 地址与代理 IP 不一致。不过，依赖 WebRTC 的视频会议、网页通话、语音客服和屏幕共享可能无法正常使用。如果平时只是登录后台、发布内容或处理订单，不需要这些功能，禁用通常更省事。
转发
转发模式适合需要 WebRTC 功能、同时又有特定网络线路要求的场景。它会通过指定方式处理相关连接，对网络配置要求更高。没有这类需求时，不必为了“更安全”特意选择转发。
WebRTC 模式应该怎么选？
- 只做网页浏览、电商后台或内容运营，不用语音和视频：选择禁用；
- 需要网页通话、视频会议，同时希望地址与代理 IP 保持一致：选择基于 IP；
- 不使用代理，希望保留浏览器默认通信能力：选择真实；
- 有明确的 WebRTC 网络转发需求：选择转发。
我自己的习惯是，先按使用场景选模式，再打开检测页面核对结果。不要只看设置项已经保存，就默认不会泄露。代理类型、系统网络、IPv6 和浏览器版本都可能影响最终表现，实测结果才最可靠。
WebRTC IP 泄露常见问题
关闭 WebRTC 会被网站识别成异常浏览器吗？
网站可以知道 WebRTC 是否可用，但通常不会只凭这一项就认定浏览器异常。真正影响环境判断的，往往是 IP、时区、语言、系统信息等多项数据之间是否矛盾。不过，如果目标网站本身依赖 WebRTC，直接禁用就会影响功能，这时更适合使用基于 IP 模式。
用了 VPN，还需要检查 WebRTC 吗？
需要。配置完整的 VPN 通常会接管系统流量，WebRTC 未必会泄露真实公网 IP，但不同 VPN、分流规则和 IPv6 设置的表现并不一样。最稳妥的做法还是连接 VPN 后跑一次 WebRTC 检测，确认页面出口与检测结果一致。
只隐藏本地 IP 就够了吗？
不够。本地 IP 被 mDNS 隐藏，只能说明局域网地址没有直接显示。还要检查 Public IP Address，确认它没有绕开代理走其他出口。对于代理环境来说，公网地址是否一致更值得关注。
手机浏览器也会有 WebRTC 泄露吗？
手机浏览器同样支持 WebRTC，也可能出现地址或线路不一致。不过移动网络通常经过运营商 NAT，检测结果会和电脑宽带不同。不要照搬电脑端的判断，直接在手机当前网络和代理状态下测试即可。
最后说两句
WebRTC 本身不是漏洞，它只是实时通信所需的一套浏览器能力。真正需要处理的是：开启代理后，网页流量和 WebRTC 流量是否走了不同出口。把模式选对，再用检测网站复查公网地址，基本就能避开这类问题。