判断 VPN 是否生效，不能只看客户端是否显示“已连接”。更可靠的方法是同时检查出口 IP、DNS 解析路径以及实际应用的流量去向。连接状态只说明客户端完成了某个网络会话；系统代理、虚拟网卡、分流规则或应用自身设置仍可能让部分请求沿原网络发出。
一次完整检查应当回答几个不同问题：公网访问使用了哪个出口，域名查询交给了哪个解析器，浏览器与命令行是否走相同路径，以及目标应用有没有绕开系统代理。把这些结果放在一起，才能区分“线路没有建立”“仅部分流量被接管”和“线路正常但网站判断异常”。
客户端显示已连接，不等于所有流量都已接管
Shadowsocks、VMess、Trojan、VLESS、Hysteria2 与 TUIC 等协议负责建立传输通道，但客户端还需要决定哪些系统流量进入该通道。常见接管方式包括系统代理、虚拟网卡模式和应用内代理。协议握手成功，只能说明本地客户端与远端节点之间具备通信条件，并不能单独证明每个程序都采用了这条路径。
系统代理通常只影响遵循操作系统代理设置的应用。浏览器大多会读取该设置，但某些命令行工具、游戏、下载程序或自带网络栈的应用可能直接连接。虚拟网卡模式会在更低的网络层接管流量，覆盖范围通常更广，不过仍会受到路由表、排除列表和局域网规则影响。应用内代理则只对配置过的程序生效。
因此，测试时需要避免把“浏览器可以访问”直接等同于“整台设备已经走线路”。反过来，某个应用连接失败，也不一定表示节点失效；它可能没有读取系统代理，或者其使用的协议被当前规则设为直连。
| 观察结果 | 可能原因 | 下一步检查 |
|---|---|---|
| 浏览器出口变化，终端不变 | 仅启用了系统代理 | 检查终端代理变量或虚拟网卡模式 |
| 出口变化，DNS 仍走本地网络 | 解析请求未被线路接管 | 检查客户端 DNS 与加密 DNS 设置 |
| 部分网站走线路，部分网站直连 | 分流规则正在生效 | 查看域名、IP 与规则集匹配记录 |
| 所有测试均无变化 | 代理未应用或路由未建立 | 检查系统代理、虚拟网卡和默认路由 |
先用出口 IP 确认公网流量路径
出口 IP 是目标网站看到的公网来源地址。未连接线路时，它通常对应当前网络的公网出口；连接后，如果测试请求确实经过远端节点，页面或接口显示的地址应随出口位置发生变化。这里只需要比较前后结果，不应仅凭地址所属国家或运营商名称判断质量。
测试前应暂时关闭浏览器缓存影响，并确保检测页面重新发起网络请求。建议在普通窗口与无扩展干扰的窗口中分别确认，因为代理扩展可能覆盖系统设置。若设备同时具备 IPv4 与 IPv6 连接能力，还要分别观察两类地址；只检查其中一种，可能遗漏另一类流量仍沿原网络发送的情况。
命令行可以作为浏览器之外的独立参照。以下命令会请求公开的出口查询接口：
curl https://api.ipify.org如果浏览器结果已经变化，而命令行仍返回连接前的出口，通常说明当前方案只设置了浏览器或系统代理，而命令行工具没有读取代理配置。在启用虚拟网卡模式后重新执行，可以进一步判断操作系统路由是否已被接管。使用应用内代理时，也可在命令中明确配置代理后再比较。
出口 IP 所属地数据库可能存在更新延迟，不同查询服务给出的城市或网络名称也可能不一致。判断是否生效时，应把重点放在“地址是否改变”以及“不同应用是否一致”，而不是要求所有数据库显示完全相同的位置。
DNS 检查要看解析请求去了哪里
访问域名之前，设备通常需要通过 DNS 查询获得目标地址。如果网页流量进入线路，但 DNS 请求仍直接交给本地网络提供的解析器，便可能形成解析路径与访问路径不一致的情况。行业中常把意外绕过预期线路的解析请求称为 DNS 泄漏。
不过，检测页面显示了本地解析器，并不总能直接证明客户端故障。现代浏览器可能启用加密 DNS，操作系统可能使用缓存，客户端也可能采用远端解析、映射地址或内置 DNS 模块。企业网络、家庭网关和安全软件还可能重写解析路径。因此应结合客户端配置和系统状态一起判断。
在 Windows 上，可以使用以下命令查看域名查询结果：
nslookup example.com
Resolve-DnsName example.com在 macOS 上，可查看系统维护的解析器配置：
scutil --dns采用 systemd-resolved 的 Linux 环境可以检查当前接口与解析器状态：
resolvectl status
resolvectl query example.com这些命令展示的是系统层信息，而浏览器的加密 DNS 可能绕开系统解析器。如果命令行与浏览器检测结果不同，应检查浏览器的安全 DNS 设置。若希望由客户端统一处理解析，应确认客户端的 DNS 模块已启用，并核对分流规则是否把解析服务器本身错误地设为直连。
用分应用测试找出绕过线路的程序
同一台设备上的应用可能采用不同网络栈。浏览器通常遵循系统代理，命令行工具是否遵循则取决于环境变量和自身参数；部分游戏和实时通信程序使用 UDP，并可能忽略只支持 TCP 转发的代理方式。还有一些应用内置代理、加密 DNS或连接复用逻辑，使其行为与系统设置不同。
排查时可以选择浏览器、终端和实际目标应用分别执行联网操作，并观察客户端连接记录。若客户端支持按进程或目标域名显示日志，重点查看请求最终匹配了代理、直连还是拒绝规则。不要只看日志中是否出现域名，还要确认该条记录的出站策略。
- 浏览器中刷新出口查询页面，记录地址是否改变。
- 在终端执行出口查询命令，对比浏览器结果。
- 关闭浏览器自带的加密 DNS 后复测，再按需要恢复设置。
- 打开目标应用执行实际请求，同时观察客户端连接记录。
- 检查未匹配规则的默认策略是代理还是直连。
- 若应用使用 UDP，确认当前接管模式与线路配置支持对应流量。
如果只有目标应用没有经过线路，应优先查应用代理设置、进程分流与 UDP 接管，而不是频繁更换节点。如果所有应用都没有变化，则应回到系统代理、虚拟网卡权限和路由表检查。分应用测试的价值在于缩小问题范围，避免把规则问题误判为线路问题。
分流规则会让“部分生效”成为正常结果
分流的目标不是让所有请求采用同一出口，而是按照域名、IP、应用或网络类型选择代理与直连。例如，本地服务可以直连，跨境访问请求通过国际线路，局域网地址则保持在本地网络。此时不同网站看到不同出口，可能正是规则设计的结果。
规则匹配通常存在优先顺序。域名规则可能先于 IP 规则生效，最终规则负责处理没有命中的请求。启用订阅规则集后，旧规则、用户自定义规则与客户端默认规则还可能同时存在。排查时应从实际连接记录反查命中项，而不是只凭规则文件中的文字推测。
DNS 策略也会影响分流准确性。若客户端依靠域名判断路径，但应用先把域名解析成 IP 并直接发起连接，客户端可能只能看到地址，无法按原域名规则处理。虚拟网卡模式中的 DNS 劫持或映射机制可以改善可见性，但配置不一致时也可能导致解析成功、连接失败。
不同平台的检查重点
Windows
Windows 上应同时检查系统代理、虚拟网卡状态和 DNS 接口优先级。部分桌面程序不会读取系统代理，因此浏览器正常而其他程序直连并不少见。切换接管模式后，可重新打开目标程序，避免已有连接继续复用旧路径。
macOS 与 iOS
macOS 客户端可能使用系统代理，也可能创建网络扩展。两种方式的覆盖范围不同。iOS 上的客户端通常通过系统提供的 VPN 网络扩展接管流量，但应用自身的加密 DNS、局域网访问策略和按需连接仍会影响检测结果。切换配置后，应让检测页面重新建立连接。
Android
Android 客户端一般通过系统 VPN 接口处理流量，并可能提供分应用代理或绕过列表。若只有特定应用出口不变，应先查看该应用是否被排除。系统中的私人 DNS 也可能独立于客户端 DNS 策略，需要结合客户端文档决定保留还是交由线路处理。
Linux
Linux 环境的差异主要来自桌面代理、环境变量、路由表与 DNS 管理组件。图形界面设置不一定影响终端进程，终端中的代理变量也不一定影响系统服务。排查时应分别检查当前 shell、服务进程和虚拟网卡路由，不要假设它们共享同一配置。
界面已连接但检测失败的排查顺序
遇到连接状态正常、出口却没有变化时，按网络层次逐步检查通常比反复重装客户端更有效。先确认请求有没有进入客户端，再确认客户端把它送往哪个出站，最后检查远端线路与解析结果。
- 断开线路并记录当前出口 IP 与 DNS 状态，建立可比较的基线。
- 重新连接后确认客户端没有握手、权限或配置解析错误。
- 检查系统代理是否已写入，或虚拟网卡是否成功创建并获得路由。
- 查看测试请求的连接记录，确认它匹配代理规则而非直连规则。
- 分别测试浏览器、终端与目标应用，判断问题是否局限于某个程序。
- 检查浏览器加密 DNS、系统 DNS 与客户端 DNS 是否互相覆盖。
- 确认 IPv4 与 IPv6 流量都符合预期，避免仅有部分协议栈被接管。
- 更换线路复测，用于区分本地配置问题与特定节点连接问题。
若连接记录中完全看不到测试请求，问题通常发生在应用到客户端之间，应检查代理设置、虚拟网卡权限或应用排除列表。若记录显示直连，则重点检查分流规则。若记录显示代理，但出口仍未变化，应确认检测页面没有使用缓存，并检查客户端实际选择的远端节点与出站链路。
IEPL 专线、中转线路与直连线路描述的是不同传输路径。直连由设备直接连接远端节点；中转会先连接入口，再由中转网络送往出口；IEPL 专线通常用于入口与出口之间的专线传输。无论采用哪种线路，网站最终观察到的都应是配置对应的出口，而不是入口节点。出口检查可以验证最终来源地址，却不能仅凭检测页面判断整段传输路径。
怎样得出可信的最终结论
可靠结论来自多项结果相互印证：浏览器与命令行出口符合预期，DNS 查询遵循设定策略，目标应用的连接记录显示正确出站，分流场景下的直连与代理结果也与规则一致。如果只有某个检测网站报告异常，应更换观察方式，并考虑数据库位置、缓存和浏览器网络功能造成的差异。
测试完成后，可以恢复日常使用所需的加密 DNS、分流规则和应用排除设置。检查过程不要求所有流量长期采用同一出口，而是要确认每类流量都按配置执行。客户端显示连接成功只是起点；出口 IP、DNS 路径和分应用记录共同构成更完整的验证链路。