IP地址泄漏检测完整步骤

凌晨两点十七分，我被手机上一连串的推送惊醒。

不是短信，不是微信，而是我给自己搭的监控机器人——它每隔十分钟会抓取一次我常用设备的公网出口IP，一旦发现异常就告警。屏幕上赫然写着：

[ALERT] 出口IP变更：103.44.xx.xx → 45.132.xx.xx（新加坡） [ALERT] DNS解析异常：检测到非预期DNS服务器 8.8.8.8

我瞬间清醒。我人在国内，家里的宽带出口应该是本地运营商的地址，怎么会跳到新加坡？更诡异的是，我明明配置了VPN，所有流量都应该走加密隧道，出口IP应该是VPN服务器的地址才对。

只有一个解释：我的真实IP泄漏了。

那一夜，我从床上爬起来，打开电脑，花了整整四个小时，把IP泄漏这件事从头到尾查了个底朝天。这篇文章，就是那次“深夜排障”的完整复盘。如果你也在用VPN，或者你只是单纯地在意自己的隐私，那么这套检测流程，建议你一个步骤一个步骤地跟着走一遍。

为什么IP泄漏这件事，比你想的更严重

很多人对IP泄漏的理解还停留在“别人知道我在哪个城市”。但真实的威胁远不止于此。

IP地址是你的网络身份证。一旦泄漏，攻击者可以结合其他信息做很多事情：定位你的大致物理位置、关联你不同平台上的账号、绕过你设置的地区限制、甚至针对你的网络环境发起定向攻击。对于使用VPN的人来说，IP泄漏意味着你花钱买的隐私保护，在一瞬间归零。

更麻烦的是，IP泄漏往往是“静默”发生的。VPN显示已连接，图标是绿的，你以为一切正常，但实际上部分流量已经绕过了隧道，从真实网卡溜了出去。这种“假安全”状态，比完全不用的风险还大——因为你放松了警惕。

所以，检测不是可选项，而是必修课。

第一步：先搞清楚“泄漏”到底有哪几种

在动手检测之前，得先明白敌人长什么样。IP泄漏不是一个单一问题，它至少有四种常见形态，每一种的检测方法都不一样。

1. 公网IP泄漏（WebRTC / 普通查询）

这是最直观的一种：你访问一个显示IP的网站，结果看到的不是你VPN服务器的地址，而是你家宽带的真实地址。这种情况通常意味着VPN根本没生效，或者分流规则把该走隧道的流量放行了。

2. WebRTC泄漏

WebRTC是浏览器里用于实时音视频通话的技术，它有一个“特性”——为了建立P2P连接，它会绕过系统代理，直接通过真实网卡获取本地和公网IP。很多VPN对系统层面的流量做了接管，却管不住浏览器内部的WebRTC，于是你的真实IP就从这里漏了出去。这是最隐蔽、也最常见的一种泄漏。

3. DNS泄漏

你访问网站时，域名需要被解析成IP。如果这个解析请求没有走VPN隧道，而是发给了本地运营商的DNS服务器，那么即使你的网页流量是加密的，运营商依然知道你访问了哪些域名。DNS泄漏不会直接暴露你的IP，但它暴露了你的“行为轨迹”，同样致命。

4. IPv6泄漏

很多VPN只处理IPv4流量，而你的设备可能同时启用了IPv6。当访问支持IPv6的网站时，流量可能直接从IPv6通道出去，完全绕过VPN。这是一种容易被忽视的“半边泄漏”。

搞清楚这四类，接下来的检测才有针对性。我当晚的排查，就是按这个顺序逐个击破的。

第二步：基础公网IP核对——最直接的第一道关

这是最简单也最应该先做的一步。打开浏览器，访问任意一个IP查询网站（比如 ip.sb、ipleak.net、whatismyipaddress 之类），记下显示的IP和归属地。

然后做对比：这个IP，和你VPN客户端里显示的服务器IP，是不是同一个？归属地是不是VPN服务器所在的国家？

我当晚做的第一件事就是这个。结果页面显示的是新加坡地址——和我监控机器人告警的一致。这说明VPN的出口确实在新加坡，公网IP这一层没有泄漏，隧道是通的。

但别急着松口气。公网IP正常，不代表没有其他泄漏。WebRTC和DNS的问题，在这个页面上未必能完全体现。所以这一步只是“排除法”的起点。

这里有个小技巧：多开几个不同的检测网站交叉验证。有些网站会缓存结果，或者检测逻辑有差异，单一来源不可靠。我习惯至少用三个不同来源比对。

第三步：WebRTC泄漏检测——最容易被忽略的暗门

这一步是重点。访问 ipleak.net 或者 browserleaks.com/webrtc 这类专门做WebRTC检测的页面，看它列出的IP列表。

