确认生效：连接状态不是最终证据
VPN 连上了怎么确认生效？先查出口 IP，再查 DNS，最后按应用验证。只有目标应用的新请求确实命中预期线路，才能判断该应用已生效；客户端的连接图标，只能说明某个连接环节已经建立。
代理客户端可能只是启动了本地监听，也可能完成了远端握手，但尚未接管浏览器以外的流量。规则模式还会主动让部分网站直连。因此，“所有查询结果都必须变化”不是正确标准。应先写清预期：哪个应用、访问哪个域名、应该直连还是经由线路。
连接前后怎么查出口 IP
使用同一个可信的公网 IP 查询工具做对照。连接前记录地址、地址族、运营商或网络归属；连接后重新发起查询。不要把设备设置中的局域网地址当作公网出口，也不要只凭地图上的城市名称判断。
- 建立基线。断开线路，确认没有其他代理扩展接管浏览器，再查询公网 IP。记录正在使用的网络，避免测试期间切换网络造成误判。
- 连接目标节点。确认客户端当前模式，以及查询网站应命中的规则。若规则本来要求该网站直连，出口不变就不构成故障。
- 重新发起请求。重新打开查询页面并刷新结果，同时查看客户端连接列表。必要时重启浏览器，以排除已有连接复用的干扰。
- 交叉核对。换用独立查询来源，比较地址和网络归属。地理数据库可能更新不同步，城市标签不一致不能单独证明节点位置异常。
如果当前网络同时提供 IPv4 与 IPv6，应分别确认它们的去向。只代理其中一种地址族时，网站可能优先通过另一种地址族连接。此时某个查询页面显示出口改变，另一个应用却仍然直连，并不矛盾。
DNS 检查：看解析路径，不只看地区
DNS 负责把域名解析成可连接的地址。网站请求经过代理，不代表域名查询也一定经过相同路径。DNS 泄漏通常指本应受隧道或代理策略约束的解析请求，却通过预期之外的本地网络或解析服务发出。
运行 DNS 检测时，工具通常会生成测试域名，再根据收到查询的递归解析器推断解析路径。页面显示的是解析服务的相关信息，不必然是设备直接连接的那台服务器，更不是设备公网出口的另一种写法。
- 先记录连接前结果。保存解析服务的名称与网络归属，便于连接后对照。
- 检查客户端配置。确认是否启用了 DNS 接管、远程解析或按规则选择解析器；不同客户端的名称可能不同。
- 检查浏览器安全 DNS。浏览器可能使用独立的加密 DNS 服务，不沿用系统解析设置。其结果与客户端不同，需要进一步查明连接路径。
- 测试新的域名请求。已有缓存可能让请求不触发新的解析；按系统或客户端文档处理缓存后，再重新检测。
解析器地区与节点地区不同，不等于发生泄漏。公共解析服务可能使用任播网络，检测数据库也可能只标记服务商的注册地点。反过来，解析器显示在目标地区，也不能证明全部应用流量都经由线路。关键是解析器是否符合配置，以及解析请求实际如何发出。
分应用验证：浏览器通过不代表全部通过
系统代理通常是供应用读取的一组代理设置。是否采用它，由应用自身实现决定。浏览器、命令行工具、聊天应用和游戏可能各走各的网络路径；浏览器扩展还可能只接管当前浏览器。
虚拟网卡模式常见名称为 TUN。它通过系统路由接收符合条件的流量，再交给客户端处理，覆盖范围通常更广，但仍受路由排除项、权限、进程规则和地址族配置影响。“开了 TUN”也不能替代实际验证。
| 接管方式 | 常见边界 | 验证重点 |
|---|---|---|
| 浏览器代理扩展 | 一般只影响对应浏览器内的请求 | 查看扩展规则，并单独测试桌面应用 |
| 系统代理 | 应用可能忽略系统设置或使用独立代理 | 核对应用设置与客户端新连接记录 |
| 虚拟网卡模式 | 仍可能存在排除路由与进程绕过 | 检查权限、路由、DNS 接管与地址族 |
| 应用内代理 | 通常仅影响该应用支持代理的功能 | 分别测试登录、内容加载与实时通信 |
让目标应用产生可识别的新请求
先打开客户端连接列表，再启动目标应用，执行刷新内容、加载新页面或重新连接等操作。按时间、域名或进程寻找对应记录，查看匹配规则、出口策略与错误信息。应用进程归属并非所有平台都能显示，缺少进程名时，可用请求时间与目标域名辅助对应。
如果没有记录，先排除旧连接复用、缓存命中和日志过滤，不要直接认定流量泄漏。如果出现明确的直连记录，再检查是否命中了直连规则、应用排除项或独立代理配置。仅有流量计数增长，不能证明增长来自正在测试的应用。
平台差异怎么处理
Windows 与 macOS 上，系统代理和虚拟网卡模式应分别确认；Linux 桌面代理设置也未必会传递给命令行程序。Android 客户端可能设置应用包含或排除名单。iOS 则应检查实际使用的客户端配置与系统 VPN 状态，不能照搬桌面端菜单。具体入口以客户端文档和当前界面为准。
看似已连接，实际没走的常见原因
订阅已导入，但运行配置没有切换
订阅链接是获取节点与相关配置的入口，不是接管流量的开关。更新订阅后，仍需确认当前启用的配置、选中的节点和代理模式。有些客户端会把新配置保存下来，但继续运行原来的配置。
规则判断与用户预期不同
规则可能依据域名、目标地址或进程决定去向，通常按客户端规定的优先顺序匹配。应用登录与内容加载还可能使用不同域名。遇到“能登录但内容打不开”，应分别检查失败请求，不要只添加应用首页域名后就认为已经覆盖全部功能。
旧连接、其他代理或权限造成干扰
切换节点不会保证已有长连接立即迁移。可以先重连目标应用，再观察新连接。若同时运行其他 VPN、代理扩展或企业网络客户端，还可能出现设置覆盖、路由竞争或访问限制。只在有权限调整的环境中逐项排查，不要擅自停用组织要求的安全配置。
混淆线路类型与流量接管
IEPL 专线、中转和直连描述的是线路路径或组织方式，不决定本机应用是否进入代理。Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC 等协议也不能替代规则与路由检查。换用另一条线路可能改变连接表现，却不会自动修正应用绕过代理的问题。
隐私边界：检测通过不等于匿名保证
出口检查能说明某次请求对外呈现的地址，DNS 检查能帮助观察解析路径，但它们不是完整的隐私审计。已登录账户、网站 Cookie、设备特征和应用主动提交的信息，仍可能关联访问行为。匿名无日志属于服务的隐私策略表述，不能由一次 IP 查询来证明。
浏览器的 WebRTC 检测也需要结合上下文理解。页面出现本地接口信息、经隐私处理的主机名或公网候选地址，含义不同；不能把任何地址字段都视为公网出口泄漏。若出现不符合预期的公网地址，应结合浏览器策略与客户端的 UDP 接管情况复查。
提交排障材料时，保留模式、规则名称、报错时间和必要的目标域名即可。分享截图前遮挡订阅链接、访问令牌、账户信息与不相关的访问记录。订阅链接可能包含认证信息，不应粘贴到公开检测页面或讨论区。
检查清单与结果判断
- ✅ 已记录未连接时的公网出口，并在相同网络下完成连接后对照。
- ✅ 已确认查询网站命中的规则，而不是默认它必须经过代理。
- ✅ 已检查当前可用的地址族，并核对 DNS 与浏览器安全 DNS 的配置。
- ✅ 已让目标应用发起新请求，并在客户端中核对对应路径。
- ✅ 已区分旧连接、缓存命中、应用独立设置与真正的直连绕过。
- ✅ 已保存必要的排障信息，且未公开订阅凭据。
若仍无法定位，可先按使用教程核对导入与接管设置，再到支持页面提交经过脱敏的连接记录。若路径已经符合预期，但目标平台仍拒绝访问，应继续检查平台地区政策、账户资格与当前出口判定，不要把所有访问失败都归因于线路未生效。