IP、DNS 与 WebRTC 泄露：原因、检测与修复
Yalgorup 编辑部 · 更新于 2026年8月1日
核心要点
- DNS 泄露不看你访问了什么内容，但暴露了你解析了哪些域名 —— 信息量几乎等价。
- IPv6 泄露最隐蔽：客户端只接管 IPv4 路由，双栈网络下 IPv6 流量直接走原线路。
- WebRTC 通过 ICE 收集候选地址，浏览器脚本可以在不发起连接的情况下拿到本地与公网 IP。
- 检测要在连上 VPN 之后做，且必须同时查 IPv4、IPv6 和 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 之后，按顺序检查：
| 检查项 | 期望结果 |
|---|---|
| IPv4 出口 | VPN 服务器地址 |
| IPv6 出口 | VPN 服务器地址，或无 IPv6 |
| DNS 服务器 | 属于 VPN，不含本地运营商 |
| WebRTC 候选 | 不含真实公网 IP |
| 手动断开客户端 | 网络立即不通，而不是恢复直连 |
最后一项最值得亲手做一次：直接结束客户端进程（而不是点「断开」），然后看浏览器还能不能上网。很多 Kill Switch 只在正常断开流程里生效，在进程被强杀时并不起作用。
常见问题
怎么快速判断有没有 DNS 泄露？+
连上 VPN 后打开任意 DNS 泄露检测站点，看列出的解析服务器归属。如果出现你本地运营商的名称，就是泄露。
直接关掉 IPv6 是好办法吗？+
是常见且有效的临时办法，但会影响纯 IPv6 环境下的访问。更好的做法是选择明确支持 IPv6 或明确阻断 IPv6 的客户端。
浏览器要怎么处理 WebRTC？+
Chrome 系可用扩展限制，Firefox 可在 about:config 把 media.peerconnection.enabled 设为 false。注意这会影响需要 WebRTC 的视频通话网页。
检测网站显示位置不对，是泄露吗？+
不一定。IP 地理库本身就有误差，尤其是新启用的机房 IP 段。只要显示的 IP 是 VPN 服务器的，就不算泄露。