WebRTC 泄漏检测
浏览器为了建立点对点连接，会主动把自己能用的所有地址报出来备选。这个过程不走你平时的代理设置，所以有可能在你毫不知情的情况下送出另一个公网地址。本页收集这些候选，与出口地址逐一比对，给出四种明确结论之一。
最后更新：2026-07-26
检测结果
收集候选最多等待 2.5 秒；期间不会向任何第三方发送你的地址。
准备中…
浏览器为什么会自己报出地址？
点对点连接要在两台设备之间穿透各自的网络边界，双方必须先交换「我可以从这些地址被连上」的清单。据 RFC 8445，这个收集与配对的过程叫做交互式连接建立，浏览器会把本机地址、经过地址转换后的映射地址、以及中继地址全部枚举出来。
关键在于这套枚举独立于浏览器的代理配置。系统代理只管普通请求，管不到这条通道，于是就出现了页面本身走线路、而候选地址来自本地网络的分裂状态。
四种结论分别代表什么
检测到泄漏——收集到的公网候选和出口地址不是同一个，说明真实地址确实被送了出去，这是唯一需要立刻处理的结果。
未见泄漏——有公网候选，但和出口地址一致，说明这条通道也走了线路。
已保护——只有内网或 mDNS 候选，公网地址根本没被枚举出来。
无法判断——有候选但缺少可对照的出口地址。我们把它单列出来，而不是并进「未见泄漏」，因为两者的证据强度完全不同。
这一页测不出什么
它无法告诉你某个网站是否真的读取过这些候选——那发生在对方的脚本里，浏览器不提供回溯。它也不区分泄漏是浏览器设置、扩展冲突还是客户端本身缺少防护造成的，只能确认结果存在。
另外，本次判定依赖单一 STUN 服务器在限定时间内的回应。网络抖动可能让一次收集不完整，所以结论以多跑两次的稳定结果为准。
常见问题
判定结果为「已保护」是什么意思？
意思是本次只收集到内网段或 mDNS 形式的候选，没有任何公网候选被送出。现代浏览器默认会把本机地址替换成随机的 mDNS 名字，这是设计使然，不是线路的功劳，但结果确实是安全的。
为什么会出现「无法判断」？
因为收到了公网候选，却没能拿到用于对照的出口地址——通常是几个取址接口都没连上。缺少参照物时我们宁可给出无法判断，也不愿把可能正常的情况报成泄漏。稍后重试一般就有结论了。
关掉这个功能会影响什么？
会影响所有依赖点对点连接的网页应用：网页版视频通话、屏幕共享、浏览器里的在线会议都可能连不上或退化为中转。如果你日常要用这些，更合适的做法是换一个自身带防护的客户端，而不是关掉浏览器功能。
候选地址里有一串奇怪的字母数字，那是什么？
那是 mDNS 主机名，形如一串随机字符加上 .local 结尾。浏览器用它替代真实的内网地址，让网页拿不到你的局域网信息，属于正常且安全的现象。
手机浏览器也需要查这一项吗？
需要。移动端浏览器同样实现了实时通信通道，行为和桌面端一致。在蜂窝网络下尤其值得查一次，因为运营商网络常常同时提供两种协议栈的出口。
与其关掉浏览器功能，不如用一个自带防护的客户端。