确认 VPN 真的生效，不能只看客户端里的“已连接”。这个状态通常只说明本地客户端与远端节点完成了握手，或者系统已经建立虚拟网络接口。至于浏览器、命令行、游戏和其他应用是否经过预期出口，还要分别核对出口 IP、DNS 解析路径与分流结果。
一次可靠的检查应该回答几件事：公网看到的地址是否变化，地址归属是否符合所选地区，域名查询交给了谁，目标应用是否进入代理，以及断线后流量会不会悄悄回到原网络。只查其中一项，很容易得到“看起来正常”的半个答案。
先定义什么叫真正生效
“生效”不是单一状态，而是从应用到远端出口的一整条路径都符合配置。客户端握手成功只是路径入口。系统路由、代理模式、DNS 设置和应用自身网络栈，任何一处绕开配置，最终结果都可能不同。
| 检查层 | 要观察的结果 | 常见误判 |
|---|---|---|
| 客户端连接 | 节点握手完成，虚拟接口或本地代理端口正常工作 | 把“握手成功”直接等同于所有流量已转发 |
| 公网出口 | 目标应用展示预期的出口地址、地区与网络归属 | 只看地图标签，不核对运营方或地址族 |
| DNS 解析 | 域名请求按照客户端或系统规则送往预期解析器 | 出口已改变，却仍由本地网络直接完成解析 |
| 分应用路由 | 应代理的应用进入线路，应直连的应用保持直连 | 只测试浏览器，默认其他程序结果相同 |
| 异常回退 | 节点断开后的行为符合阻断或回退设置 | 断线后自动直连，却仍以为保护持续有效 |
因此，最小可用的验证闭环是“连接前记录、连接后比较、按应用复查、断线后观察”。如果出口与 DNS 都正确，但某个应用仍显示原网络，问题通常不在线路本身，而在系统代理覆盖范围、应用代理设置或分流规则。
用出口 IP 检查公网看到的你
出口 IP 是最直观的一层。连接前后，在同一浏览器会话中打开可靠的 IP 查询页面，比较公网地址、国家或地区、自治系统与网络运营方。地区符合预期但运营方完全出乎意料时，不一定代表异常，因为数据中心地址、家庭宽带地址和移动网络地址的登记方式不同；但至少应与所选线路的性质相符。
检查时不要只盯着地图上的定位点。IP 地理数据库并非实时更新，同一个地址段在不同数据库中可能被标成相邻城市，甚至显示为网络运营方的注册地。对跨境线路而言，国家或地区、自治系统和服务可访问结果通常比城市级定位更有参考价值。
同时检查 IPv4 与 IPv6
有些客户端只接管 IPv4，而设备仍可通过原网络直接发送 IPv6 请求。此时普通查询页面可能恰好使用代理后的 IPv4，看起来已经切换；支持 IPv6 的应用却可能走另一条路径。检查页面如果同时展示两种地址族，应分别确认。客户端没有处理 IPv6 时，可以按实际需求关闭该地址族，或改用能够完整接管系统流量的模式。
排除浏览器缓存与旧连接
浏览器可能复用连接前建立的会话。切换节点后立即刷新，旧连接未必立刻重建。更稳妥的做法是关闭相关页面，等待旧会话结束，再开新的隐私窗口检查。命令行工具也适合交叉验证，因为它能绕开部分浏览器扩展、缓存与安全 DNS 设置。
- 断开客户端，记录当前公网地址、地区与网络归属。
- 连接目标节点，确认客户端没有持续重连或握手报错。
- 重新打开查询页面，比较出口地址与地址族。
- 再用另一个不共享浏览器配置的工具复查。
- 切换节点后重复检查，确认出口确实随线路改变。
检查DNS 解析 是否绕回本地网络
访问网站前，设备通常要先把域名解析为地址。网页内容经过国际线路，不代表域名查询也经过同一路径。如果 DNS 请求直接交给当前网络提供的解析器，外部仍可能观察到你查询了哪些域名；解析结果还可能与出口地区不一致，造成内容分区错误或连接到不合适的服务节点。
DNS 检查页面通常会列出参与解析的服务器及其网络归属。连接后看到本地网络运营方的解析器，需要继续排查；但看到与 VPN 出口不同的运营方也不一定是泄漏，因为公共解析服务会使用分布式节点，页面显示的可能是递归解析器出口，而不是你的实际位置。
浏览器安全 DNS 会改变观察结果
现代浏览器可以自行使用加密 DNS，不完全遵循系统设置。于是同一设备上，浏览器检测结果与命令行结果可能不同：浏览器把查询交给自己的解析服务，其他应用仍使用系统 DNS。检查时应先确认浏览器是否启用了独立的安全 DNS，再决定这是预期配置还是绕开了客户端规则。
Fake IP 与远程解析不能按表面地址判断
部分 TUN 客户端使用 Fake IP 机制，先给域名分配一个保留用途的映射地址，再由客户端在内部恢复域名并交给远端解析。应用看到的并不是网站真实地址，但请求仍可能正确经过隧道。此时不要仅凭本地解析结果判定异常，应检查客户端日志中的域名匹配、DNS 上游与最终路由。
- ✅ 连接前后分别运行 DNS 检查，并记录解析器的网络归属。
- ✅ 对比浏览器与系统工具，确认两者是否使用不同解析路径。
- ✅ 查看客户端 DNS 模式、远程解析设置与分流规则是否一致。
- ✅ 检查 IPv4、IPv6 查询是否都受到预期策略约束。
- ❌ 不要因为解析器地区与节点城市不同，就直接认定发生泄漏。
- ❌ 不要在浏览器启用独立安全 DNS 后，仍把结果当作系统 DNS 状态。
按浏览器、命令行与应用逐项验证
浏览器能走不代表所有应用都能走。系统代理模式主要影响主动读取系统代理设置的软件；忽略系统代理、自己建立 UDP 会话或使用独立网络栈的程序，可能直接连接。TUN 模式通常覆盖范围更广，因为它通过虚拟网络接口接管 IP 流量，但最终仍受路由表、排除项与系统权限影响。
浏览器
先禁用可能改写代理的扩展，再检查出口与 DNS。若浏览器正常而其他应用不正常，说明节点本身大概率可用，应把注意力转向系统代理覆盖范围和应用设置。若只有某个浏览器异常，还要检查其安全 DNS、代理扩展、缓存连接与企业策略。
命令行与开发工具
终端程序是否继承代理，取决于工具本身及环境变量。某些工具读取 HTTP 或 SOCKS 代理变量，某些工具直接使用系统网络接口。使用本地代理端口时，要区分 HTTP 代理与 SOCKS 代理，也要确认域名是在本地解析还是交给代理端解析。网页访问正常而软件包下载直连，常见原因就是命令行工具没有读取系统代理。
即时通信、游戏与其他独立应用
这类应用可能混合使用 TCP、UDP、长连接与自定义 DNS。只看登录是否成功无法判断整条路径。可以先完全退出应用，连接节点后重新启动，再观察客户端连接日志中的目标域名、地址和命中规则。若规则显示直连，就应调整分流；若规则显示代理但应用仍失败，再检查协议对 UDP 的支持、节点入口和目标服务限制。
分应用代理还有一个容易忽略的方向：规则可能故意让本地服务直连。此时不同应用显示不同出口是设计结果，不是故障。验证目标不是强迫所有请求走同一路径，而是确认每类请求都命中了预期规则。
理解协议与客户端模式 的边界
Shadowsocks、VMess、Trojan、VLESS、Hysteria2 与 TUIC 都可以承载代理流量，但它们不是“安装后自动接管所有应用”的开关。协议负责客户端与服务器之间如何传输数据，系统代理、TUN、路由规则和 DNS 模块才决定哪些本地请求进入这条传输通道。
Shadowsocks 是加密代理协议，通常由客户端提供本地 SOCKS 或 HTTP 入口。VMess 与 VLESS 常见于支持多种传输组合的客户端，其中 VLESS 本身不依靠协议内置加密，通常与 TLS 或其他安全传输配合。Trojan 使用 TLS 承载流量。Hysteria2 与 TUIC 基于 QUIC 思路处理传输，在网络抖动或丢包环境下有不同于传统 TCP 代理的表现，并通常更重视 UDP 能力。
协议名称无法直接证明 DNS 已被接管，也无法证明应用进入代理。即使订阅成功导入，客户端仍可能停留在仅系统代理模式；即使启用了 TUN，排除路由或权限失败也可能让部分流量绕过。判断问题时，应把“协议是否连通”和“系统是否正确导流”分开。
订阅链接与客户端导入
订阅链接通常提供节点名称、服务器入口、端口、认证信息、传输参数与 TLS 相关配置。导入成功只代表客户端读懂了配置，不代表节点可连接，更不代表当前已经选中该节点。更新订阅后，还要检查当前配置是否被替换、分组是否选中了正确线路，以及本地覆盖规则是否仍然生效。
Windows 与 macOS 客户端通常同时提供系统代理和 TUN 选项，但系统权限、路由处理及 DNS 接管方式并不完全相同。Android 常借助系统 VPN 接口建立本地隧道，并可按应用纳入或排除。iOS 同样依赖系统提供的网络扩展能力，后台行为与规则实现取决于具体客户端。跨平台迁移配置时，不应假设同名开关具有完全一致的效果。
直连、中转与 IEPL 专线 会改变什么
线路类型描述的是客户端到出口之间经过怎样的网络路径，不是代理协议。直连表示设备直接连接境外节点入口，路径简单，但质量更依赖公网路由。中转先连接较近的入口，再由服务端转发到最终出口，可以绕开部分不稳定的公网段。IEPL 专线通常指跨境专用承载路径，重点是入口到出口之间的传输组织方式。
无论使用哪种线路，最终验证方法不变：公网出口是否正确、DNS 是否按策略解析、应用是否命中预期出站。线路名称不能替代结果检查。中转入口可能位于本地附近，但公网查询看到的应是最终出口；如果查询显示的是入口地址或原网络地址，就要检查服务端转发和客户端路由。
线路可连接但访问体验异常，也不应马上归因于协议。域名解析可能返回不适合出口地区的地址，分流规则可能把静态资源送去直连，目标网站也可能根据 IP 信誉或账户地区采取不同策略。把出口、DNS、规则命中和应用响应分开记录，比反复切换节点更容易找到原因。
几种看着连上却没走 的典型情况
- ❌ 客户端握手成功，但系统代理开关未启用，浏览器仍使用原网络。
- ❌ 浏览器读取了代理，命令行工具没有读取代理环境，因此下载任务直连。
- ❌ IPv4 经过节点，IPv6 保持直连，支持双栈的应用出现不同出口。
- ❌ 出口已经改变，DNS 仍由当前网络直接解析，地区判断出现错位。
- ❌ 分流规则把目标域名归入直连，客户端日志却只显示节点总体在线。
- ❌ 切换节点后浏览器复用旧连接，短时间内仍展示前一条路径。
- ❌ TUN 权限申请失败，客户端回退到覆盖范围较窄的系统代理模式。
- ❌ 节点断开后自动回退直连，应用继续工作，让人误以为隧道仍在。
遇到这些情况，先不要同时改协议、节点、DNS 和分流。一次只改一个变量，然后重复同一套出口与解析检查。否则即使问题消失，也很难知道是哪项设置真正起作用，下次故障还要从头猜。
建议保留的检查顺序
- 保存连接前的出口与 DNS 基线。
- 确认订阅已更新，并选中了目标节点或策略组。
- 确认当前使用系统代理还是 TUN，以及相应权限是否正常。
- 检查 IPv4、IPv6 出口和 DNS 解析路径。
- 分别测试浏览器、命令行与目标应用。
- 查看规则命中、出站选择与错误日志。
- 主动断开节点，确认应用是阻断还是回退直连。
完整自查的核心并不复杂：先确认公网看到哪个出口，再确认域名由谁解析，最后确认具体应用命中了哪条规则。连接图标适合告诉你“客户端开始工作了”，不适合替整条网络路径签字。网络不会读心，配置也不会。