VPN 连上了但没生效，通常不是状态图标本身出了问题，而是“隧道建立”“路由接管”和“具体应用走线路”被混为一谈。客户端显示已连接，只能说明它与某个节点完成了通信；网页、DNS 请求和其他应用是否经过该节点，还要分别核验。
最可靠的判断方法不是反复看客户端颜色，也不是只打开一个网站试速度，而是保留连接前的基准，再依次检查出口 IP、DNS 解析走向和应用流量。三项结果彼此印证，才能区分线路故障、分流规则、浏览器设置与系统网络缓存。
连接状态为什么不等于流量生效
大多数客户端把“连接成功”定义为本机已经与节点建立可用会话。这个会话可能采用 Shadowsocks、VMess、Trojan、VLESS、Hysteria2 或 TUIC 等协议，也可能由系统提供的 VPN 网络扩展承载。协议握手成功后，客户端还要写入系统路由、启用虚拟网卡或开放本地代理端口，应用流量才有机会进入线路。
如果客户端使用全局模式，通常会尝试接管更广泛的流量；如果使用规则模式，则由域名、IP、进程或应用规则决定直连与代理。浏览器还可能单独配置代理，某些应用也会使用自己的网络栈。于是会出现客户端已连接、一个网页可访问，但另一个应用仍然直连的情况。
| 检查对象 | 能证明什么 | 不能单独证明什么 |
|---|---|---|
| 客户端连接状态 | 本机与所选节点能够建立会话 | 所有应用都已进入线路 |
| 出口 IP | 当前测试请求从哪个公网出口离开 | 其他应用与 DNS 请求采用相同路径 |
| DNS 检测 | 域名解析请求由哪一侧处理 | 网页内容流量一定经过线路 |
| 应用内验证 | 指定应用能否命中当前规则 | 系统中的所有进程都采用同一规则 |
第一步：核对出口 IP
出口 IP 是最直观的第一项证据。断开线路时，检测页面通常看到本地接入网络提供的公网出口；连接后，如果测试请求经过所选节点，页面应显示线路出口，而不是原来的接入网络出口。重点是比较连接前后是否变化，以及显示地区是否与所选线路大致一致。
- 完全断开客户端，打开网络检测页，记下出口地区与网络提供方信息。
- 连接目标线路，等待客户端状态稳定，再刷新检测页。
- 关闭检测页后重新打开，或使用新的浏览器会话复核，避免旧页面缓存干扰。
- 再用目标应用访问其自带的网络诊断或地区信息，确认应用结果与浏览器结果一致。
出口地区与节点名称不必精确到同一城市。IP 数据库的地理信息可能更新滞后，线路也可能在邻近地区完成最终出站。因此，判断重点是原出口是否已被替换、国家或区域是否合理，而不是把城市字段当成物理机房定位。
如果出口完全没有变化，先确认客户端模式。仅代理模式通常只接管明确使用本地代理端口的应用；虚拟网卡模式或系统 VPN 模式则能覆盖更多程序。还要检查浏览器是否启用了独立代理、系统是否残留旧代理地址，以及规则中是否把检测域名设为直连。
- ✅ 连接前后使用同一网络环境，结果具备可比性。
- ✅ 新出口与所选线路区域基本一致，原接入网络出口不再出现。
- ✅ 浏览器与目标应用得到相符的出口判断。
- ❌ 只看客户端节点名称，没有实际查询公网出口。
- ❌ 切换了本地网络后直接比较，把接入网络变化误认为线路生效。
第二步：检查DNS 解析走向
访问域名之前，设备通常要先把域名解析为可连接的地址。网页内容经过线路，不代表 DNS 请求也自动采用相同路径。如果解析仍由本地网络处理，就可能出现 DNS 走向与内容出口不一致；在需要按域名分流的场景中，还可能导致规则判断异常。
检测时要同时看“谁在解析”和“当前客户端如何设计 DNS”。如果客户端明确使用远端 DNS、加密 DNS 或由线路端处理解析，检测结果应与该设计一致。若浏览器启用了自己的安全 DNS，它可能绕过系统 DNS，但这不一定等同于泄漏：关键在于它是否符合你的预期、是否暴露给不希望参与解析的一方。
因此，不能简单地把“DNS 提供方名称与线路品牌不同”判定为泄漏。公共解析服务、浏览器内置解析和客户端指定解析都可能显示为独立提供方。真正需要处理的是：连接前后的 DNS 完全相同、解析仍明确落在本地接入网络，且客户端配置原本要求远端解析。
DNS 结果异常时怎么处理
- ✅ 查看客户端是否提供远端解析、代理 DNS 或防泄漏选项，并确认其已按预期启用。
- ✅ 检查浏览器是否启用独立安全 DNS，避免它与系统策略互相覆盖。
- ✅ 重新连接线路后再发起全新的域名查询，不复用已经打开的页面。
- ✅ 规则模式下确认 DNS 请求本身也有对应规则，而不只是网页域名有规则。
- ❌ 只凭解析服务名称陌生，就直接认定全部流量泄漏。
第三步：按应用验证分流规则
浏览器验证通过后，还要检查真正需要使用线路的应用。桌面客户端、游戏平台、命令行工具和系统服务可能各自采用不同网络路径。规则模式又可能按照域名、目标地址、应用进程或规则集合分配流量，所以“浏览器生效”不能代表“整台设备生效”。
可执行的做法是逐个关闭目标应用，连接线路后重新启动，再观察应用内地区、连接日志或客户端的连接记录。如果客户端能显示命中规则，重点查看该应用请求最终落在代理、直连还是拒绝项。不要只看流量计数增加，因为后台更新、连通性检测与 DNS 请求也会产生流量。
分应用代理还要注意系统差异。Windows 与 macOS 上，虚拟网卡模式通常比单独设置系统代理覆盖面更广，但部分程序可能绕过系统代理。Android 的 VPN 接口可以按应用纳入或排除；如果目标应用被排除，它会继续使用本地网络。Apple 平台上的网络扩展由系统管理，切换配置后应重新打开目标应用，让已有连接重新建立。
- 退出目标应用，避免复用连接前建立的长连接。
- 连接线路并确认出口 IP 已变化。
- 重新启动目标应用，执行一次明确需要联网的操作。
- 查看客户端连接记录或规则命中结果，确认目标请求不是直连。
- 切回断开状态复查差异，排除应用缓存与账号地区设置的影响。
流媒体、商店和内容平台还会综合账号地区、缓存、定位授权与支付资料等信息。即使出口已经变化，页面内容也可能暂时不变。这种情况不能直接证明 VPN 未生效，应先用网络层证据确认出口和 DNS，再单独处理应用缓存或账号侧地区逻辑。
订阅链接与协议配置怎么核验
订阅链接的作用是向客户端提供节点与规则配置。导入成功只表示客户端读到了配置，不表示每个节点都可连接，也不表示系统流量已被接管。订阅更新后如果节点名称变化、旧节点失效或规则集未刷新，客户端仍可能保留看似正常的旧配置。
遇到异常时，可以先更新订阅，再确认当前选中的节点确实来自最新配置。随后检查协议参数是否完整。Shadowsocks 依赖加密方式与连接参数匹配；VMess、Trojan 与 VLESS 常与传输层、TLS 和域名设置配合；Hysteria2 与 TUIC 基于不同的传输设计，也需要客户端版本支持相应协议。不要把一种协议的字段手动套到另一种协议上。
协议只负责建立通信方式，线路类型则描述流量如何到达出口。直连通常由设备直接连接远端节点；中转会先进入中间接入点，再转发到最终出口；IEPL 专线用于承载特定区段的国际传输。无论采用哪种路径，最终是否生效仍应回到出口 IP、DNS 和应用命中结果，而不能根据线路名称推断。
常见的“已连接但没走线路”情况
检测网站被规则设为直连
某些规则集合会把本地服务、局域网地址或特定检测域名设为直连。此时客户端工作正常，但检测页面故意绕开线路。可以临时切换全局模式复查；如果全局模式下出口变化，问题通常在规则而不是节点。
应用复用了旧连接
浏览器标签页、下载工具和即时通信应用可能保持长连接。线路切换后，旧会话不会立刻按新路由重建。完全退出应用再打开，比仅刷新页面更能反映当前路径。
系统代理与虚拟网卡互相覆盖
设备上同时运行多个网络工具时，后写入的代理、路由或 DNS 设置可能覆盖先前配置。排查时应只保留一个负责接管流量的客户端，确认结果后再逐项恢复其他网络工具。
规则只覆盖域名，没有覆盖直接连接的地址
部分应用不会重复查询域名，而是直接连接缓存中的地址。若规则仅按域名匹配，这类请求可能落入默认直连。检查规则日志可以确认请求是否命中预期项，再决定是否补充地址规则或调整默认策略。
浏览器与系统采用不同代理
浏览器扩展、本地代理设置和系统 VPN 可以同时存在。检测网页可能走浏览器扩展，其他应用则仍然直连；反过来也可能发生。验证时应明确当前由哪一层接管，不要把多层代理叠加后的结果当作单一客户端表现。
完整复查清单
如果前面的检查结果互相矛盾，可以按下面的顺序从网络层向应用层收敛问题。每次只修改一项，并在修改后重新测试，这样才能知道哪项设置真正影响了结果。
- ✅ 断开线路，保存出口 IP 与 DNS 基准结果。
- ✅ 更新订阅，确认节点、协议与客户端版本能够配合。
- ✅ 连接线路，复查出口是否替换为合理的线路出口。
- ✅ 核对 DNS 是否符合远端解析或既定安全 DNS 方案。
- ✅ 退出并重启目标应用，检查实际规则命中结果。
- ✅ 临时切换全局模式，用于区分节点问题与分流规则问题。
- ✅ 排除同时运行的其他代理、网络扩展和旧系统代理配置。
- ❌ 只凭客户端显示“已连接”就停止验证。
- ❌ 同时修改协议、DNS、节点和规则，导致无法定位变量。
完成核验后，可以保存当前有效的节点、模式与 DNS 组合。以后遇到访问异常，先用同一套方法区分“线路未建立”“路由未接管”和“应用规则未命中”，再决定是切换节点、更新订阅还是调整分流。隐私策略则应单独查看服务说明；需要此类立场时，选择明确标注匿名无日志的服务，并根据自身网络环境持续验证实际连接结果。