DNS 与 IP 泄露：它们是什么，以及如何检测
你打开了隧道，指示灯亮着绿色——可测试结果依然显示出你的运营商和城市。DNS、IP 和 WebRTC 泄露就是这样暴露你的：通道是加密的，但个别请求却直接溜了出去，把你出卖了。
隧道会加密在它内部传输的一切，但它本身并不能保证你的全部流量都进了隧道。有些请求会绕过受保护的通道直接发出去——而恰恰是这些请求出卖了你：你的运营商、你的城市，有时甚至是你真实的 IP 地址。下面是最常见的三个漏洞，以及在五分钟内逐一检查的方法。
三种泄露，用大白话讲清楚
在动手检查之前，先弄明白我们到底在找什么会很有帮助。泄露分三种，机制各不相同：
- DNS 泄露。每次你打开一个网站，设备都会向 DNS 服务器询问该域名对应哪个 IP。如果这个请求发到了你网络运营商的服务器、而不是走隧道，那么即便流量本身是加密的，运营商也能看到你访问的网站列表。
- IP 泄露。网站或服务看到的是你的真实地址，而不是 VPN 服务器的地址。凭 IP 很容易查出你的运营商和大致位置。
- WebRTC 泄露。浏览器内置的视频通话技术，能直接获取你的本地和公网 IP 地址，绕过代理和隧道设置。
为什么最常出卖你的是 DNS
DNS 是互联网的通讯录：它把 example.com 这类便于阅读的名字翻译成数字 IP。问题在于，传统的 DNS 请求以明文发出，而且往往会被发给网络设置里写死的、或运营商指定的那台服务器。即使隧道在正常工作，系统也可能出于习惯去问“自己的” DNS——于是你访问的域名列表就暴露在网络那一侧了。
协议层面的解决办法，是把 DNS 请求本身加密。RFC 8484 标准描述了 DNS over HTTPS（DoH）：请求被封装进一个普通的 HTTPS 连接里，因此和其他网页流量无从区分，也能防止被篡改。据 Cloudflare 的文档，这样的请求走 443 端口——和普通网站用的是同一个端口——因此很难在整体流量中被单独挑出来。关于加密总体上能带来什么，我们在加密基础一文里讲过；而单纯更换 DNS 与 VPN 究竟有什么区别，则见 VPN、代理和 DNS：区别在哪。
IP 泄露与 WebRTC 的狡猾之处
“普通”的 IP 泄露比较好懂：如果网站看到的是 VPN 服务器的地址而不是你的，那就没问题。WebRTC 的行为则要狡猾得多。它是一种用于通话和设备间直接传文件的浏览器技术；为了建立直连，它需要知道通话双方的真实地址。
为此，WebRTC 会去联系所谓的 STUN 服务器。正如 MDN 的 WebRTC 文档所解释的，STUN 服务器会返回一个“server reflexive”候选地址——本质上就是从你家庭网络外部看到的那个公网 IP。浏览器拿到这个地址后，可以通过 JavaScript 交给网页，哪怕其余所有流量都在走隧道。这就是为什么测试有时会同时显示两个地址：一个是来自 VPN 的“正确”地址，另一个则是 WebRTC 暴露的真实地址。
五分钟自查
这是比基础检查更深入的一步——如果你还没确认隧道到底连上没有，请先从如何确认 VPN 正在工作开始。接下来专门讲泄露：
- 先查不开隧道时的地址。关掉 VPN，打开任意一个“我的 IP”类服务，记下地址和运营商——这是你的基准值。
- 打开隧道并刷新页面。IP 应当变成 VPN 服务器的地址和所在国家。如果原封不动，那就是 IP 泄露。
- 检查 DNS。打开一个带 DNS leak 测试的网站。服务器列表里不应出现你家庭运营商的名字。
- 检查 WebRTC。找一个在线的 WebRTC leak 测试。如果它显示出第一步里你的那个公网 IP——那就是有泄露。
- 换个网络再测一遍。这在咖啡馆和机场尤其重要：关于开放 Wi-Fi 的风险，我们在公共网络安全一文里讲过。
该怎么办，以及一个搭建正确的隧道如何帮上忙
好的客户端会自己堵住这些漏洞，无需你手动设置。需要留意的几点：
- DNS 走隧道内部。所有 DNS 请求都应通过同一条加密通道，发往 VPN 的 DNS 服务器，而不是运营商的。
- 断线保护（kill switch）。连接一旦中断，在通道恢复之前，流量不应直接泄露出去。
- WebRTC 控制。在浏览器里，用一项设置或扩展来堵住泄露，禁止网页请求本地地址。
HamikVPN 会加密全部流量，并把 DNS 请求裹进同一条受保护的通道，因此网站域名不会泄露给外部的 DNS 服务器，你真实的 IP 也对所访问的资源保持隐藏。如果开着客户端时测试仍然持续显示泄露，那是个危险信号——还该留意哪些方面，我们整理在了不可靠 VPN 的迹象一文里。