VPN 连上了却没生效，先查出口 IP，再检查 DNS，最后按应用验证。客户端的连接图标只说明某个连接环节已经建立，不能代替真实访问测试。排查的重点不是反复点连接，而是确认：这次请求从哪里出去，域名由谁解析，目标应用有没有被规则接管。
先区分连接与流量接管
日常所说的 VPN 客户端，可能使用系统 VPN 接口建立隧道，也可能主要提供本地代理。Shadowsocks、VMess、Trojan、VLESS、Hysteria2 和 TUIC 是不同的代理协议或协议方案，不能仅凭名称推断它们会自动接管整台设备的流量。实际范围还取决于客户端、运行模式和分流配置。
桌面端的“系统代理”通常只影响遵循该设置的程序。某些应用使用自己的网络设置，不会自动跟随。TUN 或虚拟网卡模式可以接管更多流量，但仍受路由、排除项与系统权限影响。安卓上的 VPN 标志说明系统已建立相关接口，不代表每个应用都没有被排除。
还有一种情况是连接建立后，实际请求没有成功完成。客户端能联系到入口，不等于出口、域名解析和目标网站都正常。IEPL 专线、中转与直连描述的是线路路径或承载方式，不是流量接管范围，也不能代替应用验证。
| 观察到的现象 | 可能的原因 | 优先检查 |
|---|---|---|
| 客户端已连接，浏览器出口未变 | 检测站被规则直连，或浏览器未使用代理 | 系统代理、浏览器扩展、检测域名命中的规则 |
| 浏览器出口改变，某个应用仍失败 | 应用被排除、保留旧连接，或服务端拒绝访问 | 分应用设置、应用重启后的表现与具体报错 |
| 域名打不开，客户端仍显示连接 | 解析失败、规则错误、出口或目标站异常 | DNS 日志、连接日志、其他目标网站 |
| 切换网络后才失效 | 本地网络限制、隧道重连失败或解析缓存残留 | 基础联网、重连状态与客户端诊断信息 |
查出口 IP：先留对照
出口 IP 是网站看到的请求来源地址，不是设备在局域网里的地址。先在断开客户端时打开可信的公网 IP 查询页面，记下地址和网络归属；再连接选定线路，使用同一浏览器重新加载同一页面。不要只看地区名称，地址本身与网络归属也要一起比较。
- 断开连接，确认普通网站可以正常访问，记录直连状态下的公网地址。若基础联网就失败，先处理本地网络。
- 连接线路，确认配置已经启用。刷新 IP 查询页面；必要时关闭旧标签页，再新建页面，避免沿用缓存结果。
- 检查客户端的连接记录，看看查询域名命中了直连还是代理规则。规则模式下，查询站直连不等于其他网站也直连。
- 在客户端支持的情况下，临时使用覆盖该测试请求的代理规则再测。完成后恢复原配置，并验证真正需要使用的应用。
若线路提供 IPv4 与 IPv6 的处理选项，要分别关注两类地址。某类请求走代理、另一类仍走本地网络时，检测结果可能不一致。客户端没有完整接管 IPv6 时，应查阅其说明选择支持的路由或限制策略，而不是盲目修改系统网络配置。
检查 DNS：看解析路径
DNS 的作用是把域名转换成地址。访问流量经过代理，不代表 DNS 查询一定经过相同路径。解析可能由系统、客户端、浏览器的安全 DNS，或应用内置的解析器发起。所谓 DNS 泄漏，通常是指本应受预期隧道或代理策略保护的查询，却经由本地网络向外发送。
先在连接状态下运行可信的 DNS 检测页面，查看它观察到的解析服务与地区，再对照客户端的 DNS 设置。检测页面看到的往往是递归解析器的出口，而不是设备到解析器的完整传输路径；因此，仅凭服务商名称，不能认定泄漏或认定已经受到保护。
发现不一致时怎么排查
- 检查客户端是否启用了 DNS 接管，以及直连域名和代理域名是否采用不同的解析策略。规则模式下，保留部分本地解析可能是配置本意。
- 检查浏览器的安全 DNS 设置。浏览器自行使用加密解析时，结果可能不同于系统；加密解析保护的是查询传输，不自动等于请求走了代理。
- 修改配置后重新建立连接，并按系统或浏览器说明清理解析缓存。旧缓存可能让测试暂时看不到新配置的效果。
- 仍有疑问时，结合客户端日志判断查询走向。分享日志前先遮盖订阅凭据、账户信息和不必要的访问记录。
不要把 DNS 配成某个公共解析器，就当作问题已经解决。解析器选在哪里、查询怎么送达、获得地址后流量走哪里，是不同的问题。也不建议直接用网站 IP 代替域名测试来下结论：HTTPS 证书、虚拟主机与内容分发机制都可能让这种访问失败，即使网络路径没有故障。
按应用验证，别只测浏览器
浏览器检测通过后，继续测试你实际使用的软件。先看它能否加载新内容，再做一次正常操作，例如打开新的页面、刷新资料或发送普通请求。已经缓存的首页和历史内容不能证明当前连接有效；登录失败也不一定是网络问题，还可能涉及账户状态、地区政策或服务端风控。
Windows 和 macOS 上，先确认应用是否遵循系统代理。应用如果支持独立代理设置，应避免同时填写相互冲突的地址。终端程序还可能读取代理环境变量，浏览器可用而命令行失败并不罕见。TUN 模式是否可用、需要哪些权限，应以当前客户端说明为准。
安卓客户端常有分应用代理或绕过名单。检查目标应用是否在接管范围内，以及后台省电限制有没有中断客户端。iOS 上则应查看当前 VPN 配置与客户端规则；如果使用了按需连接，测试时还要确认它是否真的触发，而不是只看配置已经保存。
- ✅ 检查目标应用没有被分应用规则排除，并确认它的域名没有误命中直连。
- ✅ 切换线路后完全退出并重新打开目标应用，让它建立新连接，而不是沿用旧会话。
- ✅ 分别测试浏览器与实际应用，记录各自的结果，不把浏览器通过当作全设备通过。
- ✅ 保留具体错误提示，区分超时、域名解析失败、证书错误与账户访问限制。
- ❌ 不以缓存页面能打开、连接图标亮起或某个检测站通过作为唯一依据。
仍未生效：按顺序缩小范围
排查时每次只改变一个设置。把节点、DNS、协议和分流模式一起改掉，即使恢复访问，也不知道真正的原因。建议先保留当前配置的备份，再从接管范围开始，逐步检查解析与线路。遇到权限提示，应先看清来源和用途，不要为了让图标变亮而放开所有权限。
先查配置，再查线路
打开客户端配置页，确认当前选中的是预期配置。订阅链接只是获取节点和规则的入口，不是导入成功后就会持续自动更新的保证。按照客户端支持的方式更新订阅，观察是否成功，再检查所选节点是否仍在当前配置中。若导入报错，可能是订阅格式与客户端内核不兼容，不应靠改文件后缀解决。
接着检查是否同时运行了其他代理客户端、浏览器代理扩展或网络过滤工具。它们可能争用系统代理、路由或 DNS。临时停用非必要的同类工具后重试，但不要关闭系统安全防护来碰运气。公司或学校管理的设备，应遵循管理员策略，不自行绕过管理设置。
再做交叉验证
同一设备换另一条线路后恢复，只能把范围缩小到原线路或其到目标服务的路径；同一线路换到另一网络后恢复，则更应关注本地网络限制。公共 Wi-Fi 还可能要求先完成门户认证。先断开代理完成正常联网确认，再重新连接，避免把门户未放行误判成服务故障。
什么结果可以算验证通过
实用的判断标准是：需要走线路的请求命中了预期规则，出口符合预期，DNS 行为能够解释，目标应用能完成真实操作。若你使用规则分流，国内网站保持直连并不算失败；若你希望全设备接管，就要额外检查排除项、IPv6 与不遵循系统代理的程序。
向支持人员反馈时，提供操作系统、客户端名称、当前模式、所选线路、测试时间和经过遮盖的错误信息即可。说明“浏览器出口改变，但目标应用提示连接超时”，比只说“VPN 没用”更容易定位。不要附上密码、完整订阅地址或未检查过的日志。
如果还不确定配置入口，可以先看新手指引，按所用平台核对导入与连接步骤；线路信息可在全球节点页面查看。某个网站是否可用，仍需结合地区、账户和当时的实际访问情况验证。