关于 浏览器 IP、WebRTC 与 DNS 泄漏检查
浏览器 IP、WebRTC 与 DNS 泄漏检查会从当前浏览器同时发起四项探测：一次 IPv4 请求、一次 IPv6 请求、一轮 WebRTC 候选采集，以及 50 次一次性 DNS 解析，然后把它们放在一起比对，让你看清「网站看到的地址」「WebRTC 会提供给对端的地址」和「实际应答你的解析器」是否都是你预期的那一个。
隧道的私密程度，取决于它最窄的那个旁路。WebRTC 通过操作系统的网络栈采集候选地址，而不是走浏览器的 HTTP 路径，因此一次点对点连接可能把本该被隧道遮住的网卡通告出去。DNS 的问题更严重，因为解析发生在任何连接建立之前：一条发往运营商指定解析器的查询，会把你访问的每个主机名都告诉那台解析器，无论流量之后从哪个出口走。这两类情况都不会以报错形式出现，所以必须主动去探。
如何使用这个开发者工具
- 点击开始，让四项检查并行跑完；计数会显示四项中已完成几项。
- 先读 IPv4 与 IPv6 两张卡片 —— 那是普通网站看到的地址，也是后续一切比对的基准。
- 展开 WebRTC 候选列表，关注每条候选的类型与作用域，而不只是数量。
- 看着 DNS 卡片计数到 50，再读解析器列表：这些是实际向探测域名发起查询的解析器，并带有各自所属的网络。
- 改动一个变量 —— 开关 VPN、修改 WebRTC 设置、换一台解析器 —— 然后重跑。两次运行之间的差异，比任何单次结果都更有信息量。
实例：VPN 被 WebRTC 旁路
HTTP 流量确实走在隧道里，但 WebRTC 环节从物理网卡上采到了一条候选。这正是结论行要找的模式。
点击开始 —— 四项检查并行运行结论：检测到泄漏 4/4 已完成
IPv4 可用 203.0.113.45
IPv6 不可用 未返回公网地址
WebRTC 候选 6 · 公网 1 · 本地 1 · mDNS 遮蔽 是
198.51.100.77 IPv4 · srflx · public
192.168.1.24 IPv4 · host · private
3f2a1c9e-...-.local IPv6 · host · masked
DNS 50/50 次探测 · 2 个解析器 · 1840 ms
198.51.100.10 IPv4 DE · Frankfurt · Example Resolver GmbH
198.51.100.11 IPv4 DE · Frankfurt · Example Resolver GmbH这里有两项独立的发现。srflx 候选与 HTTP 呈现的地址不一致，意味着 WebRTC 会把一个与网页流量不同的出口提供给对端。另外，192.168.1.24 是局域网内的私有地址 —— 单看对网站危害有限，但它确认了 WebRTC 正在直接读取网卡，而没有被过滤。
ICE 候选类型及其暴露的信息
每条候选都有一个类型。类型加上地址是公网还是私有，决定了这条候选值不值得关注。
| 类型 | 含义 | 会暴露什么 |
|---|---|---|
| host | 绑定在本机某张网卡上的地址 | 本机自身的地址。私有地址（192.168.x.x、10.x.x.x、fe80::）会暴露局域网结构；公网地址就是你的真实地址，与 HTTP 层的任何隧道无关。 |
| srflx | 服务器自反：STUN 服务器观察到的公网地址 | WebRTC 流量实际会从哪个出口离开。把它和 HTTP 地址对比 —— 不一致就说明是两条不同路径。 |
| prflx | 对端自反：从对端连通性检查中学到的地址 | 只会在与真实对端的活动连接中出现。独立检查里一条都没有是正常的。 |
| relay | TURN 服务器上用于转发流量的地址 | 中继服务器的地址，不是你的地址。只有配置并通过 TURN 认证后才会出现。 |
| mDNS（.local） | 用随机主机名替换掉的私有 host 候选 | 不暴露任何网络信息。浏览器默认以此遮蔽 host 候选；这是正在生效的保护，而不是一次失败。 |
常见问题排查
所有 host 候选都是 .local 主机名，看不到地址。
成因 浏览器默认把私有 host 候选替换成随机的 mDNS 主机名，目的正是不让页面读到你的局域网地址。
解决办法 不需要修。这是受保护的状态，卡片会标注为「已遮蔽」。真实的点对点连接仍然正常，因为两个对端会在彼此之间解析这些名字。
WebRTC 显示被阻止，或者一条候选都没采到。
成因 隐私扩展或浏览器设置禁用了 WebRTC 或对等连接构造函数，也可能是页面不处于安全上下文中。
解决办法 可以视为通过 —— 这比本工具能做的任何比对都更强的保护。如果要验证自己开发的应用里 WebRTC 是否可用，请用「WebRTC 功能检查」。
DNS 卡片跑完后一个解析器都没有。
成因 扩展、带过滤的解析器或企业策略拦截了探测主机名，也可能是 12 秒超时把请求截断了。
解决办法 关闭内容拦截类扩展后重跑。零结果意味着探测没能完成，它在任何方向上都不构成关于你解析器的证据。
列出的解析器位于与 VPN 出口不同的国家。
成因 大型公共解析器以任播集群运行，并在站点之间转发查询，因此抵达权威服务器的地址常常不是你配置的那一个。浏览器层面的 DNS-over-HTTPS 更会完全绕开系统解析器。
解决办法 对比解析器的 ASN 组织，而不是它的地理位置。运营商对得上、城市却出乎意料是正常的；运营商完全不同，才是真正的发现。
某条公网 WebRTC 候选正是你的宽带地址，而 HTTP 显示的是 VPN 地址。
成因 隧道只作用在浏览器或应用层，而 WebRTC 直接摸到了物理网卡；也可能是分流规则把 UDP 排除在隧道之外。
解决办法 这是一次真实的旁路。打开 VPN 客户端的 WebRTC 保护或全局隧道模式，或在该浏览器配置中禁用 WebRTC，然后重跑确认这条候选已经消失。
适合用这个工具的场景
- 在用某条连接参加会议之前，确认 VPN 或代理是否会被 WebRTC 旁路。
- 弄清楚实际替你应答的解析器是哪一台，而不是你以为配置了哪一台。
- 对比开启和关闭 WebRTC 保护的两个浏览器配置，确认扩展确实在起作用。
- 在改动隧道、DNS 或浏览器隐私设置时，留下一份改动前后的对照快照。
应该换用别的工具的场景
- 证明你是匿名的。它只在某一时刻检查四条路径；指纹、Cookie、登录态和流量分析识别一个人的可靠性远高于 IP 地址。
- 审计应用的 WebRTC 配置，或测试你自己的 STUN 与 TURN 服务，这些是「WebRTC 功能检查」的职责。
- 测试你运维的代理。代理批量检查会从我们的服务器经由该代理发起连接，并报告它究竟在哪一步失败。
隐私与数据处理
本工具完全在你的浏览器中运行，不会把任何结果发送到本站服务器。IPv4 与 IPv6 请求由浏览器直接发往已配置的探测入口。WebRTC 环节在本地创建一个对等连接，采集候选后随即关闭；不联系任何对端，也不采集任何音视频。DNS 检查会请求 50 个主机名，它们由一次性随机标签拼在受控探测域名之下，因此这些域名的权威 DNS 服务可以回报是哪些解析器发起了查询 —— 标签每次现场生成、从不复用，本身不携带任何与你有关的信息。同样重要的是：它读不到你操作系统的代理配置，看不到你的 VPN 客户端，也从不处理任何凭据。
相关开发者工具
常见问题
网页能读到我的系统代理设置吗？
不能。页面没有任何接口可以访问操作系统的代理配置。这里的一切都是路径比对得出的推断：HTTP 请求呈现了什么、WebRTC 采到了什么、哪台解析器查询了探测域名。
DNS 探测的「一次性」体现在哪里？
50 个主机名各自使用现场生成的随机标签，任何解析器都不可能缓存过它们，每次查询都必须抵达探测域名的权威服务，该服务再回报是哪些解析器发起了查询。复用名字只会命中缓存，什么也测不出来。
为什么列表里有多个解析器？
解析器运营方以集群方式运行，递归解析器在抵达权威服务器之前还可能把查询转发给同集群的兄弟节点。发送 50 次探测正是为了让这种分散暴露出来；只查一次会暗示出一种并不存在的确定性。
WebRTC 列表里出现私有地址危险吗？
单独看危险有限 —— 它会告诉页面你的局域网编址，对扫描和指纹有帮助，但不是你的公网身份。更严重的是出现了与 HTTP 地址不同的公网候选，那意味着存在一个你并不知情的第二出口。
检查结果会被发送到哪里吗？
不会。比对在你的浏览器里完成，不会传输到本站服务器。探测入口看到的是你的 HTTP 请求，STUN 服务器看到的是一次候选采集请求，权威 DNS 服务看到的是哪些解析器发起了查询 —— 各方都只知道自己那一部分。
显示「未发现明显泄漏」，是不是就安全了？
它的意思是：此刻、在这张网络上，这四项检查彼此一致。这不是一次安全审计：浏览器指纹、已登录的会话、第三方跟踪器、流量时序分析，都发生在页面能测试的范围之外。
这项检查为什么需要 STUN 服务器？
服务器自反候选之所以存在，正是因为有一台 STUN 服务器观察并回报了你的公网映射。没有它，浏览器就只能采集 host 候选，与 HTTP 地址的比对也就无从谈起。