VPN 连上了怎么确认真的生效，不能只看客户端里的“已连接”。这个状态通常只能说明客户端已经完成握手，或已经建立到服务器的会话；它不能单独证明浏览器、下载工具和其他应用的流量都经过了预期线路。可靠的验收方法是先记录原网络状态，再核对出口 IP 与 DNS，最后按应用逐个验证实际路径。
这套检查不依赖某一种协议。Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC，以及由系统接管的 VPN 配置，都可能因为代理模式、分流规则、权限状态或应用自身设置而出现“客户端在线，目标流量未进入线路”的情况。协议握手成功只是起点，流量路径才是最终结果。
先理解“已连接”实际证明了什么
客户端显示已连接，通常表示本地客户端与远端节点之间可以通信，认证信息可用，并且协议会话已经建立。不同客户端对状态的判定并不完全相同：有的在握手完成后立即显示连接成功，有的会等到系统代理、虚拟网卡或路由规则写入完成后再更新界面。
因此，连接状态与流量接管是两个检查点。前者回答“客户端能否联系节点”，后者回答“指定应用发出的请求是否进入这条路径”。如果系统代理没有写入、虚拟网卡权限未生效、分流规则命中直连，或应用绕过系统代理自行联网，就会出现状态正常但出口不变的现象。
| 观察位置 | 能够证明 | 不能单独证明 |
|---|---|---|
| 客户端连接状态 | 本地客户端与节点会话已经建立 | 所有应用都经过节点 |
| 出口 IP 查询 | 当前查询请求从哪个公网地址离开 | 其他应用采用相同路径 |
| DNS 查询结果 | 域名解析请求由哪些解析器处理 | 网页内容请求一定经过相同线路 |
| 目标应用实测 | 该应用在当前规则下可以完成实际请求 | 系统内其余应用也已被接管 |
检查时还要分清代理客户端与系统级隧道。浏览器代理通常只处理遵循系统代理设置的程序；虚拟网卡模式会在网络层接管更多流量，但仍可能受到路由表、排除规则和本地网络保护规则影响。不能因为一种应用的出口已经改变，就推断整台设备的全部连接都已改变。
第一步：对比出口 IP 与归属
出口 IP 是最直接的起点。断开线路后，打开可信的 IP 查询页面，记录公网 IP、运营网络归属和大致地区。随后连接目标线路，关闭刚才的查询页面并重新打开，或者强制刷新，再观察结果是否变化。
- 断开客户端中的线路，确认网络恢复为日常连接状态。
- 查询当前公网出口，记录地址、网络归属与地区信息。
- 连接准备使用的节点，等待客户端完成路由或代理设置。
- 重新发起查询，不要只读取旧标签页里已经加载的结果。
- 比较连接前后的公网地址，并核对新地址是否符合所选线路的预期地区。
- ✅ 公网 IP 已变化，归属与目标线路基本一致，可以继续检查 DNS 和应用路径。
- ✅ IP 已变化但地区显示相邻城市，先交叉查询，不要仅凭单个地理数据库判定失败。
- ❌ 公网 IP 完全不变，优先检查代理模式、虚拟网卡权限、系统代理写入与分流规则。
- ❌ 浏览器出口变化而其他应用不变，说明当前设置可能只接管了浏览器或遵循系统代理的程序。
IP 地理位置数据库存在更新延迟，同一个地址在不同查询服务中可能显示不同城市。验收时更应关注公网地址是否变化、网络归属是否合理，以及国家或地区是否符合预期，不要把城市级标签当成精确定位。如果几个查询来源给出的地区不同，可以结合目标网站实际返回的区域内容继续判断。
第二步：检查 DNS 是否走预期路径
访问网站前，设备通常要先把域名解析成可连接的地址。若内容请求经过线路，而 DNS 仍交给原网络提供的解析器处理，就可能暴露本地网络的解析路径，也可能因解析结果与出口地区不一致而导致访问异常。这类情况通常被称为 DNS 泄漏。
检查时应在断开和连接状态下分别执行 DNS 查询测试，比较解析器的网络归属与地区。连接后仍看到本地网络常用解析器，不一定立刻说明内容流量没有经过线路，但说明 DNS 路径需要继续核对。较稳妥的配置是让客户端按其设计接管 DNS，并使解析策略与代理规则保持一致。
DNS 结果不能机械地要求与出口 IP 完全同城。服务商可能使用公共解析器、任播解析器或远端转发，显示的组织名称也可能与节点运营方不同。真正需要警惕的是：连接前后解析路径毫无变化、出现明显属于原网络的解析器，或者不同规则下持续得到与目标地区冲突的解析结果。
浏览器加密 DNS 会改变测试含义
部分浏览器可以启用独立的加密 DNS。启用后，浏览器可能绕过操作系统的默认解析设置，直接向浏览器指定的解析服务发出请求。此时，网页测试展示的是浏览器自身的 DNS 路径，不一定代表系统内其他应用。
排查时可以先确认浏览器是否启用了独立解析，再决定测试目标：如果要检查系统 DNS，就应使用遵循系统设置的工具；如果要检查浏览器实际访问路径，就保留浏览器当前设置。不要在测试途中反复切换配置，否则前后结果无法对应。
检查顺序
断开线路 → 记录出口与 DNS
连接线路 → 复查出口与 DNS
核对浏览器独立 DNS → 再测浏览器
核对客户端 DNS 策略 → 再测其他应用第三步：按应用验证分流规则
出口与 DNS 检查完成后，还要回到真正需要使用的应用。现代代理客户端通常支持规则分流：本地站点直连，指定域名或网络段经过代理，局域网地址保持直连。规则模式的目标本来就不是让所有请求采用同一个出口，所以“某个网站仍显示原出口”可能是规则预期，也可能是规则遗漏。
最清楚的验证方式，是临时比较全局代理与规则代理的结果。全局模式下目标应用可以改变出口，而规则模式下没有改变，问题通常落在规则匹配、规则顺序或应用绕过设置上。全局模式下仍不改变，则应继续检查系统代理、虚拟网卡、路由冲突和客户端权限。
不同平台的接管边界
桌面平台上的系统代理主要影响遵循系统代理接口的应用。一些下载工具、开发工具和游戏平台拥有独立代理配置，可能直接连接网络。虚拟网卡模式能够覆盖更多基于 IP 的连接，但仍需正确写入路由，并处理本地网络、私有地址和 DNS。
Android 与 iOS 上的客户端通常通过系统提供的 VPN 接口建立隧道。若启用了分应用代理或排除应用，被排除的程序会继续使用原网络。系统同时只允许当前生效的隧道配置接管相应流量，因此切换客户端后应重新确认配置状态，而不是只观察旧客户端的历史记录。
浏览器扩展通常只影响该浏览器中的网页请求，无法代表其他程序。命令行工具还可能读取自己的环境变量，例如 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY。开发者在测试接口请求时，应同时核对终端环境、应用配置和客户端规则。
- ✅ 浏览器、目标应用和命令行工具分别发起实际请求，并各自核对出口。
- ✅ 规则模式下确认目标域名命中了代理规则，而非默认直连规则。
- ✅ 使用虚拟网卡时检查系统授权、路由写入和 DNS 接管状态。
- ❌ 只用浏览器扩展测试后，就推断设备内所有程序已经走同一线路。
- ❌ 只看到客户端产生流量，就认定目标应用的请求已经被接管。
线路类型会影响排查位置
直连线路表示客户端直接与目标节点建立连接，链路结构较简单。若握手成功但出口不变，排查重点通常在本地代理模式、路由和应用设置。中转线路会先连接中转入口，再由中转网络转送到出口节点；客户端看到的是入口会话，网站看到的则应是最终出口地址。
IEPL 专线通常用于描述入口与出口之间采用专用承载或受控传输的线路设计。它与普通公网中转的区别主要在中间传输路径，不意味着本地应用会自动正确分流。无论采用直连、中转还是 IEPL，验收动作都相同：核对最终出口、DNS 路径与目标应用请求。
协议名称也不能替代路径验证。Shadowsocks 与 Trojan 常作为代理协议使用；VMess 与 VLESS 依赖客户端核心及传输配置；Hysteria2 与 TUIC 基于 QUIC 类传输，更关注在特定网络条件下的连接表现。它们的封装、认证和传输方式不同，但客户端显示握手完成后，仍要检查系统是否把目标流量送进对应会话。
| 线路或模式 | 网站应观察到的出口 | 优先排查点 |
|---|---|---|
| 直连节点 | 所选节点的公网出口 | 系统代理、虚拟网卡、路由与应用设置 |
| 公网中转 | 最终出口节点，而非中转入口 | 入口可达性、中转转发与出口配置 |
| IEPL 专线 | 最终出口节点 | 本地接管、入口连接与出口映射 |
| 规则分流 | 由命中规则决定 | 规则顺序、域名匹配与默认策略 |
常见的“看起来连上了”情形
系统代理没有成功写入
客户端已经连接节点，但系统代理仍为空，或者被其他网络工具覆盖。此时遵循系统代理的浏览器与应用不会进入线路。可以在客户端中重新切换系统代理，并检查操作系统网络设置是否随之变化。
规则把目标请求判为直连
域名规则、网络段规则和默认规则存在优先顺序。目标域名若先命中直连条目，后面的代理规则不会再处理。排查时应查看客户端连接记录或规则命中信息，确认实际使用了哪一条规则，而不是只检查规则列表中是否出现目标域名。
应用拥有独立代理设置
部分应用不会跟随系统代理，或者在内部保存了旧代理地址。也有应用直接使用自己的网络栈和 DNS。遇到浏览器正常、特定程序不变时，应先检查该程序的网络选项，再决定是否改用虚拟网卡模式。
订阅更新了，但当前节点没有重载
订阅链接用于向客户端提供节点与规则配置。导入订阅或执行更新后，部分客户端需要重新选择节点、重新连接，才会使用新配置。仅看到订阅更新时间变化，并不能证明当前会话已经切换到更新后的出口。
网络切换后保留了旧会话
设备从一个网络切换到另一个网络时，原有连接可能中断或进入等待恢复状态。客户端界面未必立即刷新。此时应主动断开并重新连接，然后重新执行出口与 DNS 检查，避免依据切换前的会话判断。
WebRTC 结果被误读
浏览器的 WebRTC 检测可能展示局域网候选地址、经过隐藏处理的候选名称或公网候选地址。看到本地私有地址不等于公网出口没有变化。应区分局域网地址与可由互联网访问的公网地址，并把 WebRTC 结果与常规出口查询结合判断。
一份可重复执行的验收清单
首次配置、切换客户端、修改分流规则或更换网络后，都可以按同一顺序复查。固定流程的价值在于快速定位变化发生在哪一层，而不是反复切换节点碰运气。
- 断开线路，记录原始公网出口和 DNS 解析路径。
- 连接目标节点，确认客户端完成握手与系统接管。
- 重新查询公网出口，核对地址、网络归属和预期地区。
- 执行 DNS 测试，检查是否仍明显使用原网络解析器。
- 在浏览器、目标应用和必要的命令行工具中分别发起请求。
- 规则模式异常时，对比全局模式，并查看实际命中规则。
- 网络环境或配置发生变化后，重新执行整套检查。
若出口没有变化，从系统代理、虚拟网卡和路由开始；若只有部分应用没有变化，从应用独立设置与分应用规则开始；若出口正确但域名访问异常，从 DNS、浏览器加密 DNS和规则解析方式开始。按层排查比频繁更换协议更容易找到原因。