VPN 是否生效怎么查，不能只看客户端是否显示“已连接”。这个状态通常只代表握手完成或隧道已经建立，并不等于浏览器、命令行工具和其他应用的流量都经过了目标线路。可靠的判断应同时核对出口 IP、DNS 查询路径和实际应用结果。
一次完整检查可以分成三个层次：先确认客户端与节点之间的协议连接，再确认操作系统是否把目标流量交给隧道，最后确认访问目标看到的出口与预期一致。若只检查其中一层，很容易把“协议已连接但路由未接管”误判为连接正常，也可能把浏览器自身的代理或 DNS 设置误认为系统级 VPN 已生效。
先区分“连接成功”和“流量经过线路”
客户端发起连接时，会先与远端服务器建立传输通道。Shadowsocks、VMess、Trojan、VLESS、Hysteria2 和 TUIC 都可以承担这一阶段，但协议握手成功之后，流量如何进入通道仍由客户端模式、系统权限和分流规则决定。
例如，客户端处于系统代理模式时，通常只有遵循系统代理设置的应用会进入代理。浏览器可能正常切换出口，但某些游戏、命令行程序或自行实现网络栈的桌面软件可能继续直连。客户端处于虚拟网卡或隧道模式时，可以接管更广泛的系统流量，但仍可能受到路由优先级、排除规则、其他网络工具和系统权限影响。
因此，“已连接”至少可能对应以下几种不同结果：
- 协议握手完成，浏览器和其他应用都按规则经过线路。
- 协议握手完成，只有使用系统代理的应用经过线路。
- 协议握手完成，但分流规则把当前目标判定为直连。
- 隧道已经创建，但系统路由未正确写入或被其他配置覆盖。
- 主要网页流量经过线路，DNS 查询或部分协议族仍从本地网络发出。
- 浏览器扩展或应用内代理改变了结果，使其与系统出口不一致。
排查时不要反复切换节点后只观察状态灯。更有效的方法是固定一个目标线路，记录连接前后的网络结果，再逐层缩小问题范围。这样可以判断故障发生在协议、路由、DNS、分流还是具体应用。
用出口 IP 确认实际访问路径
出口 IP 是目标网站看到的来源地址，也是判断网页流量是否经过远端节点最直接的依据。检查前应先断开客户端，访问可信的 IP 查询页面并记录本地出口；随后连接指定线路，重新查询并比较结果。若地址和地理归属随节点发生变化，说明当前查询请求已经从远端出口发出。
测试时应尽量保持网络环境不变。不要在连接前后切换无线网络、有线网络或其他上网方式，否则本地出口本身也会改变，比较结果就失去意义。浏览器页面还可能缓存旧结果，必要时可强制刷新，或在新的隐私窗口中重新查询。
出口没有变化时检查什么
出口 IP 未变化，并不一定表示节点不可用。常见原因是当前浏览器没有读取系统代理、客户端只启动了本地代理端口、虚拟网卡没有获得必要权限，或分流规则把 IP 查询站点划入了直连。此时应先检查客户端当前使用的是系统代理、规则模式、全局模式还是隧道模式。
如果全局模式下出口会变化，而规则模式下不变，问题通常不在协议连接，而在规则匹配。可以查看连接日志，确认查询站点的域名最终命中了代理规则还是直连规则。日志中的“连接成功”只能证明客户端能够访问远端；真正有诊断意义的是该请求被分配到哪个出站。
不同应用显示不同出口
浏览器、终端和桌面应用显示不同出口，通常说明它们没有共享同一套代理入口。浏览器可能启用了独立代理扩展，终端程序可能忽略系统代理，某些应用还会优先使用自身配置的网络通道。此时应分别关闭应用内代理，或明确把应用配置到客户端提供的本地代理入口，再重新测试。
| 观察结果 | 可能原因 | 下一步 |
|---|---|---|
| 连接后出口发生变化 | 当前查询流量已进入目标线路 | 继续核对 DNS 与实际应用 |
| 出口始终不变 | 代理未接管、规则直连或路由未写入 | 切换测试模式并检查连接日志 |
| 浏览器变化，其他应用不变 | 仅浏览器使用了代理 | 检查系统代理、隧道模式与应用设置 |
| 不同查询页面结果冲突 | 缓存、协议族差异或页面识别数据不同 | 刷新结果并从多个网络入口复核 |
检查 DNS 查询是否绕过隧道
访问域名时，系统需要先把域名解析为可连接的地址。若网页流量经过 VPN，而 DNS 查询仍交给本地网络提供的解析器，访问通常仍能完成，但域名查询路径与网页出口并不一致。这类情况常被称为 DNS 泄漏，更准确地说，是解析请求没有按照预期进入受控通道。
检测时应在断开和连接状态下分别查看 DNS 解析器归属。如果连接线路后，查询仍持续由原本的本地网络解析器处理，就需要检查客户端的 DNS 接管、虚拟网卡配置和系统缓存。若显示的是客户端配置的远端解析器或隧道内解析入口，则说明解析路径更接近预期。
不过，DNS 检测结果不能脱离配置判断。浏览器可能启用加密 DNS，并绕过操作系统解析设置；客户端也可能按照域名类别选择不同解析器。某个解析器与出口地区不同，不一定等于泄漏，关键是这条路径是否符合客户端的设计和用户设定。
浏览器加密 DNS 造成的差异
现代浏览器可以自行发送加密 DNS 请求。这样做会让浏览器解析结果与系统命令、其他应用和客户端日志不同。如果浏览器的加密 DNS 请求仍通过隧道发出，它未必构成绕行；但如果分流规则允许该请求直连，就会形成独立于系统 DNS 的路径。
排查时可以暂时让浏览器跟随系统解析设置，然后重新运行检测。如果结果随之统一，差异来自浏览器自身配置；如果仍不一致，则继续检查客户端的 DNS 规则、虚拟网卡接管范围和系统网络服务顺序。
系统缓存与旧解析结果
操作系统和浏览器都可能缓存解析记录。切换线路后，已有连接还可能继续复用，导致新出口已经生效，但页面看起来仍使用旧路径。测试前可以关闭相关页面，清理系统 DNS 缓存并重新打开浏览器。无需在日常使用中频繁清理，只有在诊断路径变化时才有必要。
Windows:
ipconfig /all
macOS:
scutil --dns
Linux:
resolvectl status这些命令用于查看系统当前识别的解析配置，不代表每个应用一定遵循该配置。命令结果需要与客户端日志、浏览器设置和实际 DNS 查询结果一起判断。
分应用验证：浏览器正常不等于全部正常
完成出口和 DNS 检查后，应选择实际要使用的应用逐一验证。测试对象可以包括浏览器、终端下载工具、桌面客户端、视频应用和需要 UDP 的实时通信程序。重点不是让所有应用显示完全相同的界面，而是确认每个应用的连接是否命中预期出站。
最简单的方法是先在客户端日志中观察新连接。启动目标应用并执行一次明确的网络操作，然后查看对应域名或地址被分配到代理、直连还是阻断。若日志中完全没有该应用的请求，它可能没有进入客户端接管范围，或者使用了客户端当前未处理的网络协议。
系统代理与隧道模式的差别
系统代理适合遵循代理设置的网页与桌面软件，配置相对直接，但无法保证覆盖所有进程。隧道模式通过虚拟网络接口接收系统流量，通常更适合需要统一接管的场景。启用隧道模式时，应关注系统权限、默认路由、DNS 劫持方式和局域网访问规则。
如果系统代理测试正常而隧道模式异常，应检查虚拟网卡是否创建成功、路由是否被其他 VPN 或安全软件改写，以及客户端是否排除了当前网络接口。反过来，如果隧道模式正常而系统代理无效，则应查看操作系统代理开关是否写入成功，以及应用是否支持对应代理类型。
分流规则如何影响验证结果
规则模式会根据域名、地址范围、进程名称或规则集合选择出站。规则判断错误时，客户端仍会显示连接正常，但目标请求可能直接发送。尤其在域名经过重定向、应用连接到内容分发域名，或规则只覆盖主域名时，访问链路可能与预想不同。
诊断规则问题时，可以短暂切换到全局代理进行对照。如果目标应用在全局模式下恢复，而规则模式下失败，就应检查规则顺序、域名匹配和最终兜底策略。排查完成后再恢复所需的分流设置，不必长期依赖全局模式。
UDP 与基于 QUIC 的连接
部分网页、实时通信和游戏会使用 UDP。若客户端只接管 TCP，或当前网络限制 UDP，应用可能回退到其他传输，也可能直接失败。Hysteria2 与 TUIC 本身基于 QUIC 和 UDP，节点握手、底层网络可达性以及客户端的 UDP 转发能力都会影响结果。
Trojan、VMess、VLESS 与 Shadowsocks 的具体表现也取决于客户端实现、传输层配置和路由方式，不能仅凭协议名称判断是否覆盖系统流量。协议决定客户端与服务器如何传输数据，系统代理、虚拟网卡和分流规则才决定哪些应用数据会进入这条通道。
| 测试对象 | 需要观察 | 异常线索 |
|---|---|---|
| 浏览器 | 出口、DNS、浏览器独立代理 | 扩展或加密 DNS 绕过系统设置 |
| 命令行工具 | 是否读取环境代理或进入隧道 | 终端出口与浏览器不一致 |
| 桌面应用 | 进程规则与应用内网络设置 | 日志中没有对应连接 |
| 实时通信应用 | UDP 接管与连接回退 | 网页正常但实时连接异常 |
协议、订阅与节点类型会怎样影响结果
订阅链接通常包含节点名称、服务器参数、协议类型和传输配置。将订阅导入客户端后，客户端会把这些信息转换为本地配置。导入成功只说明客户端能够读取订阅内容，不代表所选节点已经连接，也不代表路由规则自动适合当前平台。
如果更新订阅后突然无法使用，应先确认当前节点是否仍存在、协议字段是否被客户端支持，以及订阅更新有没有覆盖本地分流设置。部分客户端把节点、策略组、DNS 与路由规则分开管理；选择了新节点，却仍在使用旧策略组，也是常见的结果不一致原因。
不同协议的检查重点
- Shadowsocks：重点确认客户端是只开放本地代理，还是同时启用了系统代理或虚拟网卡。仅启动本地监听并不会自动接管全部应用。
- VMess 与 VLESS：除节点连接外，还要检查传输配置、出站策略与路由规则。VLESS 的安全性依赖所采用的传输与安全配置，不能脱离完整配置单独判断。
- Trojan：需要确认传输安全参数与目标服务器匹配。握手失败属于协议层问题；握手成功但出口不变，则应回到路由层排查。
- Hysteria2 与 TUIC：重点检查当前网络对 UDP 的可达性，以及客户端是否正确处理 UDP 流量。网络环境变化时，它们与基于 TCP 的方案可能呈现不同结果。
直连、中转与 IEPL 专线
直连线路通常由用户网络直接连接远端节点，路径更依赖公网路由变化。中转线路会先连接中转入口，再由中转链路送往出口节点，可以减少部分不可控公网路径，但实际效果仍取决于入口、承载网络和出口配置。
IEPL 专线通常指跨境企业专线承载的一类链路。需要注意，线路标注为 IEPL，并不表示用户设备到入口、入口到出口、出口到目标网站的每一段都脱离公网。验证时仍应以实际出口、DNS 路径、连接日志和目标应用结果为准，而不是只依据节点名称。
切换直连、中转或专线节点后，建议重新执行相同的检查流程。线路类型变化可能改变出口和传输路径，却不会自动修复应用未接管、DNS 设置错误或分流规则冲突。
各平台常见差异与排查顺序
Windows 客户端常同时提供系统代理与虚拟网卡模式。系统代理是否成功写入、虚拟网卡驱动是否正常、网络接口优先级是否被其他工具修改，都会影响结果。可以先查看系统代理状态，再检查路由与 DNS 配置，最后用不同应用对照。
macOS 对网络扩展和系统代理有明确的权限控制。首次启用隧道时，如果网络扩展没有获准，客户端可能保存节点配置却无法接管流量。还要注意浏览器、终端和系统网络服务可能读取不同的代理环境。
iOS 上的客户端通常通过系统 VPN 配置接管流量，但按需连接、应用规则和系统隐私功能可能改变测试结果。切换节点后，应重新发起请求，不要只观察仍在复用的旧连接。若某个应用异常而浏览器正常，可先完全关闭该应用再重新打开。
Android 的实现会受到系统 VPN 权限、省电策略、按应用代理和始终开启设置影响。若客户端在后台被系统暂停，界面可能保留先前状态，但新请求无法继续通过隧道。排查时应确认系统状态栏中的 VPN 状态、客户端运行状态和按应用列表是否一致。
Linux 更依赖具体桌面环境、路由工具和权限配置。仅设置桌面代理不会自动影响所有 shell 命令和后台服务；虚拟网卡模式则需要正确创建接口并写入路由。使用容器或独立网络命名空间时，容器流量也未必继承宿主机路径。
客户端显示已连接但无法访问的完整排查流程
遇到“已连接但打不开”时，按固定顺序检查比随机更换协议更有效。每一步都应记录结果，以便区分节点故障、网络限制和本地配置问题。
- 记录连接前基线。断开客户端，确认本地网络本身可用，并记录出口 IP 与 DNS 解析路径。
- 连接固定节点。不要连续切换多个节点。等待客户端给出明确的握手或连接回执，并查看是否存在认证、超时或传输错误。
- 复查出口 IP。如果出口未变化，检查代理模式、虚拟网卡权限、路由规则和查询站点是否命中直连。
- 复查 DNS。确认系统与浏览器是否使用预期解析路径，并排除缓存和浏览器独立加密 DNS 的干扰。
- 对照全局与规则模式。若全局模式可用而规则模式异常，重点检查规则命中和兜底出站。
- 逐个测试应用。观察客户端日志是否出现对应请求，以及请求最终进入代理、直连还是阻断。
- 检查协议与网络兼容性。若基于 UDP 的协议无法握手，可在相同网络下对照其他可用传输，判断是否属于底层网络限制。
- 排除配置冲突。暂时关闭其他代理、VPN、浏览器扩展或会改写路由的网络工具，再重新建立连接。
- 重新导入或更新订阅。确认客户端支持订阅中的协议与字段，并检查更新是否改变策略组、DNS 或本地规则。
若某一步恢复正常，应在继续修改前保存当前配置。一次改动多个选项会让故障原因难以确认。排查目标不是让状态灯变绿，而是建立一条可重复验证的路径：协议能握手、路由能接管、DNS 符合设定、目标应用得到预期出口。
最可靠的验证不是单一测试页面，而是连接日志、出口结果、DNS 路径和实际应用表现一致。任何一项冲突，都说明仍有一部分流量没有按预期运行。
如何判断问题已经解决
修复完成后，应重新从基线开始验证，而不是只重试刚才失败的页面。连接目标线路后，出口 IP 应与断开状态不同，并与所选出口相符；DNS 查询应符合客户端设定；浏览器、终端和主要应用应按照分流规则进入对应出站。
如果启用了规则模式，本地站点保持直连而指定目标经过线路并不矛盾，这正是分流的预期结果。判断是否生效时，要比较规则意图与实际路径，而不是要求所有请求都显示同一个出口。对于被明确排除的局域网资源，也应确认它们仍能通过本地网络访问。
最后可以断开并重新连接一次，检查结果能否稳定复现。如果只有首次测试成功，重连后配置丢失，应继续检查系统权限、启动项、订阅策略组和网络接口设置。可重复的操作结果比单次页面成功更有诊断价值。