出口 IP：最先能确认的一项
连上之后，先打开站内的 IP 查询页面，看当前的出口 IP 与归属地。判断标准只有一条：归属地应该是节点所在地，而不是本地运营商。如果归属地仍是本地城市、组织名仍是本地宽带运营商，说明流量根本没有进入隧道，客户端上的状态灯只能证明进程在运行。
出口 IP 还要看两处细节。第一处是 IPv6：浏览器与系统默认优先使用 IPv6，如果客户端只接管了 IPv4，页面可能直接显示本地 IPv6 地址，看起来「IP 变了」，其实只变了一半。第二处是 WebRTC：部分浏览器会通过 WebRTC 暴露本机地址或本地网络地址，这与代理是否生效无关，需要在浏览器设置里限制或关闭。
只在 IPv4 上生效的连接，遇到支持 IPv6 的目标站点会直接回落本地网络。自查时先看 IP 查询页是否同时给出 IPv4 与 IPv6 结果，再确认两边的归属地是否一致。
如果同一台设备上还装着浏览器代理扩展，扩展的优先级通常高于系统代理。此时系统层面已经接管，浏览器却仍在用扩展里的线路，两边出口不同，很容易得出错误结论。验证时先停用扩展，或者用一个没有安装任何扩展的浏览器配置对照一次。
DNS 泄漏自查
DNS 查询决定「访问的域名由谁解析」。系统默认把查询发给本地运营商；代理生效后，查询应该改由节点一侧发出。如果查询仍然送到本地 DNS，解析请求本身就暴露了要访问的目标，同时可能拿到离本地更近、对目标站点并不合适的 CDN 结果。
自查方式是打开 DNS 泄漏检测页，页面会列出参与解析的服务器 IP 与归属。合格的状态是解析器落在节点所在地，或至少与出口 IP 处在同一区域；如果列出的全是本地运营商的解析服务器，说明解析没有走代理。
客户端里对应的开关通常叫「远程 DNS」「DNS 走代理」或「防泄漏」，不同客户端措辞不同，作用一致：把解析请求交给隧道另一端的解析器。开启后要重新连接一次再看检测结果，改完不重连往往不生效。
规则模式里，国内域名走本地 DNS 解析、直连访问本身就是设计目标。判断泄漏要看被代理的那部分域名——目标站点走代理、解析却留在本地，才是需要处理的情况。
还有一种情况是应用自带的加密 DNS。浏览器或系统开启 DoH / DoT 之后，解析请求走独立的 HTTPS 连接，可能绕开客户端设置的 DNS。这类选项在浏览器的隐私设置里，验证时先关掉，确认基线状态之后再决定是否恢复。
分应用与分流验证
出口 IP 与 DNS 都正确，仍然可能有个别应用没走代理。原因有两类：应用不读取系统代理设置，或者分流规则把目标域名判成了直连。
系统代理（HTTP / SOCKS 代理）依赖应用主动读取系统设置。浏览器、系统更新、多数命令行工具会读，部分桌面应用和游戏客户端不读。要覆盖这些程序，需要客户端提供 TUN 或虚拟网卡模式，在网络层接管流量，代价是需要更高权限，部分系统上还要额外安装网络组件。
分流验证的做法是：先用全局模式确认基础链路通畅，再切回规则模式，逐个打开实际要用的服务。如果全局模式正常、规则模式下某个服务异常，问题在规则而不在线路。规则列表里一般能看到命中的条目与走向，按域名或 IP 段补一条规则即可。
分应用代理在部分平台可用。开启之后只有勾选的应用走隧道，其余应用直连。这种模式适合把工作软件排除在外，但验证时容易误判：没有勾选的应用显示本地 IP 是预期行为，不是故障。
订阅导入也要一并检查。订阅链接更新后，客户端里的节点列表应随之刷新；如果节点名称与数量长时间不变，可能是订阅没有拉取成功，或者客户端仍在用旧的配置文件。节点列表里延迟显示为超时，说明握手没有完成，换一条线路再测一次。
看起来已连接却没走代理的六种情况
下面几种情况在排查里出现频率最高，共同点是客户端界面都显示「已连接」。
- 系统代理没有写入。部分客户端需要手动开启「设置系统代理」，只连接线路不会改动系统设置，浏览器之外的流量全部直连。
- 浏览器扩展覆盖了系统代理。扩展的优先级更高，两个出口同时存在，IP 查询结果取决于当前用的是哪一个。
- IPv6 优先。隧道只接管 IPv4 时，支持 IPv6 的目标站点会由浏览器直接连接本地网络。
- 分流规则命中直连。规则按域名匹配，目标域名被归入直连分组，出口自然还是本地。
- 应用忽略系统代理。桌面应用、游戏客户端、部分同步工具不读系统代理设置，必须靠 TUN 模式覆盖。
- 应用自带加密 DNS 或独立网络栈。解析与连接都不经过系统设置，系统代理对它没有作用。
不同平台客户端的差异
Windows：系统代理与 TUN 两种模式
系统代理模式改动的是系统代理项，浏览器和多数应用跟随；TUN 模式创建虚拟网卡，能接管不读系统代理的程序，需要管理员权限。切换模式之后必须重新连接，否则旧模式残留的设置还在生效。
macOS 与 iOS：授权没给等于没连
macOS 上使用网络扩展的客户端会在系统设置里请求授权，未授权时连接看似成功，实际没有接管流量。iOS 走 Network Extension，首次连接必须在系统弹窗里确认，拒绝之后客户端内的开关不起作用。
Android：分应用列表要自己核对
Android 基于系统的 VpnService，同样需要弹窗授权。它的分应用代理更细，验证时逐项核对勾选列表，比只看总开关更可靠。
协议差异：TCP 与 UDP 的表现不同
Shadowsocks、VMess、Trojan、VLESS 以 TCP 为主，UDP 支持取决于具体实现；Hysteria2、TUIC 基于 QUIC，全程走 UDP。客户端里看到的 ss://、vmess://、trojan:// 前缀就对应不同协议。网络对 UDP 限制严格时，表现是节点能选中、一直连不上，换回 TCP 类协议就能判断问题出在哪一层。
一张自查表与判断标准
把上面的检查项合成一张表，按现象对照处理即可。
| 现象 | 可能原因 | 处理 |
|---|---|---|
| IP 查询显示本地运营商 | 系统代理未写入，或 TUN 未启动 | 检查代理模式，重新连接 |
| IP 正确，解析器仍在本地 | DNS 没有走代理 | 打开远程 DNS / 防泄漏开关后重连 |
| 只有浏览器走代理 | 系统代理模式覆盖不到其他程序 | 切换到 TUN / 虚拟网卡模式 |
| 目标站点仍判定为本地 | 分流规则命中直连 | 检查规则列表，补充域名规则 |
| IPv6 地址仍是本地 | 隧道只接管了 IPv4 | 关闭系统 IPv6，或启用 IPv6 代理 |
| 节点可选但一直超时 | 协议或端口被限制 | 换线路，或换用 TCP 类协议 |
逐项对照下面的结果，全部成立才算真正生效。
- ✅ 出口 IP 归属地为节点所在地，IPv4 与 IPv6 结果一致。
- ✅ DNS 检测页里的解析器与出口 IP 处在同一区域。
- ✅ 全局模式下目标服务正常，切回规则模式后仍然正常。
- ✅ 不读系统代理的桌面应用，在 TUN 模式下同样显示节点 IP。
- ❌ 只有浏览器显示节点 IP，系统级应用仍是本地地址——说明只写入了系统代理，没有接管全局流量。
- ❌ 检测页显示已代理，解析器却全是本地运营商——说明 DNS 没有跟着走。
判断标准：不需要看客户端的状态灯，只需要三处证据同时成立——出口 IP 在节点一侧、DNS 解析在节点一侧、实际要用的应用确实走了隧道。三者缺一，就按上面的表逐项排查，问题通常出在代理模式与分流规则，而不是线路本身。
需要对照多条线路时，可选范围是 100+ 国家与 220+ 线路；不限台数意味着可以让电脑与移动设备同时在线对照，其中一端保持默认设置、另一端改成分流模式，差异会非常直观。订阅周期内如果发现某条线路长期超时，直接换线路比反复重装客户端更省时间。
如果自查全部通过、目标服务仍然异常，问题多半在目标站点一侧的策略，而不是本地连接。这时换一条同地区的线路做交叉验证，比继续在客户端里反复改设置更有效率；需要逐项复现操作时，可以参考使用指南里的客户端配置说明。