确认 VPN 生效，先区分连接与流量
怎么确认VPN真的生效？查出口IP、DNS与分应用验证，要分别看结果。连接提示只能说明客户端处于某种连接状态；是否接管目标应用、解析请求走哪里、出口是否符合预期，还需要实际请求来核对。
代理客户端和系统级 VPN 的接管范围可能不同。系统代理是向遵循该设置的应用提供代理入口，并不强制所有程序使用它；浏览器插件通常只影响对应浏览器。TUN 模式通过虚拟网卡与路由接管匹配的流量，但仍受排除应用、路由规则和地址族配置影响。把“浏览器能打开”当作整机验证结果，容易漏掉这些差异。
测试前先写下目标：是让某个应用走国际线路，还是让默认流量都进入隧道？规则模式允许指定站点直连，这不是故障。只有实际路径与设定目标不一致，才需要继续排查。
出口 IP：建立连接前后的对照
出口 IP 是目标网站看到的请求来源，不等于本机局域网地址，也不一定等于订阅配置里的服务器地址。订阅中的地址可能是中转入口，最终出口在另一处。检查时要比较同一工具、同一浏览器和同一网络条件下的结果。
- 断开客户端连接，暂时停用浏览器代理插件。用可信的公网 IP 查询工具记录当前出口、网络运营方，以及工具是否分别显示 IPv4 与 IPv6。
- 连接选定线路，确认系统代理或 TUN 已按目标启用。在规则模式下，检查查询工具对应的域名是否确实命中代理规则。
- 重新发起查询。不要只读旧标签页里的结果；必要时使用新的浏览器会话，排除缓存页面和已有连接的影响。
- 查看客户端的连接记录，核对查询请求匹配的规则、策略组及实际出口线路，再与查询结果对照。
- 切换出口地区不同的线路后再查。若始终不变，先查接管范围与规则，不要直接认定线路失效。
国家或地区标签只适合作辅助线索。IP 地理数据库可能滞后，查询工具之间也可能不一致；同一地区的不同线路还可能共用出口。更可靠的证据是请求日志明确显示走了所选策略，并且查询到的网络归属与该线路出口相符。延迟高低不能代替出口验证。
若 IPv4 已切换而 IPv6 仍显示本地网络，先确认客户端是否接管 IPv6，以及应用是否优先使用它。需要全流量接管时，应按客户端文档配置 IPv6 路由或使用其相应保护选项。只查询 IPv4 的页面，无法说明 IPv6 的路径。
DNS 泄漏：看解析路径是否符合目标
DNS 的用途是把域名解析为地址。浏览器请求可以经过代理，而域名解析仍交给本地网络提供的解析器；也可能由代理端解析。这里的“DNS 泄漏”应结合预期定义：如果要求相关查询进入受控隧道，却被发送给本地解析器，就存在路径偏离。
连接线路后，可以用可信的 DNS 检测工具发起检测，记录它观察到的解析器及网络归属。此类工具通常通过专用测试域名观察递归解析来源，显示的是参与解析的服务器，不是网站请求的出口。解析器与出口不在同一地区，不能单独作为泄漏结论。
浏览器的安全 DNS、系统 DNS、客户端 DNS 和应用自带解析功能可能同时存在。安全 DNS 常使用加密方式访问解析服务，但“加密”不代表自动进入 VPN。浏览器也可能绕过系统解析器，因此浏览器中的检测结果不能代表所有应用。
- 先保存客户端与浏览器的 DNS 设置，明确预期使用哪个解析器，以及解析请求应走代理还是直连。
- 检查客户端是否分别配置直连域名与代理域名的解析路径；规则分流下，本地域名查询走本地解析器可能是有意设计。
- 为了定位差异，可以临时调整浏览器安全 DNS 后重复检测，每次只改变一项设置，测试结束后恢复所需配置。
- 查看客户端是否提供 DNS 日志，区分缓存命中、由代理端解析、客户端本地解析与实际发出的查询。
分应用验证：浏览器通过还不够
分应用检查要在目标应用里制造新的请求。先打开客户端连接记录，再重启待测应用，访问一个确实需要代理的功能或页面。核对请求时间、目标域名、命中规则与策略。没有日志时，不能只凭“打开成功”判断路径；该服务可能本来就能直连，或者展示的是缓存内容。
Windows 和 macOS 上，有些程序不遵循系统代理。此时应使用程序自身的代理配置，或按客户端文档启用 TUN；创建虚拟网卡可能需要权限，具体以所用客户端为准。命令行工具也可能需要自己的代理参数或环境变量，系统代理成功不等于终端请求成功。
Android 的客户端可能利用系统 VPN 接口，并提供允许或排除应用的选项。检查目标应用是否在正确列表中，同时留意系统 VPN 设置及工作资料空间。iOS 客户端通常通过系统网络扩展建立隧道，具体路由能力由客户端与配置决定，不能照搬 Android 的分应用菜单步骤。
| 测试对象 | 重点观察 | 不能据此推断 |
|---|---|---|
| 浏览器 | 出口、代理插件、安全 DNS、对应请求日志 | 桌面软件与终端也使用相同路径 |
| 桌面应用 | 自身代理设置、TUN 接管、域名或进程规则 | 只要系统代理开启就会自动接管 |
| 移动应用 | 应用允许或排除列表、重新联网后的请求 | 系统连接标识代表所有应用都走线路 |
| 命令行工具 | 代理参数、环境变量、工具实际使用的解析路径 | 终端与浏览器共享全部网络设置 |
规则检查要看最终匹配结果，而不只是某条规则写了什么。较早命中的规则可能覆盖后面的选择；策略组也可能仍指向直连或另一条线路。修改后重新发起连接，因为已有会话不一定立即改走新路径。
看似已连接，实际没走的排查顺序
先确认订阅已导入且更新成功，再检查线路是否被当前策略使用。订阅链接是配置入口，不是网页测试地址，也不是安装包链接。导入成功只说明客户端取得了配置；其中协议是否受支持、连接是否成功、应用是否被接管，仍是不同环节。
Shadowsocks、VMess、Trojan、VLESS 是常见代理协议；Hysteria2 与 TUIC 通常使用基于 QUIC 的传输。协议名称本身不会让应用自动进入代理。客户端需要支持对应协议和配置参数，本地网络也需要允许相关传输。IEPL 专线、中转与直连描述线路路径，与协议及本机接管模式不是同一层概念。
- ✅ 浏览器出口没变：查系统代理是否启用、插件是否覆盖设置，以及查询域名是否被直连规则命中。
- ✅ 浏览器能用而应用不能用：查应用自身代理、分应用排除列表与 TUN 路由，不要先反复更换订阅。
- ✅ 所有应用都失败：检查客户端错误日志、当前节点与协议支持情况，再确认本地网络是否允许所用传输。
- ✅ 重启后才生效：检查旧连接和配置重载行为，并记录需要重启的是客户端还是目标应用。
- ✅ 出口正确但目标服务报错：区分路径问题与账户地区、内容授权、风控或服务端故障，不能仅凭报错认定 VPN 没生效。
- ✅ DNS 检测出现意外解析器：对照浏览器安全 DNS、系统解析与客户端规则，确定查询归属后再修改。
WebRTC 检测也需要单独理解。实时通信功能可能通过候选地址暴露额外网络信息，但检测到局域网地址不等于公网流量绕过隧道。如果发现非预期的公网候选地址，应检查浏览器策略与 UDP 接管；仅通过普通网页的出口测试，不能证明所有实时通信路径都符合目标。
断线与切网后的复核
“连接时生效”和“断线后仍符合隐私预期”是不同问题。允许自动直连的配置，在节点不可用时可能恢复本地访问；具备断线阻断选项的客户端，也需要确认该选项已启用并覆盖所需范围。不要把所有客户端都默认视为带有此功能。
用非敏感测试页面观察节点暂时不可用时的行为，核对新请求是失败、切换策略还是转为直连。手动退出客户端与节点意外断开可能触发不同逻辑，测试记录里应写清场景。设备休眠恢复、切换网络后，再重复出口与目标应用验证，检查连接是否重建。
若需要提交工单，保留客户端名称、系统版本、连接模式、问题发生时间、目标域名和相关错误信息即可。截图前遮住订阅链接、令牌、账户信息与不必要的访问记录；不要为了复现把完整配置贴到公开讨论区。VPNHO 用户可从客服工单提交排查材料。
判断结论：当目标请求的出口、DNS 解析路径、应用接管范围与规则设计一致，才能说该场景下 VPN 已生效。浏览器检测通过，只证明该次浏览器请求；断线保护和其他应用仍需分别核对。
把检查结果整理成简单交接记录：本地网络、所选线路、接管模式、目标应用、出口结果、DNS 结果与断线行为。下一次出现问题，先与记录比较，比同时改协议、DNS 和规则更容易定位。需要了解客户端入口与导入流程，可查看使用教程；线路类型与协议用途分别见线路列表和协议详解。