WebRTC 泄漏测试很擅长制造紧张气氛：页面一打开，突然列出好几个 IP，再配一个红色“Leak”。很多人当场就去关闭浏览器功能，甚至觉得代理已经形同虚设。
先别急。测试页能收集到 ICE 候选地址，不等于它一定看到了你的真实公网出口。真正要判断的是：这是什么类型的候选、地址属于哪一层、它和代理前后的 IP 是否一致。
WebRTC 为什么需要这些地址
网页语音、视频会议和点对点通信要在不同网络之间建立连接。ICE 会尝试收集多种可用路径，再选一条能连通的。测试页只是把这些候选展示出来。
常见类型有：
host：设备本地接口产生的候选。现代浏览器可能用 mDNS 名称替代局域网 IP。srflx：STUN 服务器看到的 NAT 映射地址，常用于了解设备从公网看起来在哪里。prflx：连接检查过程中发现的对等反射候选，普通测试页不一定常见。relay：由 TURN 中继分配的地址，媒体流量经中继转发。
看到 192.168.x.x、10.x.x.x 或 mDNS 名称，和看到未经过代理的真实公网 IPv4，不是同一件事。
最有用的测试不是“看一眼红绿”
- 关闭代理，记录普通 IP 查询页显示的公网 IPv4 和 IPv6。
- 连接代理，确认普通网页出口已经变成代理地址。
- 再运行 WebRTC 测试，记录每个候选的类型和地址。
- 把
srflx等公网候选与第一步、第二步对照。
如果网页出口是代理 IP，但 WebRTC 的公网候选仍出现第一步记录的原始公网地址，这才是比较明确的泄漏信号。
为什么 IPv6 经常把判断搞乱
有些代理只接管 IPv4，设备却仍通过本地网络获得可用 IPv6。普通网页可能优先显示代理 IPv4，WebRTC 候选却暴露直连 IPv6。
这种情况确实值得处理，但它更准确的名字是“代理没有覆盖 IPv6 路径”，而不是 WebRTC 凭空创造了泄漏。可以结合IPv6 分层排查确认 IPv6 是否直连。
常见假警报
- 局域网地址：它能透露一些网络结构，但通常不是你在互联网上的真实公网位置。
- mDNS 主机名：浏览器用随机名称减少局域网 IP 暴露，不是新的公网地址。
- 代理节点地址：候选与普通网页出口一致，往往说明流量确实走了代理。
- TURN 地址：
relay候选本来就是中继服务器地址。 - 旧测试页的武断结论：有些页面只要看到候选就标红，没有结合候选类型。
确认泄漏后，从哪里修
优先检查代理或 VPN 是否明确支持 WebRTC、UDP 和 IPv6，是否启用了分应用代理，以及浏览器是否被排除在隧道之外。系统的“阻止不通过 VPN 的连接”也可能比某个浏览器扩展更可靠。
如果使用规则代理，确认 STUN/UDP 流量是否走代理或被阻断。不同客户端的 FakeDNS、TUN、系统 VPN 和仅 HTTP 代理能力完全不同，不能照抄一个开关名称。
浏览器扩展可以限制候选暴露，但它只能控制浏览器内的一部分行为。真正要求“所有流量不得直连”时，边界应该放在系统 VPN 或防火墙层。
要不要直接禁用 WebRTC
禁用确实可能让测试页变得很绿，同时也可能让网页通话、视频会议、语音聊天室和点对点传输失效。更合理的顺序是先让代理覆盖该覆盖的网络路径，再决定是否需要浏览器级限制。
如果你根本不用任何 WebRTC 功能，禁用的代价可能很小；如果每天开网页会议，为了截图全绿把功能砍掉，就有点像为了不担心爆胎把轮胎拆了。
最后留一份可复现记录
记录测试时间、浏览器版本、代理模式、是否启用 IPv6、普通网页出口，以及每个 ICE 候选类型。换一个可信测试页复核即可，不需要连续打开十几个页面让自己越来越慌。
手机端测试页显示异常时，可以用远程调试看 Console 和 Network，先确认测试脚本有没有被扩展、内容拦截或网络错误破坏。