VPN连上了怎么确认生效？查IP、查DNS与分应用验证

先分清：连接状态与流量接管

客户端可以成功连接节点，但系统仍未把目标应用的请求交给它。例如，仅启动本地代理监听，并不等于已经启用系统代理；启用系统代理，也不意味着所有程序都会遵循该设置。先在客户端确认当前使用的是系统代理、隧道接管，还是仅为指定应用提供代理。

“全局”和“规则”通常描述进入客户端之后如何选择出口；系统代理与 TUN 等隧道模式则涉及流量如何进入客户端。这是不同层面。把规则模式改成全局，并不能自动接管一个完全绕过系统代理的程序。具体开关名称与支持范围，应以正在使用的客户端说明为准。

因此，最有说服力的结果是：目标请求命中了预期规则，出口地址与连接记录相互吻合，应用的实际功能也能完成。单看状态图标或者一个网页是否打开，都容易漏掉问题。

查出口 IP：做连接前后的对照

先明确你希望检测网页走代理还是直连。如果规则本来就把该网页设为直连，连接之后地址不变是正常现象。可以临时使用客户端支持的全局代理模式进行对照，完成后恢复原有规则，避免把测试设置长期留在日常环境中。

1. 断开线路，打开我的 IP，记下当前公网地址及网络归属。不要把路由器分配的局域网地址当作公网出口。
2. 连接所选节点，确认系统代理或隧道接管已启用，并检查检测网页是否应走该节点。
3. 重新加载检测页，避免只看页面中保留的旧结果。若客户端支持连接记录，同时查看该请求使用的出口。
4. 对照地址、规则和节点选择。如果结果有分歧，先排除网页缓存与规则直连，再考虑更换节点复测。

IP 归属地来自地址数据库，并不等同于服务器的物理位置。不同数据库可能给出不同城市，线路入口与对外出口也可能不同。因此，不应仅凭城市名称不一致就判定连接失效；应结合地址是否变化、网络归属与客户端记录判断。

如果设备同时具备 IPv4 与 IPv6 连通性，还要关注检测工具是否分别检查了这些路径。只验证其中一种地址，无法排除另一种流量仍直连的情况。是否接管相关流量取决于客户端和配置，不宜把关闭某项网络能力当作所有设备的默认修复办法。

查 DNS：先明确解析策略，再判断泄漏

DNS 用于把域名解析为网络地址。网页内容经过代理，并不代表解析请求也一定经过相同路径。系统解析器、客户端的 DNS 模块、浏览器的安全 DNS，以及应用内置解析机制，都可能参与其中。

常见 DNS 检测页会生成测试域名，并根据收到的查询展示解析器信息。它通常反映递归解析服务的出口，不一定是设备直接联系的那个地址。公共解析服务还可能使用分布式网络，所以解析器显示在本地或附近地区，并不能单独证明发生了泄漏。

按配置意图核对结果

• 先查看客户端是否接管 DNS，以及直连域名和代理域名是否采用不同解析策略。规则分流下出现不同解析路径，可能是有意设计。
• 检查浏览器的安全 DNS 设置。浏览器自行发起的加密 DNS 请求，可能不使用系统解析器；但加密本身不决定它最终走代理还是直连。
• 在保持同一网络和同一节点的前提下，对照调整前后的结果。每次只改变一个设置，才能判断差异由什么引起。
• 若目标是让代理域名避免通过本地网络解析，应核查这些域名的实际解析路径，而不是要求所有国内直连域名也走远端解析。

还要留意缓存。修改解析策略之后，系统、浏览器或应用可能继续使用已有结果，导致当前页面没有产生新的查询。可以按客户端与系统文档处理缓存，再完全退出目标应用后重试，不要把一次没有新记录的测试当作最终结论。

分应用验证：网页能打开还不够

把实际使用场景拆开测试，比不断刷新同一个网页更有效。浏览器负责网页访问，桌面软件可能有独立代理设置，游戏或实时通信还可能使用 UDP。某种请求能通过，不代表其他传输方式也已被同样处理。

Windows 与 macOS 上，一些程序读取系统代理，另一些使用自己的网络设置。Linux 的桌面代理设置、环境变量和单个程序的选项，也不保证互相覆盖。移动端即使显示 VPN 状态标记，也仍可能存在按应用排除或按目标分流，应回到客户端核对。

• ✅ 浏览器：访问目标网页并打开实际内容，同时核对出口检测与客户端连接记录。
• ✅ 桌面应用：检查软件内部代理设置，完全退出后重新打开，再触发同步、下载或其他真实操作。
• ✅ 命令行工具：核对自身代理选项与代理环境变量。终端成功或失败，都不能直接代表浏览器的状态。
• ✅ 实时通信：分别验证消息、语音或视频功能，避免把文字消息成功当作通话路径已经正常。
• ❌ 只看启动页：启动页可能来自缓存，真正的数据接口可能使用另一个域名和另一条规则。

如果客户端提供连接列表，可先清理旧记录，再触发一次目标操作。查看对应进程或域名、命中的规则、实际出口及错误信息。不要只凭流量曲线在动就认定目标应用经过代理，因为变化可能来自其他后台程序。

排查时可以在受控范围内临时扩大接管范围。若这样能工作，而恢复规则后失败，就优先检查分流规则；若目标请求始终没有进入客户端，则优先检查应用代理、接管模式或应用排除设置，而不是盲目更换节点。

常见误判：把线路、规则和平台限制分开

地址变了，目标服务仍不可用

这不必然意味着代理没有生效。目标服务可能依据账号地区、授权范围、出口地址信誉或设备定位作判断。应先验证请求路径，再核查平台规则。流媒体是否可播放以目标平台实测为准，不能仅凭出口国家名称推断。

切换节点后，应用还在使用旧连接

有些应用会维持长连接，切换节点并不总会让现有会话马上重建。完全退出应用再打开，有助于重新建立请求。网页缓存、已有登录状态和解析缓存也会影响观察，因此要区分页面保留内容与真实的新请求。

专线已选中，却仍有应用直连

IEPL 专线、中转与直连描述的是线路组织方式，不是设备上的流量接管方式。专线不负责替应用开启系统代理；中转也不等于所有域名自动走代理。线路选择解决传输路径问题，客户端设置解决哪些请求进入该路径的问题。

怀疑协议不匹配，直接反复更换配置

Shadowsocks、VMess、Trojan、VLESS 等名称涉及不同代理协议；Hysteria2、TUIC 也有各自的传输与实现要求。客户端必须支持订阅实际提供的协议和参数。不要仅修改协议名称来“修复”连接，应从面板重新获取配置，并按使用教程完成导入与更新。

排查收尾：留下可复现的结果

遇到持续异常，记录当前网络环境、客户端版本、接管模式、所选节点、目标应用和复现动作。把“连不上”改写为具体描述，例如“浏览器出口已变化，桌面应用的请求未出现在连接列表”，能明显缩小排查范围。

提交截图前隐藏订阅链接、认证信息和个人账号。订阅链接往往包含访问凭据，不应发到公开讨论区；日志也可能包含域名和本机信息，只提供定位问题所需的部分。需要进一步处理时，可参考新手到进阶中的排查说明。