怎么确认 VPN 真的生效：出口 IP、DNS 与 分应用 三步验证
连上了不等于走对了：查出口 IP、查 DNS、分应用验证三步走，并列出「看起来连上其实没走」的几种常见情况。
客户端状态灯亮着，网页打开却还是原来的样子——这是「怎么确认 VPN 真的生效」最常见的提问。答案不是再看一眼连接状态，而是按三个层面依次核对：出口地址有没有真的换掉、域名解析有没有跟着隧道走、正在使用的那个应用有没有被纳入代理。三步都过，才算走对了；只过第一步就收工，漏掉的往往正是后面两层。
为什么「已连接」不等于生效
状态灯只说明一件事：本地到节点这一段的隧道已经建立。它不说明流量有没有被接管，不说明接管之后走了哪条规则，也不说明域名解析跟着走了没有。这三件事分别由客户端的接管模式、分流规则和 DNS 设置决定，任何一环出偏差，表现都是「显示已连接，实际没走」。
接管方式常见三种。系统代理只对读取系统代理设置的程序生效，浏览器通常读，很多桌面客户端不读；TUN 虚拟网卡在网络层接管 IP 流量，覆盖面最广；分应用代理只把名单里的应用送进隧道，名单外的应用照旧直连。判断「是否生效」的方法，取决于当前用的是哪一种。
协议是另一层。Shadowsocks、VMess、VLESS、Trojan 负责把流量封装后送到节点，Hysteria2、TUIC 基于 QUIC、以 UDP 承载，弱网环境下更稳。协议决定的是「怎么送」，不决定「哪些流量被送」，所以换协议修不好分流误判，只能改善链路质量。
订阅链接只是节点清单的载体。客户端导入订阅后按链接里的节点列表生成配置；订阅过期或链接失效，节点列表不再更新，但本地已保存的节点仍可能握手成功。这类情况下状态灯同样会亮，实际却转发不出去。
第一步：核对出口 IP 与 归属地
先记录基线。连接之前，在浏览器打开任意地址查询页，或在终端执行一条命令，把当前的出口地址与归属地记下来。
# 连接前：记录出口地址与归属地
curl -s https://ipinfo.io/json
# 连接后：ip 与 country 两项都应当变化
curl -s https://ipinfo.io/json连上节点之后，换一个无痕窗口再查一次。用无痕窗口是为了排除缓存与浏览器扩展的干扰——有些代理类扩展会自行接管请求，让结果看起来与客户端无关。
判断标准只有两条：地址变了；归属地与所选节点所在地区一致。两条同时满足，才说明流量确实从境外出口出去。
有几种情况需要区别对待。公开的地址归属库之间存在差异，任播地址与跨国广播地址可能显示为邻近地区，这不算异常；流媒体平台用的是自己的判定库，不以公开库为准，所以「地址归属正确、平台仍按本地展示」是可能出现的结果。反过来，地址没变也不一定是故障：分流模式下访问境内站点本来就该走本地出口，需要测的是境外站点那一次请求。
分流模式下访问境内站点显示本地地址是设计如此。测出口地址时，务必用一个确定会走代理的境外站点，或临时切到全局模式再测一次做对比。
第二步：确认域名解析没有落回本地
DNS 泄漏指的是：流量进了隧道，域名解析请求却没有跟着进去，而是发给了本地运营商。后果有两层——访问清单暴露给本地解析方，以及解析结果按本地位置返回，于是出现「出口地址是境外的，拿到的内容还是本地的」。
验证方法并不复杂：打开一个 DNS 泄漏检测页，它会列出实际应答的解析服务器及其归属。正常表现是应答服务器位于出口地区，或属于服务商下发的 DNS；异常表现是应答服务器为本地运营商。检测时同样用无痕窗口，避免浏览器缓存的解析结果干扰判断。
分流模式下有一个例外：境内域名走本地 DNS 是设计如此，不算泄漏。要看的是境外域名那一部分的应答服务器。
浏览器自带的安全 DNS（DoH）会绕过系统与客户端的 DNS 设置，直接向第三方解析服务器发查询，这是「IP 对了、内容还是本地」的高频原因。检测前先在浏览器设置里确认「使用安全 DNS」的状态，关闭后再测一次做对比。
IPv6 是同一类问题的另一面。隧道只接管 IPv4 时，支持 IPv6 的站点会从本地 IPv6 出口出去，检测页返回的就是本地地址。处理方式有两种：在系统里关闭 IPv6，或让客户端接管 IPv6 流量。
第三步：分应用与分流规则逐个确认
第三层最容易被跳过，因为它不在客户端主界面上。分应用代理的逻辑是「只代理名单里的应用」：名单外的应用即使隧道已经建立，流量依旧直连。核对方式是打开客户端的分应用列表，逐个确认要用的应用在不在里面，改完名单后重启目标应用——多数程序只在启动时读取一次代理配置。
平台之间的差异
桌面端常见系统代理与 TUN 两种模式，TUN 覆盖所有程序，系统代理只覆盖读取系统设置的程序；Android 客户端普遍提供按应用代理；iOS 受系统限制，通常以整条隧道的方式工作，没有同等的按应用开关；Linux 上多为命令行与系统代理，需要手动设置 http_proxy、https_proxy 环境变量，或改用 TUN 模式。同一份订阅在不同平台上表现不一致，多数时候是这一层造成的。
分流规则怎么影响判断
规则通常按域名后缀、GeoIP 地区、进程名匹配，命中直连的域名不会进隧道。判断方法很直接：把客户端临时切到全局模式，再访问同一个站点。切全局后正常、切回分流又不正常，问题就在规则，而不是节点。线路类型（IEPL 专线、中转、直连）影响的是链路稳定性与绕行路径，不会改变「哪些流量被代理」，排查时不要把两者混在一起。
| 层面 | 怎么查 | 正常表现 | 异常信号 |
|---|---|---|---|
| 出口地址 | 连接前后各查一次地址与归属地 | 地址改变，归属地与节点地区一致 | 地址未变，或归属地与节点不符 |
| 域名解析 | DNS 泄漏检测页 | 应答服务器在出口地区，或为服务商下发 | 应答服务器是本地运营商 |
| 分流规则 | 切全局模式，对比同一站点 | 全局与分流结果一致 | 只有全局模式正常 |
| 分应用 | 客户端的分应用列表逐个核对 | 目标应用在代理名单内 | 应用不在名单，实际走直连 |
| IPv6 | 支持 IPv6 的检测页 | 与 IPv4 出口一致，或不返回 | 返回本地 IPv6 地址 |
七种 常见情况：状态正常却没走隧道
下面这些情况，状态灯都是正常的，实际却没有按预期走。按现象对照排查，比反复重连有效。
| 现象 | 常见原因 | 处理 |
|---|---|---|
| 状态已连接，浏览器仍显示本地地址 | 客户端处于系统代理模式而该程序不读系统代理；或域名命中直连规则 | 改用 TUN 模式，或把域名加入代理规则后重测 |
| 出口地址正确，部分站点仍按本地展示 | 浏览器安全 DNS 绕过客户端 | 关闭浏览器安全 DNS 后重测 |
| 只有某个应用不走隧道 | 该应用不在分应用名单里 | 勾选后重启应用再试 |
| 检测页返回本地 IPv6 地址 | 隧道只接管 IPv4 | 关闭系统 IPv6，或让客户端接管 IPv6 |
| 换节点后仍打不开，过一会又正常 | DNS 缓存与连接复用 | 用无痕窗口或清缓存后重测 |
| 所有境外站点都打不开 | 订阅过期、流量用尽或节点故障 | 查看订阅状态，换节点或换线路类型复测 |
| 连接时提示证书或时间错误 | 系统时间偏差过大，握手阶段就失败 | 同步系统时间后重新连接 |
一次完整的 自查清单
把上面三层合成一份可以照着做的清单。每次换节点、换设备、换网络之后走一遍，通常两三分钟。
- ✅ 连接前记录一次本机出口地址与归属地，作为对照基线。
- ✅ 连接后用无痕窗口复查出口地址，排除缓存与扩展干扰。
- ✅ 用 DNS 泄漏检测确认应答服务器不在本地运营商。
- ✅ 明确当前是全局还是分流模式，知道目标域名走哪条规则。
- ✅ 在分应用列表里逐个核对要用的应用，改完重启应用。
- ✅ 关闭或统一浏览器自带的安全 DNS，避免绕过客户端。
- ✅ 检查订阅有效期与剩余流量，确认节点列表是最新的。
- ✅ 同步系统时间，避免在握手阶段就失败。
- ❌ 只看客户端状态灯就认定已经生效。
- ❌ 用同一个标签页反复刷新来判断结果。
- ❌ 用延迟或带宽数字判断出口是否正确，两者不是一回事。
把三步固定成习惯
三步的顺序不能颠倒：先确认出口地址变了，再确认解析跟着走，最后确认正在用的应用在代理范围内。顺序颠倒的代价是误判——只看了第一步就认为一切正常，后面两层的偏差会被带进日常使用，表现成「有时候能打开、有时候不能」。
结论：出口地址、域名解析、分应用与分流，三层都通过才算真的生效。任何一层异常，先用全局模式做一次对照测试，就能把问题定位到规则、DNS 还是应用本身，而不是在节点之间反复切换。
本服务目前提供 90+ 国家 / 160+ 线路，客户端覆盖 Windows、macOS、iOS、Android、Linux，不限台数，不记录日志，7 天无理由退款；注册只需用户名与密码，无需邮箱地址。换节点之后按上面的三步复测一遍，比凭感觉判断更省时间。