客户端上那个「已连接」的标记,只说明本地隧道握手成功,不说明数据真的从线路出去了。判断 VPN 是否生效,要看三个可以各自独立出错的信号:出口 IP、DNS 解析位置,以及具体应用的实际走向。三个里有两个对不上,就按没生效处理。

先分清三件事:连接状态、出口 IP 与 DNS 解析

连接状态是客户端自己的判断,它只覆盖到「隧道建立」这一步。隧道建好之后,哪些流量进隧道、域名交给谁解析、某个应用是否绕开系统设置,都由另外的配置决定。所以验证要分开做,不要用一个「能不能打开网页」的结论去覆盖全部。

三个验证信号与各自的正常、异常表现
检查项 怎么查 正常表现 异常信号
出口 IP 连接前后各查一次公网地址 地址改变,且落在所选线路的落地地区 与连接前完全一致,或落在与所选地区无关的地方
DNS 解析 查解析器的公网出口,比对解析结果 解析器出口与线路出口同地区 解析仍由本地网络完成,或结果指向本地节点
分应用走向 在目标应用内单独查一次出口 该应用出口与线路一致 只有这一个应用仍是本地出口,其余应用正常

顺序建议是:先看出口 IP,最直观;再看 DNS,最容易被忽略;最后按应用逐个确认,最容易被误判。

缓存会骗人。同一个页面第二次打开可能来自本地缓存或 CDN 边缘节点,线路已经断开也照样显示。验证时用无痕窗口,或者换一个此前没访问过的域名。

方法一:查出口 IP,确认流量从哪出去

出口 IP 是外部网站看到的来源地址。做法很简单:断开连接查一次,连上之后再查一次,两次结果不同、且新地址落在你选的地区,这一步就算通过。命令行取到的是纯文本返回值,不依赖任何客户端界面。

# macOS / Linux 终端
curl -s https://ifconfig.me/ip

