VPN 连上了但没生效?查 IP、查 DNS 的完整验证方法

客户端显示「已连接」,浏览器里的目标站点却依旧打不开;或者页面能打开,但查询出口地址时显示的仍是本地运营商的归属地。这类情况在排查记录里出现频率很高,而且多数不是线路故障,而是流量根本没有走进隧道。判断 VPN 是否真的生效,不能看界面上的连接状态,要看两个可验证的指标:出口 IP 有没有换、DNS 解析有没有跟着换。

本文给出三步验证法:查出口 IP、查 DNS 泄漏、分应用对比测试,并拆解六种「看起来连上了其实没走」的典型情况与对应修法。整套流程覆盖 Windows、macOS、iOS、Android 与 Linux,不需要安装额外的检测工具,用到的都是浏览器页面和系统自带命令。

为什么「已连接」不等于已生效

客户端里的连接状态,只说明客户端进程与线路入口之间的握手成功了,它不保证系统里其他程序的流量会走这条隧道。真正决定「生效」的是接管层级:客户端用哪种方式把流量导向隧道,以及 DNS 与 IPv6 有没有被一并接管。

接管层级:扩展、系统代理与 TUN

三种方式没有绝对优劣。系统代理部署轻、对系统改动小,但覆盖面窄,只对读取系统代理设置的应用有效;TUN 接管覆盖面广,代价是需要更高权限:Windows 上要安装虚拟网卡驱动,macOS 与 Linux 上要授权网络扩展或以相应权限运行。如果你的目标是让所有程序都走线路,应先确认客户端处于 TUN / 全局接管模式,而不是系统代理模式。

另一个常被忽略的层面是 DNS。即使流量已经走进隧道,解析请求仍可能发给本地网络下发的解析器,拿到被就近调度或被替换的结果,表现就是「连上了,但域名打不开,或者打开的是另一个区域的版本」。所以验证必须同时看 IP 和 DNS,缺一不可。

第一步:查出口 IP,看流量有没有换出口

这一步的目标很简单:拿到连接前后的两个出口地址做对比。按下面的顺序做一遍,基本就能定性。

1. 断开客户端,先测一次,记录出口 IP、归属地与运营商(ASN)。
2. 连接客户端,确认当前使用的是哪条线路、哪个地区。
3. 用同一个查询服务再测一次,对比 IP 与归属地是否发生变化。
4. 单独查一次 IPv6 出口。IPv6 常被忽略,它是「连上却没走」的高发区。
5. 换一个查询服务复测一次,排除页面缓存造成的误判。

查询服务本身也可能受 CDN 影响:部分查询站点走 CDN,返回的归属地是 CDN 节点所在位置,而不是你的真实出口。遇到「IP 变了但归属地看着不对」的情况,换一个查询服务,或者直接看 ASN 字段再判断。

# 当前出口 IPv4
curl -4 -s https://api.ipify.org

# 当前出口 IPv6(没有输出通常说明本机没有 IPv6 出口)
curl -6 -s https://api.ipify.org

# 带归属地与 ASN 的查询
curl -s https://ipinfo.io/json

• ✅ 连接前后出口 IP 不同,归属地与所选线路地区一致
• ✅ IPv4 查询结果指向线路出口;本机没有 IPv6 时,IPv6 查询无输出
• ✅ 在同一台设备上用第二个查询服务复测,结果一致
• ❌ 界面显示已连接,出口 IP 与断开时完全相同:流量没有被接管
• ❌ 浏览器里出口变了,命令行工具查出来仍是本地地址:当前是系统代理或单应用代理模式
• ❌ IPv6 查询返回本地运营商地址:IPv6 流量绕过了隧道

第二步:检查 DNS 泄漏,确认解析也走了线路

DNS 查询发生在建立连接之前。如果解析请求发给了本地网络下发的解析器,那么即使后续流量走了隧道,你也可能拿到被就近调度或被替换的解析结果,表现为「连上了但打不开」「打开的是错误区域版本」「时快时慢」。这类情况通常被统称为 DNS 泄漏,它和线路质量无关,属于接管范围的问题。

DNS 检测结果怎么读

检测页会列出本次解析使用的解析器 IP、归属地与运营商。判断方法:解析器归属地应与线路出口一致,或至少属于同一服务商网络。如果显示的是你本地宽带或移动网络的运营商名称,那就是泄漏;如果解析器地址与出口 IP 同网段或同 ASN,属于正常。

