VPN 到底生效没有，不能只看客户端的连接图标。查 IP、查 DNS、分应用确认，分别回答出口在哪里、域名由谁解析、目标软件是否走了预期路径。把连接前后的结果放在一起，再结合分流规则，才能判断配置是否符合用途。
先明确验证范围：已连接不等于全部接管
“已连接”通常表示隧道或代理连接已经建立，不代表设备上的所有请求都会经过它。浏览器扩展可能只影响浏览器；系统代理通常需要应用主动遵循；TUN 或系统 VPN 接口能接管更广的流量，但仍可能受到路由、应用排除项和协议支持范围影响。
代理客户端里的“全局”也需要看上下文：它可能只是把已进入代理内核的请求全部交给所选节点，而不是自动让所有应用进入代理。规则模式则会按域名、目标地址或进程等条件选择代理、直连或拒绝。因此，国内网站显示本地出口，未必是故障。
查出口 IP：保留连接前后的对照
出口 IP 是目标网站看到的请求来源。打开本站的IP 查询页面，先在断开代理时记录公网地址、地址类型和运营商信息；连接后重新查询。测试期间保持同一网络，不要同时切换 Wi-Fi 与其他网络，否则出口变化可能来自接入网络本身。
- 关闭其他代理扩展或重复运行的客户端，记录未连接状态下的查询结果。
- 连接目标节点，确认客户端模式与测试用途一致，再刷新查询页面。
- 查看客户端连接记录，确认查询请求命中了代理规则及预期出站。
- 断开后再次查询，观察结果是否回到原来的接入网络；必要时关闭页面后重新打开。
出口变更说明这次查询请求走了不同的网络路径，不能直接证明其他软件也被接管。地址没有变化时，也不要马上认定节点失效：查询站点可能被分流为直连，浏览器可能绕过系统代理，也可能正在使用另一种地址类型。
IP 归属地数据库存在更新差异。查询页面显示的城市与节点名称不同，不能单独作为故障证据。更有价值的是比较公网地址、网络运营商、客户端出站记录，以及目标业务能否按预期工作。
| 观察结果 | 可以说明什么 | 还需检查什么 |
|---|---|---|
| 查询页出口已改变 | 该页面请求使用了不同出口 | 目标应用与 DNS 是否同样符合规则 |
| 查询页出口未改变 | 本次请求未呈现预期出口 | 直连规则、代理入口、缓存与地址类型 |
| DNS 显示不同地区 | 解析服务与网页出口不一定在同地 | 解析服务是否来自预期配置 |
| 浏览器正常，其他应用异常 | 应用间的代理路径可能不同 | 独立代理设置、应用排除项与路由 |
查 DNS：区分解析位置与泄漏
DNS 把域名转换成可连接的地址。网页请求经过代理，不代表域名解析也一定经过代理。若预期让解析留在隧道内，实际却交给了本地网络的解析服务，就需要检查是否存在非预期的解析外发。反过来，规则明确要求本地域名使用本地解析时，这种结果不应直接算作泄漏。
使用能触发新域名查询的 DNS 检测页面，对照连接前后的解析服务列表。重点看服务提供者是否符合客户端配置，而不是要求解析服务的国家与节点完全一致。公共 DNS 的分布式部署、上游转发和检测站的识别方式，都可能影响显示结果。
浏览器安全 DNS 与系统 DNS 要分别看
浏览器的安全 DNS 可能通过 DoH 独立发起解析请求，绕开系统的解析设置；这些请求本身又可能被代理或直连。排查时先记录浏览器设置，再检查客户端是否接管该请求，不要把“启用加密 DNS”直接等同于“DNS 已进入隧道”。
下面的命令可辅助观察系统解析工具返回的服务器与结果，但不能单独证明浏览器的解析路径。不同系统可能显示本地转发地址，也可能由工具直接访问指定解析服务。
nslookup example.com如果刚调整过设置，已有 DNS 缓存可能让检测缺少新的请求。优先使用检测页面提供的新查询功能，再重启目标应用复测。清理缓存只用于消除旧结果干扰，不能代替对解析路径的核对。
分应用确认：浏览器结果不能代表全部软件
先让目标软件完全退出，再连接代理并重新打开。已有长连接可能继续沿用原路径，后台进程也可能保留连接。随后在客户端的连接面板中，观察目标域名、命中规则、出站节点和流量变化；只看总流量增长并不足以认定该软件已经被接管。
- ✅ 浏览器：检查扩展代理与系统代理是否重叠，并对照查询请求的出站记录。
- ✅ 桌面应用：查看软件是否提供独立代理选项，再核对是否被客户端排除。
- ✅ 命令行工具：检查代理环境变量及工具自己的配置，不把终端结果直接套用到浏览器。
- ✅ 游戏、会议与实时通信：分别观察登录、内容加载与媒体连接，确认 UDP 等相关流量是否受当前模式支持。
- ✅ 移动端应用：检查系统 VPN 状态、应用分流与后台限制，切换网络后重新验证。
Windows 与 macOS 上，系统代理和虚拟网络接口是不同的接管方式。Linux 的终端、桌面环境与应用可能使用各自的代理设置。iOS 与 Android 的 VPN 接口也不能替代对应用分流及客户端能力的检查。遇到差异，应依据当前系统和客户端的实际选项排查。
目标网站能打开，只能说明当前访问可用；它可能原本就能直连。相反，某个网站拒绝访问，也可能与账户地区、站点风控、服务范围或应用缓存有关，不能据此直接认定代理完全失效。
常见差异：IPv6、WebRTC 与分流规则
不同地址类型走了不同路径
设备可能同时具备 IPv4 与 IPv6 连接。若代理只覆盖其中一种，另一路径仍可能使用接入网络出口。应选择能分别检测地址类型的工具，对照客户端的 IPv6 支持与路由设置；没有检测到某类地址，也可能只是当前网络未提供该连接，不能推导出所有环境下都不会外发。
WebRTC 结果需要看地址性质
浏览器实时通信可能通过候选地址探测网络路径。检测结果里的局域网地址、经过隐藏处理的本地主机名，与接入网络的公网地址不是同一回事。若出现非预期的公网地址，应进一步核对 UDP 路由及浏览器设置，而不是看到额外地址就直接判定全部流量泄漏。
规则、订阅和连接状态并非同一层
导入订阅只是把服务提供的节点或配置交给客户端，不等于已经启用系统代理。订阅更新后，还要确认当前选中的节点、模式和规则是否符合预期。Shadowsocks、VMess、Trojan、VLESS、Hysteria2 与 TUIC 等名称描述协议方案，不能仅凭协议名称判断应用是否已被接管。
按证据排查，避免反复更换配置
保留原配置，每次只调整一个相关选项。例如先解决应用未进入代理的问题，再检查 DNS；否则同时更换节点、规则和解析服务，即使恢复，也很难知道原因。测试结束后，恢复为适合日常用途的配置。
向支持人员反馈时，说明操作系统、客户端版本、连接模式、发生问题的应用与域名，并附上已脱敏的命中规则及出口变化。准确描述“浏览器出口改变，但目标应用连接仍为直连”，比笼统说“VPN 没用”更便于定位。
判断结论：出口 IP 符合预期、DNS 路径符合配置、目标应用命中正确出站，这些证据相互对应，才足以说明所测试的使用场景已经生效。一次检测不能替代长期配置检查，切换网络、更新客户端或修改规则后，应重新验证。
VPN97 提供客户端使用教程与线路信息，可用于核对配置入口。无日志策略属于服务的隐私立场，不是设备端不发生意外直连的保证；本地路由、解析与应用设置仍需单独确认。