判断 VPN 是否生效，不能只看客户端里的“已连接”。这个状态通常只表示本地客户端与远端节点完成了握手，未必意味着浏览器、命令行工具和其他应用的流量都经过该线路。可靠的检查应同时观察出口 IP、DNS 解析路径、路由模式和具体应用的访问结果。
最实用的顺序是：先记录连接前的网络特征，再建立连接并检查出口 IP，随后验证 DNS，最后逐个测试容易绕过代理的应用。这样能够把问题缩小到节点、系统代理、虚拟网络接口、分流规则或应用自身设置，而不是反复更换线路碰运气。
先理解“已连接”到底代表什么
客户端建立连接时，会先解析节点地址，再与服务器协商协议、加密和认证信息。使用 Shadowsocks、VMess、Trojan 或 VLESS 等连接方式时，只要握手成功，客户端通常就会显示已连接。但此时流量如何进入连接通道，仍取决于客户端采用的接管方式。
常见接管方式包括系统代理和虚拟网络接口。系统代理会修改操作系统提供给应用的代理设置，愿意遵循该设置的浏览器与桌面应用通常能够进入线路；不读取系统代理的程序则可能继续直连。虚拟网络接口会在系统路由层接收更多流量，覆盖范围通常更广，但仍可能受到排除规则、本地网络路由和应用自带网络栈的影响。
| 观察到的状态 | 可以说明什么 | 仍不能说明什么 |
|---|---|---|
| 节点握手成功 | 客户端能够连接远端服务 | 所有应用都已进入线路 |
| 系统代理已开启 | 系统代理配置已经写入 | 应用一定遵循系统代理 |
| 虚拟网络接口已启用 | 客户端可以在路由层接管流量 | 分流规则没有把目标排除 |
| 网页可以打开 | 当前网页请求能够完成 | DNS 与其他应用使用相同路径 |
IEPL 专线、中转线路与直连线路描述的是节点到目标网络之间的传输组织方式。IEPL 通常用于更稳定的跨境传输，中转会先把流量送到中继入口，直连则由本地网络直接连接远端节点。这些差异会影响连接质量，但不会改变验证方法：最终仍要查看出口、DNS 和应用请求实际走向。
出口 IP 验证：确认网页流量去了哪里
出口 IP 是第一项检查，因为它直接反映测试请求从哪个网络出口访问外部服务。测试前应先断开客户端，打开一个能够显示公网出口信息的查询页面，记录运营商、地区和网络组织等结果。随后连接目标线路，关闭原有查询标签页并重新打开，再比较两次结果。
- 断开连接，记录当前出口地区与网络组织。
- 完全关闭用于查询的页面，避免页面缓存旧结果。
- 连接目标节点，确认客户端没有持续重连或报错。
- 重新打开查询页面，对比出口地区和网络组织是否改变。
- 换一个浏览器或命令行请求重复检查，观察结果是否一致。
如果连接后出口信息变为所选线路对应的地区，说明当前测试工具的请求已经经过线路。如果结果完全没有变化，则优先检查系统代理是否写入、虚拟网络接口是否启用，以及当前分流模式是否把查询站点判定为直连。
出口发生变化也不代表所有流量都已接管。浏览器可能使用系统代理，而终端工具、游戏平台或同步程序可能直连。因此，出口 IP 验证更适合回答“这个请求是否经过线路”，不能单独证明整台设备上的全部连接都采用相同路径。
浏览器还可能保留旧连接。即使线路已经切换，原有标签页中的长连接仍可能暂时沿用此前建立的会话。检查时应新建标签页，必要时彻底退出浏览器后重开。使用隐私浏览窗口也有助于减少扩展、缓存和持久连接对结果的干扰，但它不会自动改变系统路由。
DNS 验证：域名解析是否绕开连接
访问网站通常先进行 DNS 查询，把域名转换为可连接的地址。网页内容经过国际线路，并不必然意味着 DNS 查询也走同一路径。如果 DNS 请求仍交给本地网络处理，就可能出现解析结果与出口地区不一致、特定域名解析失败，或连接界面正常但网站持续超时的情况。
检查 DNS 时，应关注解析服务所属网络和地区，而不是只看页面是否标出“泄漏”。不同检测页面采用的判断标准并不完全相同。更稳妥的方法是比较连接前后的解析结果：连接后若仍只显示本地网络默认的解析服务，同时出口已经改变，就需要检查客户端的 DNS 接管设置。
- 确认客户端是否启用了远程 DNS 或加密 DNS。
- 确认分流规则是否让 DNS 请求绕过了虚拟网络接口。
- 检查浏览器是否启用了独立的安全 DNS，并使用了另一套解析服务。
- 检查系统中是否保留手动填写的固定 DNS 配置。
- 切换线路后清理系统和浏览器的 DNS 缓存，再重新测试。
所谓 DNS 泄漏，通常指预期由连接通道处理的解析请求，实际被发送给了本地网络或其他非预期解析服务。它不一定导致网页无法打开，但会造成出口路径与解析路径不一致。对依赖地区解析的内容服务而言，这种不一致还可能返回不适合当前出口的地址。
浏览器的安全 DNS 是常见干扰项。它可能绕过操作系统的默认解析设置，直接连接浏览器指定的解析服务。若只有某个浏览器的 DNS 检测结果异常，而其他应用正常，应先检查浏览器自身设置；若所有应用都出现相同结果，再检查客户端和系统层的 DNS 接管。
分应用验证：找出哪些程序没有经过线路
分应用验证用于处理一种常见情况：浏览器测试正常，但命令行、下载工具、游戏启动器或桌面客户端仍然使用原网络。原因通常不是节点失效，而是不同应用读取代理设置的方式不同。
先选择一个已经通过出口 IP 验证的浏览器作为基准，再依次打开其他应用，观察相同目标能否访问、显示的地区是否一致，以及客户端连接日志中是否出现对应请求。每次只测试一个应用，避免多个后台请求混在一起，使日志难以判断。
| 应用类型 | 常见接管方式 | 容易出现的问题 |
|---|---|---|
| 常规浏览器 | 系统代理或浏览器代理 | 扩展覆盖代理设置，安全 DNS 独立解析 |
| 命令行工具 | 环境变量、显式代理或虚拟网络接口 | 默认忽略系统代理，继续直接连接 |
| 桌面应用 | 系统代理、应用内代理或虚拟网络接口 | 应用自带网络配置覆盖系统设置 |
| 游戏平台与实时通信 | 虚拟网络接口或专用转发规则 | 部分数据报流量未被系统代理接管 |
如果客户端提供全局、规则和直连等模式，可暂时切换到覆盖范围更大的模式进行对照测试。若应用在扩大接管范围后恢复正常，说明节点本身可用，问题更可能位于分流规则。此时不应长期依赖盲目全局转发，而应检查目标域名、地址段和应用进程是否被错误归入直连。
分流规则通常按照域名、目标地址、地理数据库、应用进程或协议类型决定路径。规则顺序也很重要：前面的宽泛直连规则可能提前命中，使后面的代理规则没有机会执行。修改后应重新启动相关应用，因为已经建立的连接不会自动迁移到新路径。
订阅链接只负责向客户端提供节点与配置更新，不等同于系统流量已经被接管。导入订阅后，还需要选择节点、启用连接并确定代理模式。订阅更新成功但出口不变，通常应检查本地接管设置，而不是反复重新导入订阅。
客户端显示已连接但没有流量的排查顺序
遇到“已连接但无法访问”时，从本地到远端依次检查，通常比随机更换协议有效。先确认设备本身能够正常联网，再观察客户端是否持续重连。若基础网络不可用，客户端界面可能保留上一次状态，但不会产生有效转发。
- 确认基础连接：断开客户端后访问普通网站，排除当前网络本身中断。
- 重新选择节点：刷新订阅并选择另一条可用线路，排除单个节点配置过期。
- 检查时间：系统时间偏差可能使证书校验或认证过程失败，应启用系统自动校时。
- 检查接管模式：系统代理适合遵循代理设置的应用，覆盖更广时可测试虚拟网络接口。
- 检查分流：暂时扩大接管范围，判断目标是否被误判为直连。
- 检查 DNS：更换为客户端提供的远程解析方式，并清理旧缓存。
- 检查冲突：退出其他会修改代理、路由或过滤网络请求的程序后重试。
协议切换应放在基础检查之后。Shadowsocks 主要提供加密代理传输；VMess 和 VLESS 常用于由客户端按规则转发连接；Trojan 将认证与加密传输结合，并常配合传输层安全配置。不同协议需要客户端与服务端配置匹配，不能只更改客户端协议名称而保留不兼容的端口、传输方式或认证信息。
连接日志也能帮助定位阶段。域名解析失败通常指向 DNS 或基础网络；连接远端超时可能与节点不可达、路由质量或本地网络限制有关；认证失败更可能是订阅内容过期或配置不匹配；握手成功但没有应用请求，则应回到系统代理、虚拟网络接口和分流规则。
排查时应避免同时修改节点、协议、DNS 和分流。一次改变一项，随后重复出口与 DNS 检查，才能知道是哪项设置产生了影响。若同时改动多处，即使暂时恢复，也很难形成可复用的配置。
Windows、macOS、iOS 与 Android 的验证差异
Windows 桌面程序对系统代理的支持并不统一。浏览器通常会读取系统设置，但部分命令行程序和自带网络组件的应用需要显式代理参数，或者依赖虚拟网络接口。发现浏览器出口已变化而终端没有变化时，应优先检查这一差异。
macOS 同样提供系统代理，但应用可以选择自己的网络实现。启用虚拟网络接口后，需要留意系统是否弹出网络扩展授权，以及客户端扩展是否仍处于启用状态。系统更新或客户端重新安装后，相关授权可能需要重新确认。
iOS 上的客户端通常通过系统提供的 VPN 配置接管流量。状态栏图示只能说明系统配置处于连接状态，仍建议使用浏览器检查出口与 DNS。若某个应用结果不同，应确认客户端是否启用了按需连接、分应用规则或排除本地网络等选项。
Android 客户端通常依赖系统 VPN 权限建立虚拟接口。系统的始终开启设置、允许绕过设置、省电策略和后台限制都可能影响持续连接。若切换到后台后线路中断，应检查系统是否限制了客户端运行，而不是直接判断远端节点故障。
各平台的客户端界面不同，但验证逻辑一致：先确认握手，再确认出口，随后检查 DNS，最后按应用验证。平台差异主要体现在流量如何进入线路，不在于检测标准本身。
怎样判断检查已经完成
完整验证不要求所有应用显示完全相同的界面，而要求路径结果与预期一致。用于国际访问的应用应显示所选线路对应的出口；计划直连的本地服务应继续使用本地路径；DNS 解析不应意外落到与配置冲突的服务；切换线路后，新建立的连接应采用新的出口。
- 连接前后的出口信息存在明确变化。
- 出口地区与当前选择的线路相符。
- DNS 解析路径符合客户端配置。
- 浏览器、终端和目标应用分别完成验证。
- 分流规则能够解释哪些请求直连、哪些请求进入线路。
- 切换节点后关闭旧连接，重新测试仍能得到一致结果。
如果出口、DNS 与目标应用都符合预期，就可以确认连接已经实际生效。若只有其中一项异常，应针对对应层级处理：出口不变检查接管方式，DNS 异常检查解析设置，单个应用异常检查应用代理与分流规则。把连接状态拆成这些独立环节，通常比只盯着客户端按钮更容易找到原因。