VPN是否生效怎么查？先比较连接前后的出口 IP，再检查 DNS 解析路径，最后验证实际使用的应用。客户端显示“已连接”，通常只说明某个连接或本地代理已建立，不能单独证明浏览器、办公软件和其他应用都经过了预期线路。
判断目标不是“所有流量必须变化”，而是需要走代理的请求确实走代理，需要直连的请求按规则直连。这也是为什么检测前要先看清客户端采用系统代理、规则分流，还是虚拟网卡接管模式。下文按可复查的顺序操作，不依赖一张检测截图下结论。
先确认接管范围：连接状态不等于流量路径
系统代理通常向遵循系统设置的软件提供代理地址，并非接管所有网络请求。有些应用使用自己的网络组件，可能忽略系统代理。浏览器扩展的影响范围更窄，往往只作用于该浏览器，不能代表桌面应用也已改变出口。
虚拟网卡模式通过路由接管更多流量，常见名称包括 TUN 或 VPN 模式，但仍可能受到排除列表、进程规则和协议支持范围影响。在移动端，即使系统状态栏出现 VPN 标识，也可能启用了按应用排除或按需连接。应以客户端实际配置为准。
- ✅ 记录当前线路、代理模式、规则组和是否启用虚拟网卡，避免测试中途改变条件。
- ✅ 暂停其他代理扩展或同类客户端，减少多层代理和路由冲突。
- ✅ 关闭后台下载与同步任务，先验证路径，再考虑速度问题。
- ✅ 列出需要验证的浏览器、办公软件及其他应用，不把浏览器结果推广到整台设备。
订阅链接用于向客户端提供配置，不是网页代理地址。导入成功后，还要确认订阅更新正常、线路已被选中、相应接管开关已开启。Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC 等协议的名称，也不能直接说明当前应用有没有经过代理；客户端的路由与接管配置同样关键。
检查出口 IP：保留连接前后的对照
先断开连接，在同一个浏览器打开IP 检测页面，记录可用的公网地址、运营商或地址所属网络信息。随后连接目标线路，重新加载检测页面并比较结果。测试期间不要同时更换网络，否则无法判断变化来自代理还是本地网络切换。
出口地址发生变化，说明这次检测请求的路径发生了变化；它不证明设备上的全部请求都已接管。反过来，规则模式下某个检测域名可能被判为直连，即使地址没有变化，也不能直接判定整条线路失效。此时应查看该域名命中的规则和实际出站。
地址所属国家或地区也不是精确定位。不同数据库可能更新滞后，线路名称、机房位置与地址登记地区也可能不同。优先比较实际地址和客户端连接记录；地区标签只作辅助，不要仅凭地图上的位置判断成功与否。
同时关注 IPv4 与 IPv6。若检测工具支持分别检查，应确认两类请求都符合预期路由。只看到某一类地址变化，不能排除另一类仍在直连；不要把禁用 IPv6 当作通用答案，先核对客户端支持情况和路由设置。
浏览器的旧页面和应用已有连接也会干扰对照。切换线路后重新发起请求，必要时重启目标应用。无痕窗口可以减少部分缓存和扩展因素，但不会自动绕过系统路由，也不能代替 DNS 检查。
检查 DNS 泄漏：区分解析器与访问出口
DNS 把域名转换为网络地址，解析请求与网站连接可能走不同路径。DNS 泄漏通常指原本应受代理或隧道配置约束的解析请求，却通过预期之外的本地网络发送。不能因为检测结果出现一个不熟悉的解析服务名称，就直接认定存在泄漏。
使用会生成新测试域名的 DNS 检测工具，分别在断开与连接状态运行，记录解析器的网络归属。若启用了接管 DNS 的模式，连接后仍稳定出现本地网络提供的解析器，就值得继续排查。但部分测试展示的是递归解析器的上游出口，而非设备直接联系的服务器，归属信息仍需结合配置解释。
浏览器安全 DNS 为什么会改变结果
浏览器的安全 DNS 可能使用加密解析服务，绕开系统解析器选择。它的连接是否经过代理，仍取决于浏览器请求如何被路由。因此，“使用加密 DNS”和“解析请求经过代理”是不同问题，不能互相替代。
先记录浏览器安全 DNS 的设置，再与客户端 DNS 模式、连接日志对照。需要隔离变量时，可以临时调整该设置进行对比，并在测试后恢复预期配置。不建议反复修改系统、浏览器与客户端的解析设置却不留记录，否则很难确定哪项改变真正有效。
缓存与虚拟地址不一定是故障
系统和应用都可能缓存解析结果，所以刚切换线路时没有新的 DNS 请求，并不异常。部分客户端还会使用 Fake-IP 机制，返回内部使用的虚拟地址，再由客户端映射到目标域名。这类地址不应当作网站的真实公网地址，也不能仅凭它判定泄漏。
分应用验证：检查实际请求命中了什么规则
浏览器验证完成后，打开真正要使用的应用，触发明确的新请求，例如刷新远程文档、重新加载资源或发起同步。同时在客户端连接面板中查找对应进程或域名，检查它命中的规则、出站线路和是否出现连接错误。
日志能显示应用请求命中了预期出站，是重要证据，但也应结合应用实际响应判断。应用可能访问多个域名，其中登录、内容和资源下载分别走不同路径。只验证首页打开，不能代表登录或文件传输已经正常。
| 接管方式 | 优先检查 | 常见误判 |
|---|---|---|
| 浏览器代理扩展 | 扩展生效范围、排除域名与浏览器出口 | 把浏览器结果当成桌面应用结果 |
| 系统代理 | 应用是否遵循系统设置、是否自带代理配置 | 认为开启系统代理就能接管所有应用 |
| 虚拟网卡模式 | 路由、DNS 接管、排除列表与协议支持 | 忽略被排除的进程或另一类地址流量 |
| 按应用或规则分流 | 目标进程、域名规则与实际出站 | 把符合预期的直连请求当作线路故障 |
Windows 与 macOS 上要区分系统代理和虚拟网卡开关；Linux 上，桌面代理设置与终端程序的代理环境变量也未必一致。iOS 与 Android 则要查看客户端是否提供应用排除、按需连接等选项，具体支持能力取决于系统与客户端，不应直接照搬其他平台教程。
需要使用 UDP 的应用，还应确认客户端、所选配置与线路都支持相应转发。网页正常而语音或游戏异常，可能是协议或路由覆盖差异，并不一定是整条连接没有生效。
看似连上却没走线路，按什么顺序排查
- 确认配置有效。检查订阅是否更新成功、是否选中预期配置，避免修改了未启用的规则组。
- 确认接管开关。区分“连接线路”和“设置系统代理”，并核对虚拟网卡权限是否已获准。
- 检查命中规则。查看检测域名或目标应用是否被设为直连，是否存在更靠前的排除规则。
- 隔离其他网络工具。暂停浏览器扩展、其他代理客户端或可能重写路由的软件，再重复对照。
- 重新建立应用连接。结束旧连接并重新打开应用，必要时再检查解析缓存与安全 DNS 设置。
- 整理证据再求助。提供系统、客户端、模式、错误现象和脱敏日志，不要发送完整订阅链接。
诊断时可暂时切换到客户端提供的全局代理规则，观察目标请求是否改变出站。这里的“全局”通常描述规则选择，并不必然扩大接管范围：一个忽略系统代理的应用，仍可能不受影响。完成对照后，应恢复符合实际用途的规则。
订阅链接可能包含访问凭据，日志也可能暴露目标域名与地址。向帮助支持提交材料前应先脱敏，只保留排查所需部分。不要把完整配置上传到来源不明的在线检测页面。
验证结论：路径正确不代表所有服务都可用
出口改变、解析路径符合配置、目标应用命中预期线路，合起来才能较完整地说明连接生效。网站是否允许访问，还可能受账号地区、权限、服务状态、Cookie 与出口地址策略影响；连接生效和平台可用不是同一个结论。
同样，测速快慢不是生效判据。线路类型描述传输路径，不能代替终端验证；IEPL 专线、中转或直连的名称，也无法证明本机 DNS 与分流一定配置正确。先确认路径，再单独处理速度、稳定性与应用兼容问题。
判断标准：用连接前后的出口对照证明检测请求的变化，用 DNS 检查确认解析符合预期，再用应用请求与客户端记录验证分流。只对已验证的应用和请求下结论，不把“已连接”当成整台设备的通行证明。
VPNCB 支持 Windows、macOS、iOS、Android、Linux，客户端与订阅需登录面板后获取。需要重新梳理导入与连接流程，可查看快速上手。账户无需邮箱地址，使用用户名与密码即可创建；实际连接效果仍应按本文方法在自己的网络环境中验证。