两个每个人都该做的泄露检测：WebRTC 与 DNS

人们把「IP 泄露」说成是一个 bug。它至少是两个，藏在不同层里，修法也不一样。你可以把其中一个彻底关掉，却依然从另一个暴露；而测试页上显示出 VPN 的地址，对这两件事都不能证明什么。

一、先想清楚：你在意的是哪个观察者

每个泄露问题本质上都是「谁知道了什么」。你访问的站点知道你连过来时的地址；你所在的本地网络知道你解析了哪些域名；浏览器的网络栈知道你的本地地址，而且很愿意告诉对端。VPN 承诺改变的是第一项；除非专门配置过，否则它对第二项和第三项什么也没说。

二、WebRTC：浏览器主动把地址递给对端

WebRTC 的存在是为了让两个浏览器直连，传输音视频与数据。为此它会收集 ICE 候选——包括本地地址，和通过 STUN 服务器发现的公网地址——并把这些发给对端。如果你的 VPN 客户端没有把这类流量纳入隧道，STUN 请求就会从物理网络直接出去，候选列表里于是出现了你真实的公网地址。而网站可以用 JavaScript 读到这份列表，不需要任何授权。

要看的特征很简单：某个地址和站点为你的 HTTP 请求报告的地址不一致，或者公网地址旁边还躺着一个 192.168.x.x。前者说明网页流量走了隧道、WebRTC 没走；后者本身没有向互联网泄露什么，但确实说明候选收集没有被限制。

三、DNS：你的解析器知道你打开的每一个站

任何连接之前，域名都要先变成地址。这个查询通常以明文离开你的机器，发往操作系统挑选的那个解析器——而系统挑选的方式是一团乱麻：DHCP 选项、网卡级设置、systemd-resolved、VPN 客户端脚本、浏览器内置 DoH。最终生效的那个，很少是用户以为的那个。

可靠的测法比「问一个网站」要绕一点：请求一个唯一域名，让权威服务器记录下是谁替你发起了这次查询。那个解析器地址、以及运营它的网络，才是唯一可信的答案。解析器与出口 IP 同国、且由同一家运营，直连情况下属于正常。解析器与出口 IP 不同国，说明流量从一地出去、查询从另一地发出——这就是 DNS 泄露的定义。

四、把两个结果放在一起读

• 出口 IP 与解析器同国，且都来自你的运营商：没用 VPN，什么都没漏，一切符合预期。
• 出口 IP 在国外，解析器还在国内：VPN 路由了流量但没接管 DNS。这是最常见的一种错配。
• 出口与解析器都在国外，但分属不同服务商：不算泄露，但两条路径走了不同路由，而且解析器看得见全部——VPN 看不见。
• 解析器属于 Cloudflare、Google 或 Quad9：加密 DNS 开着。运营商看不到查询了，那家公司能看到，而且是全部。

五、修掉它们，同时别把东西弄坏

WebRTC 的可靠解法是带全隧道路由、且 kill switch 覆盖 UDP（不只是 TCP）的 VPN 客户端。直接关掉 WebRTC 也行——Firefox 在 about:config 里有 media.peerconnection.enabled——但会顺带毁掉正常的视频通话，所以大多数人更适合选一个把 STUN 代理进隧道的客户端，而不是把功能关死。

DNS 要在隧道层面强制，并且验证，因为浏览器或系统的一个设置就能悄悄覆盖你的意图。如果 VPN 客户端有个「DNS 泄露保护」开关，那说明本该由配置完成的事得靠这个开关来做；每次客户端更新后都重测一遍，路由是会被重写的。在自己能控制的网络上，自建解析器、用 DHCP 下发，再把它到上游那一段套上 DoT。

六、两个测试都测不到的东西

它们都不衡量「你是否可被识别」。TLS 指纹、装了什么字体、时区、屏幕尺寸、打字节奏，这些依然属于你，代理一个都改不了。泄露测试干净，只意味着那几扇显眼的门关上了，不代表房间里没人。

ipbox.one 首页会同时跑这两项检查：浏览器暴露的 WebRTC 候选地址，和实际应答你的解析器，并与 Cloudflare 看到的地址并列展示——三者可以直接对比，而不用靠推断。