# Windows PowerShell
(Invoke-RestMethod https://ifconfig.me/ip)

# 单独查 IPv6 出口
curl -s -6 https://ifconfig.me/ip

也可以在浏览器里打开查 IP 的页面,但要确认页面显示的是纯出口地址,而不是被 CDN 判断出来的城市名——后者经常和真实落地差得很远,拿来当结论容易误判。

出口 IP 和所选地区对不上,先别急着判定失败

下面三种情况属于正常,需要分开看待:

  • 中转线路:入口在近处、落地在目标地区,你看到的应当是落地地址。如果看到的是入口地址,说明这条流量被分流规则判成了直连。
  • IP 归属库滞后:广播地址段、刚调整过的地址,归属地标注可能比实际晚一段时间,换个查询来源交叉核对更稳。
  • 双栈只接管了一半:IPv4 走了线路、IPv6 仍是本地出口。浏览器和系统通常优先 IPv6,这时页面看起来「没连上」,其实是走了另一条路。

排查双栈就用上面那条带 -6 的命令,再跑一次不带 -6 的,两个结果要一起看,只看其中一个都会得出错误结论。

方法二:查 DNS 解析,确认域名在哪被解析

DNS 泄漏的意思是:流量进了隧道,域名却还是交给本地网络里的解析器去问。结果是解析按你本地位置返回,平台同时收到两套位置信号;有时表现为能连上但加载慢,有时表现为登录被要求二次验证,流媒体则直接判定地区不符。

# 查看某个域名当前解析成什么
nslookup www.wikipedia.org

# 查询解析器在公网上的出口地址(不带 @ 参数,走系统当前解析器)
dig +short TXT o-o.myaddr.l.google.com

# Windows 下同样的查询
nslookup -type=TXT o-o.myaddr.l.google.com

第二条命令返回的是递归解析器在公网上的出口地址。把它和第一步查到的出口 IP 放在一起看:两者落在同一地区,说明解析跟着线路走了;解析器仍然是本地运营商,说明 DNS 没有接管成功。

三种让 DNS 悄悄漏掉的原因

  1. 浏览器自带安全 DNS 开着。它绕过系统解析器,客户端接管 DNS 也拦不到。验证时先在浏览器设置里关掉安全 DNS,再测一次,两次结果对比就能定位。
  2. 客户端把 DNS 交给本地处理。部分客户端默认「本地解析 + 远程连接」,域名在本地就解析完了。改成由线路侧解析,再复测。
  3. 分流规则本来就把这个域名判成直连。规则模式下这是预期行为,要验证的是被判走线路的那部分域名,别拿直连域名当样本。

用 nslookup 时注意看它打印的「Server」一行,那是当前生效的解析器。如果这一行还是路由器地址或运营商地址,后面的解析结果就没有参考价值。

方法三:分应用验证,确认指定应用是否走线路

分应用代理在安卓客户端上最常见;桌面端多数是全局 TUN,想做分应用得靠路由表、独立浏览器代理或虚拟机。这一项最容易误判,因为不同客户端的勾选语义相反:有的是「只代理所选」,有的是「跳过所选」。

  1. 先确认勾选方向

    打开分应用列表,看界面写的是「仅代理所选应用」还是「跳过所选应用」。这一步弄反,后面全错,再仔细的对比也没有意义。

  2. 在被勾选的应用里查一次出口 IP

    用应用内嵌的浏览器打开查 IP 页面,记录结果,和连接前记下的基线对比。地址改变且落在所选地区,这一项通过。

  3. 在未勾选的应用或系统浏览器里再查一次

    两个结果应当不同。相同,说明分应用没有生效,流量还是统一走了一条路。

  4. 结果相同就查两处

    一是列表方向是否选反,二是这个应用是否走自己的网络栈。内置代理、私有协议、系统级下载器都可能绕开系统设置,这类情况换客户端设置解决不了。

  5. 留一份基线记录

    系统大版本更新、客户端升级之后,分应用列表可能被重置。按这份基线复测一遍,比出问题后再回头找原因省事得多。

桌面端没有分应用开关时,判断方法换一种:在同一台机器上,分别用系统浏览器和一个自带代理设置的应用去查,看两者出口是否一致。一致说明全局接管生效;不一致说明有应用绕开了隧道,需要单独为它配置代理。

看起来连上了其实没走:常见情况对照

下面这些情况在排查里出现频率最高,可以当作逐项对照表用:

  • ❌ 客户端显示已连接,但订阅链接早就过期,节点列表是旧的,连上的是已经下线的地址。
  • ❌ 系统代理模式下,只有读取系统代理设置的应用会走线路,不读这项设置的应用照旧直连。
  • ❌ 浏览器开着安全 DNS,解析绕过客户端接管,出口 IP 变了而解析仍在本地完成。
  • ❌ 只接管了 IPv4,IPv6 仍是本地出口,双栈站点优先走 IPv6,页面表现就像没连上。
  • ❌ 分应用列表方向选反,以为代理了,实际是被排除在外。
  • ❌ 分流规则把目标域名判成直连,或者规则集长时间没有更新。
  • ✅ 正确状态:断开与连接两次查到的出口 IP 不同且落在所选地区,解析器出口与线路同地区,目标应用单独查也是线路出口。

判断标准可以很硬:三个信号里有两个对不上,就当没生效处理。先回客户端查订阅状态与分流模式,再查 DNS 与双栈,最后才怀疑线路本身。顺序反了,容易在没问题的环节上反复折腾。

一次验证流程走完

把上面的方法串成一条固定流程,每次换网络、换设备、客户端大版本更新之后跑一遍,几分钟就够。

  1. 断开连接,记录基线:IPv4 出口、IPv6 出口、解析器出口,三项写下来。
  2. 连接一条线路,重复同样三项查询。
  3. 对比:出口是否改变、地区是否与所选线路一致、解析器是否跟着变。
  4. 打开目标应用,在应用内单独查一次出口。
  5. 有任何一项没变,按上一节清单逐条排查,一次只改一个设置,改完立刻复测。
  6. 换一条线路再跑一遍,排除单条线路的问题,而不是直接判定整项服务不可用。
90+ 覆盖国家与地区
210+ 线路总数
不限 同时在线设备台数
7 天 无理由退款

线路数量多,意味着复测成本低:一条线路的出口不对,换同地区的另一条再跑同样的三项查询,就能分清是线路问题还是本地配置问题。线路列表按地区分组,挑同地区的备用线路很方便。本服务不记录日志,订阅用量与流量包余量在面板里可以自己核对;7 天无理由退款期内发现问题,直接走退款流程,不必先做一堆排查。

建议把验证记录留档:日期、网络环境、线路地区、三项结果。真出问题时,这份记录比任何口头描述都有用,也能看出问题是从哪一次变更开始的。

结论:能不能打开网页不是判断标准,三个信号一致才是。出口 IP、DNS 解析位置、分应用走向,三项都对得上,才算真的生效。