VPN是否生效怎么查？先比较连接前后的出口 IP，再检查 DNS 解析路径，最后逐个验证实际使用的应用。客户端显示“已连接”，通常只说明连接状态或代理核心已启动，不代表设备上每个请求都走了所选线路。
判断的重点不是“所有地址都必须改变”，而是流量是否符合自己的配置：规则模式下，本地网站直连可能是预期行为；全局代理下，未接入代理的应用仍可能直出。下面按可复现的顺序检查，避免把网站能打开、节点延迟正常或地区显示变化，当成全部生效的证据。
先明确验证对象：连接、出口与应用
订阅链接只是交付节点与配置的入口。把订阅导入客户端并更新成功，说明客户端取到了配置，不等于已经启用代理。Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC 是不同的代理协议；客户端是否支持相应协议、配置是否完整，都会影响连接，但协议名称本身不能证明流量已经经过代理。
还要区分传输线路和本机接管方式。IEPL 专线、中转与直连主要描述服务端或接入链路的组织方式；系统代理、应用内代理与 TUN 模式则决定本机哪些流量进入代理。专线不会自动接管没有配置代理的应用，TUN 模式也不能替代对实际路由和 DNS 行为的检查。
| 检查项目 | 能确认的事情 | 不能据此确认的事情 |
|---|---|---|
| 客户端连接状态 | 客户端报告连接建立或代理核心运行 | 所有应用都经过该连接 |
| 浏览器出口 IP | 这次浏览器请求对外使用的地址 | 桌面软件、游戏或后台服务的出口 |
| DNS 检测 | 检测域名查询所呈现的解析器线索 | 所有域名、所有应用的完整解析路径 |
| 客户端连接日志 | 请求命中的规则与所选出站 | 目标网站是否允许访问或账号所在地区 |
出口 IP 怎么查：保留连接前后的对照
在可信的公网 IP 查询页面查看地址与归属地即可，不需要提供账号密码或订阅链接。先断开代理，记录当前网络的出口 IP、运营商名称，以及页面是否显示 IPv6。再启用客户端、选定节点，用同一个浏览器重新访问同一个检测页面，保留两次结果。
- 建立基线。保持网络不变，暂停其他代理工具和可能接管网络的浏览器扩展，查看未连接时的公网地址。
- 确认客户端模式。记录选中的节点，以及当前使用规则、全局还是直连模式；确认系统代理或 TUN 开关确实启用。
- 刷新测试请求。重新打开检测页，必要时使用隐私窗口减少缓存干扰。隐私窗口不会自动绕过系统代理，也不等于匿名网络。
- 核对实际出站。在客户端连接日志中查找检测页面对应的域名，检查它命中的规则、策略组与最终节点。
- 交叉确认。换一个独立的查询页面再看结果。如果归属地不同，先比较 IP 是否一致，不急着认定节点失效。
如果出口 IP 改变且日志显示请求经过选定节点，可以判断这次浏览器请求已经走了代理。若地址未改变，应检查检测域名是否命中直连规则，以及浏览器是否另有代理设置；不能只凭结果相同就断言节点无法连接。
IP 归属地来自数据库，并非实时定位。不同数据库可能把同一个地址标到不同城市或地区，IP 注册信息也不一定等于服务器物理位置。流媒体与其他网站还会结合账号区域、支付资料或历史记录判断地区，因此出口改变不等于某个服务必然可用。
DNS 是否泄漏，不能只看解析器国家
DNS 负责把域名解析成地址，业务连接则负责访问目标。两者可能走不同路径，所以出口 IP 正常时仍有必要检查解析行为。这里所说的 DNS 泄漏，通常指本应受代理策略保护的查询，意外通过本地网络或非预期解析器发出；它需要结合既定配置判断，而不是看到某个国家名称就下结论。
先在未连接时运行可信的 DNS 泄漏检测，记录解析器名称与运营商；连接后再运行同类测试，同时查看客户端 DNS 设置和日志。检测站通常通过专用域名查询观察递归解析器的对外地址，不会完整展示设备到解析器之间的每一段链路。
如果连接后仍出现本地运营商解析器，且配置原本要求远程解析，这是需要排查的信号。反过来，出现海外公共解析器也不能单独证明查询经过代理：系统或浏览器可能在直连状态下就使用了它。
浏览器安全 DNS 与客户端 DNS 要一起看
浏览器的安全 DNS 通常使用 DoH，系统也可能配置加密 DNS。这能加密相应的解析传输，但不自动保证它经由代理。浏览器可能绕过系统解析设置，自行连接解析服务；该连接是否被代理，还取决于系统代理、TUN 和分流规则。
若结果不一致，先记录原设置，再暂时让浏览器使用系统解析配置，与客户端推荐的 DNS 配置配合复测。不要为了让检测页面“变绿”就随意关闭所有安全 DNS。规则模式也可能有意让本地域名本地解析、其他域名远程解析，这与意外泄漏不同。
此外，DNS 缓存会减少新查询，检测时应让页面发起新的测试请求。客户端若使用 Fake-IP，应用可能拿到用于内部映射的合成地址；这个地址不是最终出口 IP，也不能拿它的归属地判断节点位置。
分应用验证：浏览器正常不代表全部正常
Windows 与 macOS 的系统代理通常只影响遵循系统设置的应用，并不等同于把整台设备的所有流量送入隧道。有些桌面软件有独立代理设置，终端工具可能依赖环境变量，还有应用直接建立连接。TUN 模式能扩大接管范围，但仍需要检查权限、路由排除项和客户端支持情况。
Android 客户端可能提供按应用包含或排除的选项；iOS 客户端一般通过系统网络扩展处理流量，具体接管范围取决于客户端能力与配置。不要把某个平台的界面开关名称照搬到另一个平台，实际操作可先参照客户端使用教程。
- ✅ 浏览器：核对出口 IP，并确认检测域名在连接日志中的出站记录。
- ✅ 桌面应用：关闭旧连接后重新发起请求，按时间、目标域名或进程查看日志；客户端不提供进程信息时，不强行作进程级判断。
- ✅ 终端工具：检查工具是否支持系统代理或独立代理选项，再与客户端日志对照，不能把浏览器的结果直接套用。
- ✅ 移动端应用：核对按应用代理的名单与系统授权，重新打开应用后验证实际功能。
- ❌ 仅凭应用首页能显示内容判断生效：页面可能来自本地缓存，未必发生了新的网络请求。
对于没有出口查询功能的应用，可以观察它产生的新连接是否出现在客户端日志中，以及是否命中预期出站。但日志不可见并不一定代表直连：也可能是日志级别不足、连接被复用或客户端不展示该类记录。应结合应用自身的网络诊断与系统网络设置进一步核实。
显示已连接却没走线路，按什么顺序排查
先查模式与规则，再查网络接管
先确认不是直连模式，也没有把目标域名放进绕过名单。规则模式下，目标可能命中地区规则、进程规则或兜底规则，策略组还可能选中了直连。应查看最终出站，而不只是节点列表里高亮的名称。临时切换全局代理有助于定位规则问题，但它通常只改变进入代理核心的流量如何出站，不会让原本未接入的应用自动进入代理。
如果浏览器和其他应用表现不同，再查系统代理是否被其他软件覆盖、浏览器扩展是否另设出口、TUN 是否获得必要权限，以及按应用排除设置是否生效。测试期间只保留一个负责接管流量的客户端，更容易确认故障来自哪里。
再查旧连接、协议支持与网络切换
切换节点后，已经建立的长连接可能继续沿用原路径。重新打开目标应用或断开其旧连接，再产生新请求，比反复刷新状态图标更有意义。无线网络与移动数据切换后，也应重新检查连接状态及路由。
网页能用而语音、游戏或其他实时功能异常时，要单独检查 UDP 支持及相关规则，不能据此直接认定整个代理没有生效。反过来，节点延迟测试成功也只代表测试请求完成，不保证目标业务连接、认证或地区限制都没有问题。
最后核对订阅是否已更新、当前客户端是否支持订阅中的协议，以及面板是否显示正常的套餐与流量状态。不要把订阅链接粘贴到陌生转换网站排错；它可能包含访问凭据。需要协助时，通过联系支持入口提供客户端名称、系统平台、错误现象和已脱敏的日志即可。
最终结论：用相互印证的证据判断生效
出口 IP 对照确认请求去了哪里，DNS 检查确认解析是否遵循配置，分应用验证确认日常软件是否真正接入。它们相互印证，才比单看“已连接”更可靠。任何检测都只能覆盖当时、当次请求，不能推导出持续匿名或全部应用始终受保护。
日常使用不必不断切换设置。保留一次正常状态下的出口、模式与 DNS 配置记录，出现异常时先与这份基线比较，再逐项改变变量。这样既能定位问题，也能避免为修复某个应用而破坏原本正常的分流。需要理解协议和线路术语，可继续查看协议与线路参考。