怎么确认VPN真的生效了？先查出口 IP，再查 DNS，最后在目标应用里核对分流结果。连接图标只能说明系统或客户端建立了某种连接状态，不能证明所有应用、所有域名都经过预期线路。判断标准应当是：需要代理的请求走代理，需要直连的请求按规则直连。
先建立连接前后的对照
先暂停下载、同步等后台任务，记录当前网络、客户端模式和准备测试的应用。若正在远程操作设备，不要直接断开维持远程会话的连接；应先安排可恢复的操作方式。检测期间尽量保持同一网络，避免把网络切换造成的出口变化误认为代理生效。
临时断开代理后，打开可信的公网 IP 查询页面，记下地址、运营商和大致地区。重新连接客户端，再用相同页面刷新查询。地址属于个人网络信息，保存在本地即可，不必把完整结果贴到公开讨论区。
分流模式下，国内查询页面可能本来就按规则直连。因此，应选择明确需要走代理的检测目标，或临时将该目标设为代理后再比较。客户端里的“全局”通常只是把已接管的请求统一交给选定策略，不一定覆盖整台设备。
- 记录未连接时的公网出口，以及检测页面的域名。
- 确认订阅已导入、节点已选定、代理或隧道开关已开启。
- 连接后重新加载页面，核对地址变化与目标规则。
- 如需切换模式验证，记下原设置，结束后恢复。
把三个问题分开。订阅更新成功，只说明取到了配置；节点探测有响应，只说明探测请求得到了回应；目标应用请求经过预期出口，才是这次用途验证的关键。
核对出口 IP，不只看地区文字
公网 IP 查询页面看到的是访问它的请求来源。连接后地址发生变化，且客户端连接记录显示该域名命中代理策略，可以支持“这个浏览器的这次请求走了代理”的结论，但不能直接推广到其他应用。
地区文字来自 IP 数据库，可能更新滞后。节点名称也可能表示入口或线路分组，不必然等于出口所在地。遇到地区不一致，先对照其他可信查询结果和线路说明；不要仅凭城市标签判断线路失效。
| 观察结果 | 可以说明什么 | 接着检查 |
|---|---|---|
| 浏览器出口已改变 | 该检测请求的出口发生变化 | 目标应用是否也被接管 |
| 出口未变，规则为直连 | 可能是符合预期的分流 | 改测明确走代理的目标 |
| 出口未变，规则为代理 | 请求路径与预期不符 | 缓存、系统代理、隧道与绕过项 |
| 出口改变，平台地区未变 | 网络出口不是平台唯一判断条件 | 账号地区、定位权限与既有会话 |
| 不同地址族结果不同 | 网络接管范围可能不一致 | 客户端对各地址族的路由支持 |
双栈网络还需要留意 IPv4 与 IPv6。浏览器可能优先采用其中一种连接，而客户端只接管另一种。应使用能分别报告两者结果的工具，结合客户端文档核对支持范围。不要为了让检测页面“全绿”就随意关闭系统网络功能。
检查 DNS 解析路径，区分泄漏与分流
DNS 负责把域名解析成地址。DNS 检测通常会让浏览器访问测试域名，再观察向测试方查询的递归解析器。它显示的是解析器线索，不是设备上每个应用的完整解析路径，也不能直接证明所有请求的内容如何传输。
先确定预期：如果目标域名应当通过隧道解析，而查询却交给了本地网络的解析器，就值得排查；如果国内域名按规则直连并使用本地 DNS，则不一定属于泄漏。关键是实际路径是否偏离明确的配置目标。
浏览器的安全 DNS、系统加密 DNS、客户端 DNS 模块可能各自参与解析。浏览器使用加密 DNS，并不自动代表请求经过代理；加密 DNS 也可以直连。检测出现公共解析服务名称时，应结合该解析请求的路由判断，不能仅凭名称得出安全结论。
- ✅ 查看客户端是否接管 DNS，以及代理域名和直连域名分别使用什么解析策略。
- ✅ 核对浏览器安全 DNS 与系统 DNS 设置，记录差异后逐项验证。
- ✅ 改动后清理相关解析缓存或重启测试应用，再触发新的查询。
- ❌ 不要把“解析器在境外”直接等同于请求经过代理。
- ❌ 不要把检测页未发现异常理解为整台设备没有任何旁路流量。
需要定位冲突时，只改动一个设置再复测。若同时更换节点、浏览器和 DNS，就难以判断哪个改动起了作用。检测恢复预期后，把临时关闭的保护项恢复，并再做一次最终验证。
逐个应用验证，不要用浏览器代替全部
浏览器正常而其他应用不通，常见原因是接管范围不同。Windows 与 macOS 上的系统代理通常影响遵循系统代理设置的程序；忽略该设置、使用自带代理或直接建立网络连接的程序，可能走另一条路径。
TUN 等虚拟网卡方式能够接管更广的流量，但仍受路由、排除项、权限以及客户端实现影响。“全局规则”与“TUN 接管”不是同一个开关。前者决定已进入客户端的请求如何处理，后者涉及哪些流量能进入客户端。
Android 客户端可能提供分应用包含或排除名单。检查当前名单的含义：选中的是“走代理”，还是“不走代理”。iOS 的个人 VPN 配置与受管理设备的按应用 VPN 并不相同，不能假定所有客户端都有任意选择应用的能力。功能应以当前客户端和系统提供的选项为准。
在目标应用中复测实际动作
先完全退出目标应用，再重新打开并执行需要网络的动作，例如刷新内容、检索资料或加载媒体。仅看到旧页面不算验证成功，因为内容可能来自缓存。随后查看客户端是否出现对应连接、命中哪条规则、使用哪个策略组。
部分应用会连接多个域名，登录成功不代表媒体请求也成功。应分别测试登录、内容列表和实际播放。平台还可能结合账号地区、付款地区、设备定位与历史会话判断可用内容，因此应按目标平台验证，不作无条件解锁判断。
客户端的本地连接记录有助于核对规则，但可能包含访问域名；排查完成后按需要关闭临时详细记录。需要向支持提交材料时，隐藏订阅链接、凭据及不相关的访问记录。
排除“看起来连上”的常见情况
订阅导入了，配置没有启用
订阅链接是获取节点与配置的入口，不是连接本身。确认导入到了兼容客户端，配置已经启用，并选中了可用策略。订阅链接往往带有访问凭据，不应发到公开检测网站。使用 VPNPO 时，登录面板后获取订阅，客户端下载权限按面板判定。
协议受支持，接管方式却不匹配
Shadowsocks、VMess、Trojan、VLESS 等协议是否可用，取决于客户端核心和具体配置支持。协议名称本身不代表已经接管系统流量。导入失败时先核对订阅格式和核心兼容性；浏览器能用而其他应用不能用时，优先检查代理模式与分应用规则。
线路名称被当成生效证明
IEPL 专线、中转与直连描述的是线路组织方式，不能替代终端验证。中转通常经过额外入口转发，直连通常不经过该类中转入口；IEPL 标签也不能单独证明所有流量的实际承载方式。无论选哪种线路，都要核对出口、DNS 与应用请求。
浏览器扩展或其他网络工具接管了请求
浏览器代理扩展、其他 VPN 客户端和企业网络工具可能覆盖设置。先保留必要连接，按工具说明逐项排除冲突。若浏览器出口变了而客户端里没有相应连接，也要考虑浏览器正在使用另一套代理，而不是当前客户端已经生效。
检测服务也需要筛选。查询公网出口与 DNS 不需要提供订阅链接、密码或支付信息。遇到要求上传完整配置、安装不明证书才能继续的页面，应停止操作。
补查断线保护与浏览器旁路
若用途要求代理断开后停止联网，应检查客户端是否提供断线保护，并阅读它与系统“始终开启 VPN”等设置的适用边界。保存工作后，在可控环境里主动断开连接，观察目标应用是否仍能建立新的外部请求，再恢复连接复测。
浏览器 WebRTC 检测可能显示局域网地址、经过隐藏处理的主机名或公网候选地址。局域网地址出现，不等于真实公网出口已经暴露；若出现本不应直出的公网地址，则需要继续核对浏览器策略、UDP 路由和客户端接管范围。
公网出口改变也不意味着账号身份消失。登录状态、Cookie 和设备权限仍可被目标服务使用。VPNPO 的隐私立场是不记录日志，但这是一项服务策略，不能替代终端设置检查，也不能证明目标网站不会记录自身收到的访问。
结论：按请求验证，不按图标判断。先确认目标请求的出口，再核对 DNS 路径，最后逐个应用检查规则。结果一致时，可以确认本次测试范围内的代理行为符合预期；更换网络、客户端配置或规则后，应重新验证相关用途。
仍无法定位时，整理系统与客户端名称、所用模式、异常应用、命中规则和脱敏后的检测差异，前往排查手册继续检查，或通过支持页面提交问题。描述“哪个请求没有按预期走”，通常比只写“已经连接但不能用”更容易缩小范围。