如果列表里只有你的VPN服务器IP，恭喜，WebRTC没漏。如果列表里出现了你家宽带的真实公网IP，或者出现了你本地局域网的地址（比如 192.168.x.x 加上真实公网），那就是典型的WebRTC泄漏。

我当晚在这一步发现了问题：页面在“Public IP”一栏显示了新加坡的VPN地址，但在WebRTC的候选列表里，赫然出现了我本地运营商的一个地址段。虽然不完全是我家的公网IP，但已经足够关联到我的真实网络环境。

为什么会这样？ 因为WebRTC的ICE候选收集机制会枚举本机所有网络接口，包括物理网卡。VPN的虚拟网卡只是其中之一，物理网卡的真实地址同样会被收集并可能被对端看到。

怎么修？ 三条路：一是在浏览器里禁用WebRTC（Chrome可以用扩展，Firefox可以在 about:config 里改 media.peerconnection.enabled）；二是在VPN客户端里开启“WebRTC泄漏保护”（不是所有客户端都有）；三是用支持WebRTC防泄漏的浏览器配置。我选的是第二条加第一条双保险。

第四步：DNS泄漏检测——看不见的行为泄漏

DNS泄漏的检测稍微技术一点，但原理不复杂。访问 dnsleaktest.com 或 ipleak.net 的DNS检测板块，它会告诉你当前是哪个DNS服务器在为你解析域名。

理想情况下，这里显示的应该是VPN服务商的DNS，或者至少是你配置的加密DNS（比如走DoH/DoT的公共DNS）。如果显示的是你本地运营商（比如电信、联通、移动）的DNS服务器，那就是DNS泄漏——你的域名查询请求正在被本地网络看到。

我当晚的结果是：DNS服务器显示为 8.8.8.8。这本身不算“本地运营商泄漏”，但问题是——我的VPN配置里明确要求DNS走隧道内的解析器，8.8.8.8 是明文DNS，说明我的DNS请求没有走加密通道，而是直接发出去了。这属于配置层面的泄漏，虽然没暴露给运营商，但暴露给了路径上的任何人。

修复思路：在VPN客户端里强制指定DNS，开启“DNS泄漏保护”，或者干脆在系统层面启用DoH（DNS over HTTPS）。我用的是在客户端里锁定隧道内DNS，并把系统DNS也改成加密解析，双管齐下。

第五步：IPv6泄漏检测——别让流量从“后门”溜走

这一步很多人会跳过，但它恰恰是“半边泄漏”的重灾区。

检测方法：访问 test-ipv6.com 或者 ipleak.net 的IPv6板块。如果你的VPN只处理IPv4，而你的网络环境启用了IPv6，那么访问IPv6站点时，流量可能直接从物理网卡的IPv6地址出去，完全不经过隧道。

我当晚查了一下，家里的宽带确实分配了IPv6地址，而我的VPN客户端默认没有接管IPv6流量。也就是说，虽然我访问大多数IPv4网站是安全的，但只要目标站点支持IPv6，我的真实IPv6地址就可能暴露。

修复方案：要么在VPN客户端里开启IPv6泄漏保护（通常是“阻止IPv6流量”或“通过隧道转发IPv6”），要么在系统网络设置里临时禁用IPv6。我选了前者，因为后者会影响一些本地服务的正常使用。

第六步：综合复测与常态化监控

四项检测做完、问题逐个修复之后，必须做一次完整的复测。把前面所有检测网站重新跑一遍，确认：公网IP是VPN地址、WebRTC列表干净、DNS走的是隧道内解析器、IPv6没有绕行。

但复测通过不代表一劳永逸。IP泄漏可能因为VPN断线重连、系统更新、浏览器升级、网络环境切换（比如从家里换到咖啡厅WiFi）而重新出现。所以真正靠谱的做法，是把检测常态化。

我的做法是：写了一个小脚本，每隔一段时间自动抓取出口IP和DNS信息，一旦发现和预期不符就推送告警——就是文章开头那个把我半夜叫醒的机器人。你也可以用更轻量的方式：收藏几个检测页面，每次切换网络环境或重启VPN后手动点一遍。关键不是工具多高级，而是养成“连上VPN先验一遍”的习惯。

那次深夜排障，最终定位到的问题是：VPN客户端在一次自动更新后，WebRTC保护和DNS锁定被重置成了默认关闭状态，而我恰好在更新后没有复检。一个很小的配置回退，就足以让“已连接”的绿色图标变成一种错觉。

IP泄漏检测这件事，说到底不是一次性的技术操作，而是一种安全习惯。VPN给你的是隧道，但隧道有没有漏，得你自己去敲一敲、看一看。别等到某天发现自己的真实地址出现在不该出现的地方，才想起那晚本该做的那几步检测。