VPN 连上了怎么确认真的生效？不要只看客户端的连接图标。先对比连接前后的出口 IP，再检查 DNS 解析路径，最后逐个验证需要使用的应用。判断标准不是“所有流量都改变”，而是“应该经过线路的请求，确实按预期经过线路”。
这套方法适用于系统自带的 VPN 连接，也适用于通过订阅链接导入节点的代理客户端。两者的接管范围可能不同：客户端能连接到节点，只能说明连接环节有进展，不能代替对浏览器、桌面软件和后台服务的实际验证。
先分清“连接成功”和“流量接管”
一次访问通常包含域名解析、路由选择、连接目标服务等环节。客户端显示已连接，可能表示隧道已经建立，也可能只是代理核心已启动。应用是否使用这个入口，还取决于系统代理、虚拟网卡、分流规则和应用自己的网络设置。
“系统代理”通常告诉愿意遵循该设置的软件，把相应请求交给代理。它并不等于接管设备全部网络。TUN 模式则通过虚拟网卡和路由处理 IP 流量，接管范围往往更广，但仍受排除项、权限、协议支持与具体配置影响。“全局代理”也可能只是把已经进入客户端的请求统一交给节点，并不自动让所有应用进入客户端。
| 检查项目 | 主要观察 | 不能单独证明 |
|---|---|---|
| 客户端连接状态 | 核心、隧道或节点是否建立连接 | 目标应用的请求是否经过节点 |
| 浏览器出口 IP | 该浏览器访问检测站点时的公网出口 | 其他应用及其他地址族也使用相同路径 |
| DNS 检测 | 检测域名的递归解析器及相关线索 | 全部业务流量的出口和隐私边界 |
| 客户端连接记录 | 目标请求命中的规则、策略和出站 | 远端服务一定允许访问或操作成功 |
| 目标应用实际操作 | 所需功能能否在当前路径下完成 | 设备上的所有应用都已被接管 |
出口 IP：用相同条件做连接前后对照
先在未连接状态下，用浏览器打开可信的公网 IP 检测页面，记录公网地址、地址族和网络归属。随后连接选定线路，在同一浏览器重新加载同一页面。尽量使用能返回当前请求信息的页面，而不是只展示缓存内容的页面。
如果检测请求命中代理规则，出口通常会变成线路的远端出口。地址归属地与所选地区相符，可以作为辅助证据，但地理数据库可能存在更新延迟或标注差异。不要仅凭城市名称不同就认定线路异常，也不要把本地局域网地址误当成公网出口。
- 记录连接前的公网出口，并确认浏览器没有同时运行其他代理扩展。
- 连接线路后检查当前模式，确认检测域名没有被规则安排为直连。
- 重新发起检测请求，对比地址变化；必要时关闭旧标签页，避免沿用已有连接。
- 查看客户端连接记录，把检测域名对应的出站与页面结果相互核对。
- 断开后再次检测，确认变化与本次连接有关，而不是来自其他代理或网络切换。
支持 IPv4 和 IPv6 的设备需要分别观察。某些配置只处理其中一种地址族，浏览器可能选择另一条路径。若目标是让相关公网请求都经过线路，应确认两类流量都被接管，或按客户端文档使用合适的阻断策略，而不是看到一个地址变化就结束检查。
DNS：判断解析路径，不只看国家名称
DNS 负责把域名转换成地址。DNS 泄漏通常指本应按预期受保护的解析请求，却走了意外路径，例如仍由本地网络的解析器处理。它与业务连接的出口不是同一件事：网页请求可以经过节点，而域名查询仍在本地完成。
常见 DNS 检测页面会生成测试域名，再观察哪些递归解析器前来查询。结果中的地址通常属于解析服务，不是你的业务出口。公共解析服务可能采用任播、缓存和转发机制，其标注地区不一定等于实际处理位置，因此“解析器和节点不在同一国家”本身不足以判定泄漏。
更有价值的问题是：当前配置期望由谁解析？客户端是否接管系统 DNS？浏览器是否启用了独立的加密 DNS？如果预期使用远端解析，却反复看到本地运营商解析器，就需要继续核对。反过来，没有看到运营商名称，也不能据此断言全部应用的 DNS 都已经得到保护。
- ✅ 核对客户端的 DNS 模式、远端解析设置及直连域名的解析策略。
- ✅ 检查浏览器的安全 DNS 设置，确认它与客户端配置是否相互独立。
- ✅ 在配置调整后重新发起测试，避免把已有缓存或旧连接当成新结果。
- ✅ 对照客户端记录中的域名、目标地址和出站，判断解析与业务连接是否符合预期。
- ❌ 不要把解析器名称、地区相同或不同，直接等同于安全或泄漏结论。
部分客户端使用 Fake-IP，把合成地址返回给应用，再在内部关联域名和实际出站。这类地址与普通公网解析结果不同，不代表 DNS 一定损坏。遇到局域网设备、企业内网域名或特殊应用异常，应检查对应的排除规则，而不是随意替换整套 DNS 配置。
分应用验证：浏览器正常不代表其他软件正常
浏览器、命令行工具、游戏和桌面办公软件可能使用不同网络栈。浏览器通常能遵循系统代理，命令行程序则可能依赖环境变量或自己的代理参数；部分软件会忽略系统代理。移动端客户端还可能设置应用白名单或排除名单，所以必须用实际需要的应用验证。
Windows 与 macOS
先退出浏览器代理扩展，避免它覆盖系统设置。测试桌面软件时，查看客户端是否出现对应进程或目标域名的连接记录。如果浏览器有记录，而目标软件完全没有，优先检查软件自己的代理选项、客户端接管模式及虚拟网卡权限。受管理的办公设备还可能有组织下发的网络策略，不宜擅自覆盖。
Android 与 iOS
先确认系统已允许客户端建立 VPN 连接，再检查客户端是否提供并启用了分应用规则。Android 还要关注后台运行与省电限制：切换应用或锁屏后断流，与首次连接失败是不同问题。iOS 的接管范围则受客户端实现和系统配置影响，不能直接套用桌面端的设置路径。
命令行与后台任务
终端中的请求不会因为浏览器能访问就自动走相同路径。检查工具是否读取代理环境变量，以及该工具使用本地解析还是把域名交给代理端解析。不要从终端输出中看到请求成功，就推断它经过了节点；仍应结合出口和客户端记录核对。定时任务的运行环境也可能与交互式终端不同。
验证时执行真实、低风险的操作，例如刷新应用内容或请求公开资源。单纯打开应用首页可能命中本地缓存，无法证明新请求的路径。也不要反复提交付费、发布或其他不可逆操作来测试连接。
看起来连上却没生效，按现象定位
节点延迟测试通过，只说明测试请求有响应；能否完成目标服务的访问，还受 DNS、规则、传输方式与远端限制影响。Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC 等名称描述的是不同协议方案，并不是流量接管成功的凭证。客户端需要支持订阅实际提供的协议及配置。
| 现象 | 可能原因 | 下一步 |
|---|---|---|
| 显示连接，出口没有变化 | 检测域名直连、系统代理未生效或应用未被接管 | 查该请求命中的规则和出站 |
| 浏览器正常，其他应用失败 | 应用忽略系统代理、被排除或使用不同传输方式 | 查应用设置、接管范围及相关协议支持 |
| 出口已变化，目标网站仍拒绝访问 | 服务地区政策、账号限制或出口信誉判断 | 核对服务提示，不把拒绝访问直接当成代理失效 |
| 切换线路后仍像旧出口 | 已有长连接没有重建，或页面使用旧结果 | 退出相关应用后重试，重新检查连接记录 |
| 锁屏或换网络后失效 | 后台限制、隧道重连失败或路由未恢复 | 恢复客户端运行并重建连接，再复测目标应用 |
IEPL 专线、中转和直连描述的是线路路径或承载方式，不会替你完成设备端接管。即使选择专线，错误的分流规则仍会让请求直连；反过来，中转线路也可以按配置正常转发。线路类型不能替代出口、解析和应用层的交叉验证。
整理检查结果，再调整配置
排查时每次只改一个相关设置，保留原配置以便恢复。先确认订阅导入成功且节点可用，再检查目标请求是否进入客户端，随后核对出站与 DNS，最后处理目标服务自身的提示。若一开始就同时更换节点、解析器和规则，即使问题暂时消失，也很难知道真正原因。
需要协助时，可以通过支持页面提供设备系统、客户端名称、所用模式、异常发生场景和已经完成的检查。截图应遮住订阅链接、用户名、密码、令牌以及其他私人信息。订阅链接是配置凭据，不要粘贴到公开检测页面，也不要把完整链接发布到讨论区。
VPNGQ 的使用教程适合处理安装与订阅导入，完整手册可用于继续核对配置。营销中的“匿名无日志”是服务的隐私策略表述，不代表浏览器登录状态、网站追踪或应用账号信息会自动消失。确认线路生效与管理账号隐私，是需要分别处理的事情。