处理方式按优先级排列:

• 在客户端里开启 DNS 接管(有的客户端叫 DNS 劫持、DNS 代理),让解析请求走隧道。
• 改用线路侧下发的解析器地址,避免继续使用路由器下发的本地地址。
• 检查浏览器是否开启了加密 DNS。它会绕过系统 DNS 设置,排查时先关掉再检测。
• 路由器侧如果启用了 IPv6,确认 IPv6 的 DNS 也被接管,否则解析可能从 IPv6 通道漏出去。

# Windows:查看系统当前使用的 DNS 服务器
ipconfig /all

# macOS:查看系统解析器配置
scutil --dns

# Linux:查看当前解析配置
cat /etc/resolv.conf

# 返回的地址就是解析器出口,可与出口 IP 对比
nslookup whoami.akamai.net

第三步:分应用、分场景对比测试

出口 IP 和 DNS 都对,仍然可能有个别应用不走线路。这一步的目标是把「哪个应用没走」定位出来,而不是笼统地归因于线路。

1. 浏览器:用无痕窗口或清一次缓存后访问目标站点,记录结果。
2. 命令行:用 curl 查出口 IP,与浏览器结果对比。命令行工具默认不读系统代理,需要显式设置 http_proxy / https_proxy 环境变量,或者依赖 TUN 接管。
3. 桌面应用:在客户端的分应用代理列表里确认该应用被标记为走线路;以 UDP 为主的软件在系统代理模式下通常不会被代理。
4. 移动端:Android 上确认 VPN 权限已授予、客户端在省电白名单里;iOS 上确认 VPN 配置处于已连接状态,没有被按需连接规则提前断开。
5. 交叉验证:在同一账号的另一台设备上复测。VPNDX 不限台数同时在线,换设备复测不需要额外操作。

按平台差异逐项确认

• Windows:排查前先看「设置 → 网络和 Internet → 代理」是否被其他软件改回了自动配置;部分应用走 WinHTTP 代理,可以用 netsh winhttp show proxy 单独确认。TUN 模式依赖虚拟网卡驱动,安全软件拦截驱动会导致接管失败。
• macOS:部分应用不读系统代理;用 scutil --dns 看系统解析器,用 networksetup -getwebproxy Wi-Fi 看当前代理项。使用网络扩展接管时需要在系统设置里授权。
• iOS:由系统 VPN 配置统一接管,通常不需要分应用设置;低电量模式会限制后台刷新,长时间切到后台后要重新唤起客户端确认状态。
• Android:分应用代理是系统级能力,可以在系统 VPN 设置或客户端内选择只让部分应用走线路;省电策略可能回收客户端进程,造成看似连接实则中断。
• Linux:创建 TUN 设备需要 root 或相应权限;命令行工具默认不读系统代理,要么配置环境变量,要么走 TUN。

六种典型「连上却没走」的情况与修法

把上面三步的结果对照下表,基本可以直接定位到原因。

什么时候必须重新验证

三步验证不是一次性动作。下面这些时点之后,接管状态可能已经变化,建议重新走一遍。

• 更换网络环境后:从家庭宽带到公司网络、从 Wi-Fi 切到移动热点,路由与代理设置都会重建。
• 切换线路或线路地区后:分流规则与解析器可能随线路变化。
• 客户端或操作系统大版本更新后:网络扩展权限、系统代理设置都可能被重置。
• 路由器重启或更换后:下发的 DNS 地址与 IPv6 前缀都会变。
• 出现「能打开但很慢」「个别站点打不开」时:先做验证,再判断是不是线路侧的问题。

把出口 IP 查询页加入书签,三步走完通常不超过两分钟。多数「线路故障」在这一步就能定性:是本地接管没生效,还是线路侧确实异常。VPNDX 提供 120+ 国家 / 220+ 线路,涵盖 IEPL 专线与中转、直连线路,不限台数同时在线,客户端覆盖 Windows、macOS、iOS、Android、Linux,使用军工级加密,注册无需邮箱地址,支持支付宝、微信与 USDT 付款,并提供 30 天无理由退款。站内线路页可以查看线路状态,与本地验证结果对照,能更快判断问题出在哪一端。