客户端窗口里亮着「已接通」,不等于流量真的从国际线路出去。要确认 VPN 真的生效,得把三件事分开看:出口 IP 有没有换成节点所在地、DNS 查询由谁解析、正在用的那个应用有没有被规则覆盖。下面按这三步给出可复制的检查方法,再列出几种「连上了却没走通」的典型情况。

连上、接管、生效是三件事

很多人把这三步当成一步,于是排查时无从下手。它们其实可以互相独立:

  • 隧道建立:客户端与节点完成握手。Shadowsocks、VMess、Trojan、VLESS 一般跑在 TCP 或 WebSocket 一类传输上;Hysteria2、TUIC 基于 QUIC,底层是 UDP。握手成功只说明这条链路通了。
  • 流量接管:客户端把本机流量交给隧道。TUN 模式接管全部 IP 流量,系统代理模式只影响那些会读取代理设置的应用。
  • 出口生效:目标网站看到的来源地址是节点地址,而不是本地运营商分配的地址。

三者分离时,最容易出现的错觉就是「客户端一切正常,但打开网页仍是本地结果」。这通常不是客户端在骗人,而是接管范围或分流规则没有覆盖到你测试的那个目标。

第一步:查出口 IP

连接前后各查一次,是最直接的判断方式。浏览器打开任意 IP 查询页面可以看地址与归属地;命令行更适合做前后对比,因为输出干净、便于记录。

# 连接前:记录基线
curl -s https://api.ipify.org; echo

# 连接后:再查一次
curl -s https://api.ipify.org; echo

# 同时看出口地区
curl -s https://www.cloudflare.com/cdn-cgi/trace | grep -E '^(ip|loc)='

正常结果是两次地址不同,且第二次的归属地与所选节点一致。若两次完全相同,先检查分流规则是不是把这个查询域名判成了直连,再检查当前的接管模式是不是系统代理。

IPv6 与 WebRTC 是两个常见漏点

多数隧道默认只接管 IPv4。如果本地网络有原生 IPv6,访问支持 IPv6 的站点时会直接用本地地址出去,而 IPv4 的检查结果看起来一切正常。单独查一次 IPv6 出口:curl -6 -s https://api64.ipify.org,返回本地地址就说明 IPv6 没有被接管。

浏览器还有一条独立通道:WebRTC 可以在不经过代理的情况下拿到本机地址。用一个没装任何扩展的浏览器对比一次,或者在浏览器设置里限制 WebRTC,就能判断问题是不是出在这里。

命令行工具不读系统代理。curl 需要显式加 -x,或设置 http_proxy / https_proxy 环境变量才会走代理。所以在系统代理模式下,终端查到的地址与浏览器不同属于预期行为;切到 TUN 模式后,两者应当一致。

第二步:查 DNS 由谁解析

DNS 负责把域名换成地址。流量走了隧道、解析却仍交给本地运营商,会带来两个后果:访问意图暴露给本地解析器;解析结果按本地位置返回,拿到的是就近节点,于是「已经切到海外」的预期落空。

检查方式有三种:

  • 在线 DNS 泄漏测试页面会列出本次解析实际使用的解析器,适合快速看一眼。
  • Windows 用 nslookup example.com,macOS 与 Linux 用 dig example.com,看返回的 SERVER 段是哪一台。
  • macOS 还可以用 scutil --dns 查看系统解析器的排列顺序,判断默认走哪一个。

判断标准不是「有没有出现本地 DNS」,而是「你关心的那个域名由谁解析」。分流模式下,国内域名走本地解析、国际域名走隧道解析,本来就是设计目标;把国内域名也强行送进隧道,反而会让国内站点变慢。

分流模式里出现本地解析器不等于泄漏。真正要确认的是:访问国际站点时,那条解析请求有没有经由隧道发出。

第三步:分应用验证

同一个节点,不同应用的接管方式并不一样。把「浏览器能打开」当成全部走通,是排查里最常见的误判。

  • 浏览器通常读取系统代理设置,是最容易走通的一类。
  • 桌面应用有的读系统代理,有的只认 TUN 模式。
  • 命令行与开发工具多数不读系统代理,需要环境变量或 TUN 才能接管。
  • 移动端由系统级 VPN 配置接管,覆盖面最广,但后台省电策略可能把连接掐断。

