WebRTC IP 泄漏怎么查？VPN 与代理环境下的地址判断和排查
开启 VPN 或代理后，WebRTC 检测出现另一个地址，不一定就是公网 IP 泄漏。 先看候选类型和地址范围，再与同一时段的直连、网页出口作对照。若本应经过代理的测试反复暴露当前运营商公网地址，就应继续检查 WebRTC 的连接路径；单看检测页的红色提示还不足以定位原因。
作者：小仓 · 资料核对日期：2026-10-02
本文讨论浏览器 WebRTC 的地址暴露与代理排查，不对某个机场或 VPN 的隐私效果作实测认证。
一、为什么网页 IP 变了，WebRTC 结果却不同？
WebRTC 支持浏览器之间的音视频及数据通信，常见于会议、语音和文件传输。它的连接建立过程不同于普通网页下载。MDN WebRTC API 文档
建立连接时，ICE 会收集多条候选路径，并通过 STUN、TURN 等机制获取可用地址。网页 HTTP 请求走代理，不代表所有 WebRTC 探测都沿用它；在允许直连的环境里，STUN 请求可能绕过应用代理。分流 VPN 也可能让不同接口暴露不同公网地址。IETF RFC 8828
因此，排查目标应写清楚：你希望这个浏览器的哪些通信经过代理，而不是只要求某个 IP 查询页面显示节点所在地。接入概念可参考规则、全局与 TUN 的区别。
二、先读候选类型，再读地址
检测页面若显示 Type、Protocol 和 Address，先把它们一起记录：
| 常见类型 | 地址来自哪里 | 能说明什么 |
|---|---|---|
host |
网络接口对应的候选 | 可能涉及本地或虚拟接口；不能认为它天然就是私有地址 |
srflx |
向 STUN 等服务发起请求后获知的映射地址 | 需要判断它对应运营商、代理出口还是其他网络路径 |
relay |
TURN 服务分配的中继地址 | 这个地址可能属于 TURN 服务器，不能直接当作本机或机场出口 |
类型定义见MDN RTCIceCandidate 文档。IPv6 主机候选也可能是公网地址，不能按“host 就安全、srflx 就泄漏”的口诀判断。
候选是可供尝试的路径，不等于会议最终选用了它。若需要确认实际媒体出口，还应结合已选候选对与客户端连接记录；仅收集候选的测试不能替代真实通话验证。W3C WebRTC 统计与候选对说明
私有地址与 mDNS 名称怎样看？
192.168.1.20 这样的 RFC 1918 私有地址，不能当作运营商公网出口。私有 IPv4 的范围是 10.0.0.0/8、172.16.0.0/12 和 192.168.0.0/16，注意不是所有 172.* 都属于私有地址。RFC 1918
私有地址暴露仍可能透露局域网信息，与你担心的公网出口绕过是不同问题。遇到随机名称加 .local 的候选，可能是用 mDNS 名称替代本地 IP 的机制；它不是一个新的公网 IP。机制可参考IETF mDNS ICE 草案。该资料是草案，不能据此推断所有当前浏览器版本采用相同默认策略。
三、做一次条件明确的对照测试
1. 保留浏览器和网络条件
记录系统、浏览器版本、客户端与核心版本，以及浏览器代理扩展、系统代理、TUN 是否同时启用。保持同一设备、网络和节点，暂停测试期间的自动节点切换。
先用你已核对来源的网页 IP 查询工具记录 HTTP 出口，标明它是否实际检查了 IPv4 和 IPv6。只返回 IPv4 的工具，不能替你验证 IPv6。
2. 收集新的 ICE 候选
可以使用 WebRTC 项目的Trickle ICE 示例页：确认并记录 ICE servers 中使用的服务，保持配置不变，点击 Gather candidates，等待本轮收集结束。记录候选的类型、协议、地址和错误。
该页面会向所配置的 STUN/TURN 服务发起测试请求。无需填入机场订阅链接；也不要将私人 TURN 密码放进公开测试页面。不要为扩大测试范围随意勾选麦克风或摄像头权限项，已有权限状态应一并记录。
只有 host 或完全没有结果时，可能是 STUN 不可达、配置不完整、浏览器策略限制或脚本失败，不能立即写成“零泄漏”。页面出现部分错误，也不一定代表所有候选都未取得；应查看实际结果。
3. 与直连条件比较
若当前网络允许直连，且你愿意进行这个对照，可先关闭无关应用，在短时间内断开代理，重新创建一次测试，记录直连时观察到的地址；随后恢复代理，再发起新的测试。不能用同一页面里留存的旧候选代表重连后的结果。
如果不能或不希望断开，就跳过直连对照，把地址归属标为“尚未确认”。地址库里的运营商名称和地理位置只作辅助，不能代替同一时段的连接证据。
四、怎样解释对照结果？
| 结果 | 合理的下一步 |
|---|---|
| 出现私有地址或 mDNS 名称 | 单独评估本地信息暴露，继续检查公网候选 |
| WebRTC 地址与 HTTP 出口不同 | 检查候选类型、TURN 中继及不同出站，不先断言泄漏 |
| 开启代理后反复出现已确认的直连公网地址 | 核查非预期直连、UDP 接入和分流策略 |
| 公网候选只有预期出口 | 记录本轮范围；继续验证实际使用的会议或语音服务 |
| 没有公网候选或测试报错 | 先排除测试能力和可达性问题，不把空白当作通过 |
这张表是依据候选机制形成的排查方法，不是任何服务的测试结论。记录中还应区分“网页脚本看到地址”“探测请求走了直连”和“实际媒体用了直连”，三者需要的证据不同。
五、发现非预期直连后怎么处理？
先查看客户端是否接管相关 UDP、IPv6 和目标服务，核对命中规则及最终出站。只给浏览器装 HTTP 代理扩展时，不能假定它覆盖 WebRTC 的全部通信。TUN 也要检查实际路由和排除项，相关双栈问题见IPv6 代理验证。
浏览器还可能提供地址处理策略。例如 Chrome 的扩展隐私 API 定义了 webRTCIPHandlingPolicy，其中包含 disable_non_proxied_udp 等取值；这是供扩展使用的 API，不是每个浏览器界面都有同名开关。Chrome 隐私 API 文档
采用浏览器或已有可信扩展明确支持的设置，记录原值，每次改一项后重建测试，再验证常用会议、语音和文件传输。更严格的通信限制可能影响连接成功率或媒体体验，不能只检查 IP 页面就结束。
常见问题
禁用 WebRTC 后，就不会暴露身份了吗？
不能这样保证。WebRTC 只是网络信息的一部分；登录状态、网站会话和其他请求仍然存在。需要 WebRTC 功能时，优先把接入和地址策略调整到预期范围，再验证实际用途。
应怎样保存测试记录？
下面是空白模板，分享时可用“直连地址 A、代理地址 B”替代完整公网 IP，删去账户和服务凭据。
时间、系统、浏览器及客户端版本：
代理接入方式、节点、IPv4/IPv6检查范围：
网页HTTP出口记录：
ICE服务、权限状态与候选类型：
直连基线是否取得：
异常候选及客户端出站记录：
本轮唯一修改、重新测试结果：
实际会议或语音验证结果：
评论