判断 VPN 是否真的生效，只看客户端的状态灯没有意义。状态灯说明的是代理进程在运行，而不是你正在访问的那个网站真的走了线路。可核对的结果只有三个：出口 IP 是否换到了线路所在地、DNS 解析是否跟着走了线路、以及具体应用有没有真的走代理。
下面按这三个方向拆开讲，每个方法都给出可以自己动手执行的步骤，最后附一份换线路、换设备、换网络环境后都能复用的检查清单。
方法一：先确认出口 IP 是否落在所选地区
出口 IP 是外部网站看到的来源地址。连接线路后，它应当变成线路所在地的地址；如果还是本地地址，说明流量根本没有经过线路，此时讨论速度与稳定性都没有意义。
- 断开连接，先记录当前的出口 IP 与归属地，作为对照基准。
- 在客户端里选择目标地区的线路并连接，等待客户端提示连接成功。
- 用无痕窗口重新打开检测页，避免浏览器缓存返回连接前的旧结果。
- 比对出口 IP 与归属地是否与所选线路一致，跨地区线路的归属地可能与节点城市略有偏差。
本站的网络检测页面可以直接看到出口 IP 与归属地，不需要额外安装工具。
命令行核对更适合一次性排查
浏览器之外，命令行输出没有缓存干扰，适合做一次性核对：
# 查看当前出口 IP
curl -s https://ifconfig.me
# 查看出口 IP 的归属信息
curl -s https://ipinfo.io/jsonWindows 可以在 PowerShell 里执行同样的命令。如果命令行返回的仍是本地地址，而浏览器已经变成线路所在地，说明命令行没有走系统代理，需要改用 TUN 模式或单独设置代理环境变量，这一点在方法三里还会展开。
三种常见的误判
- 归属地数据库滞后：新分配或重新划分的地址段，查询结果可能标到邻近地区，不能只凭一个库下结论。
- 缓存干扰：浏览器缓存与系统 DNS 缓存都可能返回连接前的结果，无痕窗口能排除大部分干扰。
- 多出口：同一地区可能有多个出口地址，刷新几次结果不同属于正常现象，不必反复重连。
方法二：查 DNS，确认解析没有回到本地
DNS 决定「域名被翻译成哪个地址」。如果解析请求仍然发给本地运营商，即使网页流量走了线路，解析结果也会按本地位置返回：跨境站点可能被调度到离本地更近的节点，地区限制照旧生效，查询内容也仍然暴露给本地解析器。这就是常说的 DNS 泄漏。
怎么看解析器列表
DNS 泄漏检测工具会列出实际收到查询的解析器地址与所属网络。连接线路后再测一次，按下面的口径判读：
| 测到的解析器 | 说明 | 处理 |
|---|---|---|
| 只出现线路所在地的解析器 | 解析跟着线路走，符合预期 | 无需处理 |
| 出现本地运营商的解析器 | 解析请求没有走代理，属于泄漏 | 在客户端开启远端解析，让 DNS 走代理 |
| 本地与远端解析器同时出现 | 部分请求被系统级加密 DNS 接管 | 关闭系统 DoH，交给客户端统一处理 |
| 出现公共解析器地址 | 需要确认查询是否经线路转发 | 对照出口 IP 判断，别只看解析器名称 |
命令行也能看本机当前使用的解析器：nslookup example.com 的输出里，Server 一行就是实际应答的地址。如果它是本地路由器或运营商地址，说明解析没有走线路。
系统级的加密 DNS（DoH / DoT）会绕过客户端设置的 DNS。验证前先确认操作系统或浏览器没有单独开启这类功能，否则测出来的结果与客户端里的配置并不一致。
fake-ip 与远端解析的区别
部分客户端默认使用 fake-ip 模式：本地看到的解析结果是虚拟地址，真实解析在远端完成。这种情况下，用本地命令查到的地址不代表泄漏，判断依据仍然是泄漏检测页列出的解析器，而不是本机返回的那个 IP。远端解析模式下，解析请求由线路出口发出，返回的地址也更贴近线路所在地。
方法三：分应用验证，确认具体场景真的走代理
现代客户端普遍提供分流：按域名、按地区、按应用决定哪些流量走线路、哪些直连。分流开着的时候，「已连接」只说明代理进程在运行，不代表你正在用的那个应用走了线路。
按场景逐个确认
| 场景 | 核对方式 | 常见漏点 |
|---|---|---|
| 浏览器访问国际站点 | 无痕窗口打开网络检测页看出口 IP | 浏览器装了独立代理扩展，绕过了系统代理 |
| 桌面客户端（同步盘、开发工具） | 在应用内查看网络状态或日志 | 应用自带代理设置，默认走直连 |
| 命令行工具（git、curl、包管理器） | 执行一次出口 IP 查询 | 不读系统代理，需要 TUN 或环境变量 |
| 移动端应用 | 在应用内查看账号地区或内容列表 | 应用走自有通道，没有使用系统 VPN |
不同平台的接管方式不一样
- Windows：系统代理只影响读取系统设置的程序，启用 TUN 才能覆盖命令行与其他应用。
- macOS：通过系统网络扩展接管流量，首次启用需要在系统设置里允许扩展加载。
- Android：基于系统 VPN 服务，开启后默认全局接管，分流细节由客户端内部规则决定。
- iOS：同样通过系统网络扩展工作，按提示完成配置后才会真正接管流量。
- Linux：多数客户端不自动修改系统代理，需要手动配置 TUN，或为终端单独设置代理环境变量。
命令行临时设置代理的写法如下，端口号以客户端里显示的实际值为准：
export https_proxy=http://127.0.0.1:7890
export http_proxy=http://127.0.0.1:7890
curl -s https://ifconfig.me分流规则决定了「走不走」
规则模式按域名后缀、GeoIP 地区、进程名做匹配，命中直连的域名不会经过线路。验证某个站点时，可以临时切到全局模式复测：全局下正常、规则下不生效，问题就在规则本身，而不是线路。反过来，如果全局也不通，再回到方法一和方法二排查。
判定口径：三个方法都通过才算真的生效——出口 IP 变了、解析器列表里没有本地运营商、目标应用确实走了代理。只满足其中一项，都只能说明链路的一部分通了。
几种「看着连上了其实没走」的情况
下面这些现象在排查里出现频率最高，可以先对照，再决定是改配置还是换线路。
| 现象 | 常见原因 | 处理 |
|---|---|---|
| 状态灯是绿的，页面一直转圈 | 节点不可用，或订阅已过期、流量用尽 | 换一条线路，检查订阅状态与剩余流量 |
| 网页能打开，账号地区没变 | 该域名命中直连规则，或浏览器走了扩展代理 | 切全局模式复测，关掉浏览器代理扩展 |
| 只有部分应用生效 | 应用不读系统代理 | 启用 TUN，或为应用单独设置代理 |
| 解析结果仍是本地节点 | DNS 泄漏，解析没有走线路 | 开启远端解析，关闭系统加密 DNS |
| 连上几秒后断开 | 系统时间偏差过大，握手校验失败 | 校准系统时间后重新连接 |
| 部分站点直连、部分走线路 | 只代理了 IPv4，IPv6 流量仍走本地 | 关闭 IPv6，或启用 IPv6 代理 |
时间偏差这一条最容易被忽略：VMess 一类协议对客户端与服务端的时间差敏感，偏差过大时握手直接失败，表现就是「连上了但立刻断」，看起来像线路问题，实际改系统时间就能解决。
协议与线路类型会影响判读，但不改变方法
验证方法不变，但不同协议与线路在「连不上」和「连上后不稳」上的表现不一样，知道差别可以少走弯路。
- Shadowsocks：基于 SOCKS5 的轻量代理，UDP 需要服务端单独开启中继，语音与游戏类应用不走 UDP 时会表现为「网页正常、通话不通」。
- VMess：对时间同步敏感，握手失败多半与系统时间或客户端版本有关。
- VLESS：本身不内置加密，依赖外层 TLS，配置错误时表现为能连上但无法传输。
- Trojan：以 TLS 承载，证书与域名配置不匹配时会直接握手失败。
- Hysteria2 / TUIC：基于 QUIC，全部走 UDP，网络限制 UDP 时表现为完全连不上，而不是慢。
线路类型同样影响判读：IEPL 专线的跨境段走专线，不经过公共互联网出口，晚高峰的稳定性通常更好；中转线路是境内入口加跨境段，表现取决于中转段质量；直连线路直接连海外节点，受国际出口拥塞影响最明显。三种都能正常连通，差别主要体现在高峰期与长连接场景。
一份可以反复使用的检查清单
把上面的方法压缩成清单，换线路、换设备、换网络环境后照着走一遍即可。
- ✅ 连接前后各查一次出口 IP，记录归属地的变化
- ✅ 用无痕窗口复测，排除浏览器与 DNS 缓存
- ✅ 查解析器列表，确认没有本地运营商地址
- ✅ 至少实测一个目标应用，而不是只看状态灯
- ✅ 命令行单独核对一次，必要时启用 TUN
- ✅ 记录失效时的现象，便于判断是规则、DNS 还是节点问题
- ❌ 用「能打开一个首页」当作生效证据
- ❌ 在规则模式下判断线路好坏
如果三个方法都通过、目标应用仍然不理想，问题通常在线路本身而不是配置：换一条同地区线路复测，或改用专线类线路。VPNVan 提供 100+ 国家、240+ 线路可切换，账号不限台数，无需邮箱地址即可注册，首次付费后 7 天内可申请无理由退款，用来做这类对照测试的成本很低。
最后提醒一句：订阅地址相当于账号凭据，导入客户端后不要转发给他人。地址一旦外流，别人消耗的是这个账号的流量，验证结果也会变得难以解释。
验证顺序建议固定为：出口 IP、DNS、分应用。前两步确认链路与解析，第三步确认业务真的走了代理。顺序反了，很容易在分流规则上反复绕圈。