确认 VPN 真的生效，不能只看客户端里的“已连接”。这个状态通常只能说明客户端与远端线路完成了握手，无法证明浏览器、桌面软件、命令行工具和 DNS 查询都经过了预期路径。可靠的判断方法是依次检查出口 IP、DNS 解析、路由模式和具体应用，并把连接前后的结果放在一起比较。
如果出口地址发生变化，但某个应用仍显示原来的网络位置，问题通常不在线路握手，而在系统代理、TUN 模式、分流规则、缓存连接或应用自身的网络实现。反过来，如果页面可以正常打开，也不能直接推断全部请求都经过线路：规则模式可能只转发特定域名，其他流量仍按本地网络直连。
先理解“生效”包含哪些部分
VPN 是否生效并不是单一开关。完整连接至少涉及线路握手、系统路由、名称解析和应用流量。任何一层没有按预期工作，都可能出现界面显示正常、实际路径异常的情况。
| 检查对象 | 要确认的结果 | 常见异常 |
|---|---|---|
| 客户端状态 | 配置已加载，线路握手完成，没有持续重连 | 订阅过期、节点不可达、系统时间异常或协议参数不匹配 |
| 出口 IP | 连接后的公网出口与连接前不同，并符合所选地区 | 应用绕过代理、规则命中直连、旧连接未释放 |
| DNS 解析 | 解析请求符合客户端设定的本地、远端或加密 DNS 策略 | 系统缓存、浏览器独立解析、局域网解析器继续接管 |
| 具体应用 | 需要经过线路的应用实际使用了对应出口 | 应用不读取系统代理、仅部分协议被接管、分应用规则配置错误 |
| 协议与地址族 | TCP、UDP、IPv4 与 IPv6 按当前配置处理 | 只接管其中一类流量，另一类仍从本地网络发出 |
不同客户端对这些层的控制能力并不相同。桌面端常见的“系统代理”主要修改操作系统的代理设置，只有主动读取这些设置的应用才会跟随。TUN 模式则创建虚拟网络接口，通过路由表接管更广泛的网络流量，更适合不支持代理设置的软件，但通常需要相应的系统权限。
移动端客户端一般使用系统提供的 VPN 接口统一接管流量，不过仍可能受到分应用排除、按需连接、私有 DNS 或应用内加密 DNS 的影响。因此，同一份 Shadowsocks、VMess、Trojan、VLESS、Hysteria2 或 TUIC 配置，在不同平台上的“已连接”并不意味着接管范围完全一致。
出口 IP 检查的正确顺序
出口 IP 是最直观的验证入口，但必须先记录未连接状态，才能进行可靠对比。只在连接后打开查询页面，看见一个陌生地址，并不足以证明结果属于当前线路；企业网络、共享网络和上游代理本身也可能让公网地址与设备局域网地址不同。
- 断开客户端。完全退出已有连接，关闭可能自动重连的按需规则。
- 记录基线。查看当前公网出口、网络提供方和大致地区，不要把完整地址发布到公开截图中。
- 重新连接。选择容易辨认的地区线路，等待客户端状态稳定。
- 新建会话。使用新的浏览器隐私窗口，避免旧页面、缓存和长连接干扰判断。
- 再次查询。对比出口地址、地区和网络归属是否随线路变化。
- 切换线路复查。换到另一个线路组后重新加载，确认结果不是查询页面缓存。
- ✅ 连接前后出口地址不同，地区与所选线路一致，可以继续检查 DNS 与应用流量。
- ✅ 浏览器和系统网络工具得到相同出口，说明接管范围较一致。
- ❌ 地址完全不变，需要检查当前规则是否把查询域名设为直连。
- ❌ 只有浏览器地址变化，其他软件不变，通常表示当前使用的是系统代理而不是完整流量接管。
- ❌ 切换线路后仍显示旧地区，可能是页面缓存、连接复用或旧进程没有关闭。
还要分别观察 IPv4 与 IPv6。部分本地网络同时提供两种地址，而客户端可能只接管 IPv4。此时普通查询看起来已经切换出口，但支持 IPv6 的应用仍可能优先走本地路径。处理方法不是简单关闭所有网络能力，而是先确认客户端是否支持 IPv6 接管；如果不支持，再按客户端文档决定禁用、阻断或交给规则处理。
DNS 解析是否按预期处理
浏览器访问域名之前，通常需要先把域名解析为 IP 地址。DNS 泄漏通常指本应交给线路内解析器或指定加密解析器的请求，却继续发送给本地网络提供的解析服务。它不会必然导致网页打不开，但会暴露查询过的域名范围，并可能造成解析结果与线路地区不一致。
判断 DNS 是否异常，不能只看检测页面列出的解析器名称。现代客户端可能使用公共 DNS、DoH、DoT、远端解析或按域名分流；浏览器也可能启用自己的安全 DNS。这些结果未必与出口线路属于同一家网络。真正需要确认的是：检测结果是否符合当前配置，而不是解析器名称是否和出口 IP 完全相同。
建立可解释的 DNS 结果
先打开客户端的 DNS 配置，确认当前策略属于哪一种：由系统解析、通过远端线路解析、使用指定加密 DNS，还是根据域名规则分别处理。随后清理旧缓存，重新发起查询。不同桌面系统可使用对应的缓存刷新命令：
Windows:
ipconfig /flushdns
macOS:
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
Linux with systemd-resolved:
resolvectl flush-caches刷新系统缓存后，还应关闭并重新打开浏览器，因为浏览器可能维护独立缓存和连接池。如果浏览器启用了自己的加密 DNS，系统命令不会清除其全部状态，需要在浏览器网络设置中确认解析策略。
- ✅ 解析器与客户端设定一致，查询结果随配置切换而变化。
- ✅ 本地域名按本地规则解析，国际域名按远端规则解析，结果与分流设计一致。
- ❌ 客户端设定远端解析，但检测结果始终只有本地网络解析器。
- ❌ 浏览器与命令行解析结果长期不同，需要检查浏览器独立 DNS 设置。
- ❌ 切换线路后域名仍返回明显过期的地址，需要清理系统、浏览器和应用缓存。
分流 DNS 比单一解析路径更复杂。例如，本地域名可以由本地解析器处理并直接访问，其他域名由远端解析后经过线路。这种情况下，检测页面同时显示不同来源的解析请求不一定代表泄漏。判断重点应放在规则是否符合预期、需要远端解析的域名是否被错误送到本地。
逐个应用验证流量路径
出口 IP 和 DNS 都正常后，下一步是逐个验证实际使用的软件。浏览器能走线路，不代表游戏、下载器、终端、同步工具和桌面客户端也会读取相同代理设置。尤其在系统代理模式下，部分应用会直接建立连接，完全忽略操作系统代理。
浏览器
浏览器通常最容易验证，但也最容易受到扩展、独立代理设置、安全 DNS 和连接复用影响。排查时先停用会修改网络路径的扩展，再使用新的隐私窗口测试。若一个浏览器结果正常、另一个异常，应比较两者的代理与 DNS 设置，而不是立刻更换节点。
命令行与开发工具
命令行工具是否走代理，取决于工具本身、环境变量和系统实现。有些工具读取代理环境变量，有些需要显式指定代理，还有些在 TUN 模式下才会被透明接管。测试时应同时查看客户端连接日志，确认请求是否命中代理规则、直连规则或拒绝规则。
桌面软件与移动应用
桌面软件可能使用自带网络栈，移动应用也可能建立独立的 QUIC 或其他 UDP 会话。如果当前节点协议或客户端模式只接管 TCP，相关请求可能继续直连或直接失败。Hysteria2 与 TUIC 以 UDP 为传输基础，不代表启用这类协议后所有应用 UDP 都必然被接管；应用流量是否进入隧道，仍由客户端路由和 TUN 配置决定。
分应用与绕过规则
部分客户端允许指定哪些应用经过线路，哪些应用保持直连。排查时要同时查看“包含”和“排除”列表，注意应用更新后可执行文件路径或包标识可能变化。若规则仍引用旧路径，新版本程序可能不再命中原有策略。
| 现象 | 优先检查 | 处理方向 |
|---|---|---|
| 浏览器正常，终端直连 | 系统代理、代理环境变量、TUN 模式 | 为工具设置代理，或改用能够接管该流量的模式 |
| 网页正常，应用内请求失败 | UDP、QUIC、证书校验、分应用规则 | 检查协议支持与应用是否被排除 |
| 部分网站走线路，部分直连 | 规则模式、域名分类、进程规则 | 查看规则命中日志，确认是否属于预期分流 |
| 切换节点后应用仍显示旧出口 | 长连接、后台进程、连接池 | 完全退出应用后重开，必要时断开并重连网络 |
| IPv4 正常，IPv6 保持本地出口 | 客户端地址族支持、系统路由 | 启用对应接管能力，或按配置阻断未受保护的路径 |
显示已连接但流量没走线路的原因
最常见的原因是客户端只建立了到节点的连接，却没有成功修改系统代理或路由。权限不足、虚拟网卡初始化失败、其他网络工具覆盖设置，都可能造成控制层在线而数据层未接管。此时应先查看客户端日志，而不是反复点击连接按钮。
系统代理与 TUN 模式选错
只需要浏览器和支持代理的软件时，系统代理通常更简单。需要接管不读取代理设置的应用时，TUN 模式更合适。两者并非速度档位，而是不同的流量入口。开启 TUN 后仍应确认虚拟接口已经建立、默认路由或策略路由已经写入。
分流规则命中了直连
规则模式会根据域名、IP、进程或规则集决定路径。查询出口的网站如果被归入直连，检测结果自然不会变化。排查时切换到全局代理仅适合作为短暂对照：如果全局模式正常，说明线路本身大概率可用，问题集中在规则；验证完成后应恢复符合需求的分流模式。
旧连接没有释放
浏览器、聊天软件和同步工具会维持长连接。线路切换不会总是强制这些连接立即重建，因此应用可能暂时继续沿用旧路径。完全退出应用并重开，比只刷新页面更可靠。对于后台常驻进程，还要确认进程确实结束。
多个网络工具争用设置
同时运行企业 VPN、调试代理、网络过滤软件或另一个线路客户端时，后写入的路由和代理设置可能覆盖先前配置。排查阶段应保留必要工具，暂停其他会修改网络路径的程序，再逐项恢复，以确定冲突来源。
订阅配置没有更新
订阅链接负责向客户端提供节点与规则信息。服务端配置发生调整后，本地客户端仍可能保留旧副本。应在客户端内执行订阅更新，确认更新成功后再重新选择线路。订阅链接属于访问凭据，不应粘贴到公开检测网站或问题截图中。
线路类型如何影响排查结论
直连、中转和 IEPL 专线描述的是到线路入口及出口之间的网络路径，不等同于客户端接管方式。直连线路由设备直接连接远端节点，路径简单，但更依赖本地网络到目标地区的公网质量。中转线路先连接较近的入口，再由中间网络送往出口，可能改善部分网络环境下的路由稳定性。
IEPL 专线通常指入口与出口之间使用专用承载或受控链路，重点在跨区域传输路径。无论使用哪种线路，设备端仍要正确完成系统代理、TUN、DNS 和分流配置。专线不会自动修复应用绕过代理，也不能替代出口 IP 与 DNS 验证。
协议同样不能单独决定是否生效。Shadowsocks、VMess、Trojan 与 VLESS提供不同的传输和认证方式，Hysteria2 与 TUIC侧重基于 UDP 的传输机制；真正决定应用请求是否进入线路的，仍是客户端如何建立本地入口并应用路由规则。节点握手成功而应用直连，通常应先查本地接管层，而不是直接认定远端节点故障。
一套可重复的完整验证流程
临时打开一个查询页面只能得到瞬时结果。更稳妥的做法是建立固定检查流程，每次更换客户端、导入订阅、调整 DNS 或修改分流规则后都按同样顺序执行。这样可以快速判断变化发生在哪一层。
- 更新配置。在可信客户端内更新订阅，确认线路与规则成功载入。
- 记录未连接基线。保存出口地区、地址族和当前 DNS 策略，不公开完整网络标识。
- 建立连接。观察日志是否完成握手，是否出现持续重试或虚拟接口错误。
- 检查出口。使用新会话比较连接前后 IP，并分别关注 IPv4 与 IPv6。
- 检查 DNS。确认解析器与客户端策略一致，排除系统和浏览器缓存。
- 检查规则命中。查看测试域名和应用被判定为代理还是直连。
- 逐个应用验证。覆盖浏览器、终端、桌面软件和需要使用的移动应用。
- 切换线路复查。确认应用会建立新连接，出口结果能随线路变化。
- 恢复日常模式。如果为了排查临时使用全局代理，完成后恢复所需的分流配置。
- ✅ 客户端握手稳定，日志没有循环重连。
- ✅ 出口结果与所选线路一致，地址族没有意外绕过。
- ✅ DNS 查询符合本地、远端或加密解析策略。
- ✅ 需要经过线路的应用均命中代理规则。
- ✅ 应保持直连的本地服务仍按规则访问。
- ❌ 只看连接图标，没有核对实际出口与规则日志。
如果完整流程中只有某个应用失败，应优先收集该应用名称、操作系统、客户端模式、节点协议、规则命中结果和错误日志。若所有应用都无法切换出口，则优先检查系统代理、TUN 接口、路由冲突和订阅配置。把问题限定在具体层级后，排查效率会明显高于反复换节点。