怎么检测 VPN 是否生效？最可靠的起点不是看客户端的连接图标，而是对照连接前后的出口 IP，再检查 DNS 请求，最后逐个确认你实际使用的应用。连接状态只表示客户端尝试建立了通道；浏览器、桌面程序和系统服务是否使用这条通道，还取决于代理模式、分流规则及应用自身的网络设置。
下面的方法不要求记住自己的公网地址。先记录断开时看到的网络信息，再在同一设备、同一网络下连接目标节点并重测。对照结果时，同时留意检测工具测到的是浏览器流量，还是整台设备的流量。把这两者混为一谈，是“明明显示已连接却仍走原网络”的常见原因。
先查出口 IP：建立连接前后对照
出口 IP 是目标网站看到的访问来源。先断开 VPN，在浏览器打开一个可信的 IP 查询页面，记录显示的公网 IP 和大致地区；也可以使用本站的我的 IP 查询页查看当前浏览器的出口信息。然后连接准备使用的节点，刷新查询页，再比较结果。最好保留查询页地址和测试时所选节点，以免后来拿不同工具、不同网络的结果直接比较。
- 断开客户端连接，关闭其他正在运行的代理或网络加速工具，查询并记下浏览器出口 IP。
- 连接目标节点，确认客户端所选模式；重新载入查询页，不要只看断开时留下的页面内容。
- 比较 IP 本身是否变化，并核对大致地区是否符合所选出口。地区数据库可能滞后，不能仅凭城市名称判定失败。
- 需要确认另一款应用时，在那款应用内执行可观察到网络结果的操作，不要把浏览器的检测结果直接套用到它身上。
如果地址改变，说明这次浏览器请求至少从不同的出口到达了查询站，但这还不能证明 DNS 或其他应用也经过线路。如果地址不变，也先不要急着下结论：分流模式可能让这个查询站直连；浏览器扩展可能覆盖系统代理；页面也可能展示了缓存内容。换一个可信的查询站并强制重新载入，能帮助排除单个站点的显示问题。
再查 DNS：解析路径与网页出口要分开看
DNS 负责把域名转换成可连接的地址。网页请求经过目标节点，不代表域名查询必然走同一条路径。检测时，使用能显示实际响应 DNS 查询的测试工具，在连接前后分别查询未访问过的域名，比较解析服务的归属与客户端预期。若工具提示应清除缓存或重新生成测试域名，按它的说明操作；反复打开已经解析过的页面，可能根本没有发起新的 DNS 请求。
判断 DNS 泄漏要先看自己的目标：如果客户端设置为所有相关查询都交给线路处理，却反复看到本地网络指定的解析服务，就应检查 DNS 配置。若启用了分流，本地域名由本地解析、国际域名由另一解析路径处理，也可能是规则的预期行为。解析服务所在国家与出口地区不同，同样不能单独作为泄漏证据；公共解析服务的节点位置和显示归属未必一致。
还要留意浏览器的安全 DNS 设置。有些浏览器会自行使用加密 DNS，而不是系统配置的解析服务。测试结果因此可能反映浏览器的设置，并非客户端的系统级 DNS 行为。排查时先记录浏览器是否开启该功能，再分别测试浏览器和其他应用；不要为了得到某个“好看”的测试结果，就在不了解影响的情况下修改系统 DNS。
分应用验证：浏览器通过不等于全设备通过
客户端常见的工作范围包括浏览器扩展代理、系统代理以及接管更多设备流量的虚拟网络接口模式。浏览器扩展通常只影响对应浏览器；系统代理要求应用遵循系统设置；使用虚拟网络接口时，还要看路由与分流规则。名称相似的“全局”和“规则”选项在不同客户端里实现不一定相同，应以实际设置说明和测试结果为准。
| 待验证对象 | 可执行的检查 | 结果如何解读 |
|---|---|---|
| 浏览器网页 | 连接前后查询出口 IP，再执行新的 DNS 测试 | 只说明该浏览器当前测试请求的路径 |
| 另一款浏览器 | 在该浏览器单独打开同一查询页 | 结果不同，先检查扩展、代理和安全 DNS 设置 |
| 桌面应用 | 查看应用是否有独立代理设置，并测试其实际联网功能 | 网页出口变化，不能推断该应用也已接入 |
| 移动应用 | 在同一网络下分别测试浏览器与目标应用 | 留意应用内置连接方式及客户端分流规则 |
测试桌面或移动应用时，尽量选择能直接观察请求结果的功能，例如应用内的网络诊断、服务地区提示或连接日志。如果应用本身不显示出口，就不要把“能打开内容”当作路径证明：直连也可能正常打开。更稳妥的做法是查看客户端的连接记录或规则命中信息，并与应用发起请求的时间对应；这些记录只用于判断流量去向，不应随意公开包含账户或访问地址的截图。
排查“已连接但没走线路”的常见情况
发现测试结果不符合预期时，先固定测试条件：保持同一网络、同一设备和同一个待测应用，只改变客户端的一项设置。这样才能知道是哪项设置影响了结果。下面的清单按容易核对的顺序排列；完成一项就重新测试，不要同时切换节点、规则和浏览器设置。
- ✅ 核对当前模式。规则模式可能让 IP 查询站直连；如需验证线路本身，可在理解影响后临时选用适合测试的模式，测完恢复原设置。
- ✅ 核对代理范围。只有浏览器扩展生效时，其他浏览器和桌面应用不会自动采用同一出口。
- ✅ 核对应用设置。独立配置的代理、内置 DNS 或旧的网络连接，可能覆盖你以为正在使用的系统路径。
- ✅ 核对 IPv6。若本地网络提供 IPv6，而所用模式未处理相应流量，支持 IPv6 的站点可能走另一条路径；分别观察 IPv4 与 IPv6 的查询结果。
- ✅ 核对 DNS 与规则命中。出口 IP 改变而解析仍不符合预期时，应分开检查解析设置，不要只反复更换节点。
IPv6 检查尤其容易被忽略。一个查询页可能只展示 IPv4，另一个站点却优先使用 IPv6。若工具能分别显示两类地址，就分别比较连接前后的结果。发现差异后，先查客户端是否支持所选模式下的 IPv6 路由，以及当前规则是否覆盖目标请求；不要仅凭关闭设备的 IPv6 功能来掩盖未弄清的路径问题。
还有一种情况是连接建立了，但节点没有正常转发目标请求。此时可以先测试普通网页，再查看客户端是否报告握手、认证或订阅更新错误。不要把所有加载失败都归为“线路未生效”：目标服务故障、应用缓存、域名解析异常，也会造成相似表现。用出口、DNS、应用三个层面的结果交叉判断，比反复点击连接按钮更有效。
订阅与协议名称不能代替实际检测
订阅链接通常用于向兼容的客户端提供节点和配置信息。导入成功，只表示客户端拿到了可识别的配置；节点能否连接、规则是否按预期运行，仍需单独验证。更新订阅后如果测试结果突变，应确认当前实际选中的节点和模式，而不是只看订阅列表有没有显示新条目。不同平台客户端的设置位置可能不同，也不能假设同名选项必然覆盖相同流量。
Shadowsocks、VMess、Trojan、VLESS、Hysteria2 和 TUIC 是不同的连接协议或方案名称，不是“已通过检测”的标记。协议影响客户端与节点如何建立连接，出口 IP、DNS 和应用分流则回答流量实际去了哪里。IEPL 专线、中转和直连描述的是线路组织方式，也不能取代终端侧验证：即使节点可用，应用没有被代理规则接管，访问仍可能走本地路径。
如果需要向支持人员描述问题，提供客户端平台、所用模式、预期访问的应用，以及连接前后出口和 DNS 的差异即可。订阅链接可能包含访问凭据，不要把完整链接贴进公开讨论区。截图也应遮住与排查无关的账户信息。
如何给这次检测下结论
把结论限定在已经测试过的范围内。如果浏览器出口符合所选节点、DNS 解析符合你的模式预期，而目标应用也有对应的规则命中或可观察的网络结果，就可以说这些已测请求按预期运行。反过来，只有客户端显示“已连接”，或者只有浏览器出口发生变化，都不足以推断整台设备的所有流量采用了同一路径。
网络环境或客户端配置变化后，原来的检测结果也可能失效。更换网络、切换节点或更新订阅时，按同样的顺序重新检查，记录的是当时、该设备、该应用的结果，而不是对以后所有连接的保证。