验证方法很直接:挑同一个目标,在浏览器与终端各访问一次,对比出口地址。两边一致,说明接管范围覆盖到了命令行;只有浏览器变了,说明当前是系统代理模式,或者分流规则把终端访问的目标判成了直连。

平台之间的差异

Windows 上 TUN 模式需要安装虚拟网卡,首次连接会有权限确认;macOS 需要允许网络扩展,安装后通常要重启客户端才生效;Linux 下 TUN 需要 root 权限,或给二进制文件 CAP_NET_ADMIN 能力,否则只能用系统代理;iOS 与 Android 走系统 VPN 框架,首次连接要确认配置,客户端被后台清理后连接会断,需要重新打开。订阅导入方式也不同:桌面客户端粘贴订阅链接后手动更新一次节点列表,移动端多数通过一次点击完成导入。

三项检查对照表

把上面三步压缩成一张表,排查时按行逐项核对即可:

三项检查的判断标准
检查项 怎么查 正常结果 能说明什么
出口 IP IP 查询页面、curl 查询接口 连接后的地址与所选节点同地区 流量确实从节点出去
DNS 解析器 泄漏测试页面、nslookup 或 dig 国际域名的解析在隧道内 解析没有交给本地运营商
分应用接管 浏览器与终端各访问一次 两边出口地址一致 接管范围覆盖到该应用

常见的「假连通」

下面这些情况,客户端状态都是「已接通」,但流量并没有按预期走国际线路:

  • ❌ 分流规则把测试目标判成直连,出口地址自始至终没有变化。
  • ❌ 系统代理开着,但被测应用不读代理设置,只有浏览器走了隧道。
  • ❌ 只接管 IPv4,本地有原生 IPv6,支持 IPv6 的站点仍从本地出去。
  • ❌ 流量进了隧道,DNS 仍由本地解析器处理,解析结果按本地位置返回。
  • ❌ Hysteria2、TUIC 这类基于 QUIC 的协议,在网络限制 UDP 时表现为握手失败或频繁重连,看起来像「连上了,一会儿又断」。
  • ❌ 订阅链接过期或节点已下线,客户端还留着旧的线路名,点连接只是反复重试。
  • ✅ 出口地址变成节点所在地、国际域名的解析在隧道内、浏览器与终端结果一致,三项同时满足才算真的走通。

把流程固定下来

每次换线路、换协议、换客户端之后,按同一套顺序走一遍,比凭感觉判断可靠得多:

  1. 连接前记录一次出口地址与解析器,作为基线。
  2. 连上节点,记下所选地区与协议名称。
  3. 再查一次出口地址,对比地区是否与所选节点一致。
  4. 查一个国际域名的解析器,确认解析走隧道。
  5. 浏览器与终端各测一次,对比两边结果。
  6. 换一条线路或换一个协议复测,确认问题不是出在单条线路上。

结论:三项都通过,才算 VPN 真的生效——出口变了、解析走了隧道、被测应用被覆盖。只满足其中一项时,先查分流规则和接管模式,再怀疑线路本身。

验证之后,再确认服务侧几件事

出口地址会随所选线路变化,换线路复测的成本越低,排查就越快。VPNAJ 目前覆盖 120+ 国家、180+ 线路,量子加密,不限台数同时在线,移动端、笔记本与桌面可以各自跑一遍上面的三步;注册只需用户名与密码,无需邮箱地址。

120+ 覆盖国家与地区
180+ 可选线路
7 天 无理由退款
不限 同时在线台数

如果换了两三条线路、两种协议之后三项检查仍不通过,问题多半在本地接管方式上,而不是节点。这时先回退到 TUN 模式重测一次,再考虑重装客户端、重新导入订阅链接。

提示:验证的价值在于可重复。同一套命令、同一张对照表,今天能用,换一台机器也能用,排查就不必从零开始猜。