DNS泄露、IPv6 与 WebRTC 泄露：原因、检测与修复

DNS泄露 是最常见、也最容易被忽略的一种 —— 隧道明明连上了，域名解析却还走着运营商的服务器。这一页按成因把四类泄露讲清楚，并给出一份可以自己跑一遍的检测清单。

泄露是什么意思

隧道正常建立，网站也确实看到了 VPN 服务器的 IP —— 但某一类请求走了别的路，把真实信息交了出去。这就是泄露。

它不是加密被破解，而是流量根本没进隧道。

一、DNS泄露：解析请求走了运营商

访问网站前要先把域名解析成 IP。如果这个查询发给了本地运营商的 DNS，那么即使后续流量走了隧道，运营商依然知道你解析过哪些域名。

成因

• 客户端没有修改系统 DNS 设置
• Windows 的「智能多宿主名称解析」会并行向多个网卡的 DNS 发查询，谁先回用谁
• 浏览器自己启用了 DoH，绕过了系统设置
• 手动配置的隧道（尤其是自建）只改了路由，没改 DNS

检测：连上 VPN，访问 DNS 泄露检测页面，看返回的解析服务器属于谁。

修复：使用会强制接管 DNS 的客户端；或在系统里把 DNS 固定为隧道内地址；Windows 上可关闭智能多宿主解析。

二、IPv6 泄露

这是最容易被忽略的一种。很多客户端只处理了 IPv4 路由，如果本地网络同时提供 IPv6，那么访问支持 IPv6 的网站时，流量会直接从原线路出去。

结果是：你以为在用日本节点，网站却看到了你真实的 IPv6 地址。

检测：连上 VPN 后访问同时显示 IPv4 与 IPv6 的检测页，两个地址都应该属于 VPN 服务器。若 IPv6 一栏显示你的本地地址，就是泄露。

修复：选择明确声明支持 IPv6 或会主动禁用 IPv6 的客户端；必要时在系统或路由器上关闭 IPv6。

三、WebRTC 泄露

WebRTC 是浏览器里做实时音视频的标准。为了打通点对点连接，它使用 ICE 框架（RFC 8445）收集本机所有可用的「候选地址」，其中包括局域网地址和通过 STUN 服务器发现的公网地址。

问题在于：网页里的 JavaScript 可以直接读取这些候选地址，不需要真的发起通话。于是一段脚本就能拿到你的真实 IP，哪怕全部流量都在隧道里。

现代浏览器已经做了缓解 —— 默认用 mDNS 随机主机名替代局域网地址 —— 但公网地址的暴露风险依然存在。

检测：使用 WebRTC 泄露测试页面，看列出的候选地址里有没有你的真实公网 IP。

修复：浏览器扩展限制 WebRTC；Firefox 可关闭 media.peerconnection.enabled；或使用会阻断非隧道流量的客户端。

四、断线瞬间的回落

隧道断开的那几秒，系统会把流量退回默认路由。正在下载的连接、后台同步的应用会立刻用真实 IP 继续跑。

这类泄露持续时间短，却最难察觉，因为它发生时你可能根本没在看屏幕。

对应的机制是 Kill Switch：在隧道不可用时直接阻断出站流量，而不是放行。

泄露自测清单

连上 VPN 之后，按顺序检查：

最后一项最值得亲手做一次：直接结束客户端进程（而不是点「断开」），然后看浏览器还能不能上网。很多 Kill Switch 只在正常断开流程里生效，在进程被强杀时并不起作用。