VPN 没生效，先区分连接与接管
VPN 连上了却没生效，先查出口 IP，再查 DNS，最后核对具体应用。客户端的“已连接”通常只说明隧道或代理服务已启动，不等于浏览器、游戏和命令行都使用了它。
排查时要分清几个环节：应用把请求交给谁，客户端按什么规则处理，域名由谁解析，远端网站最终看到哪个公网地址。任何环节与预期不符，都可能出现“图标亮着，但网站打不开”。不要一开始就重装客户端，也不要同时修改所有开关。
系统代理、虚拟网卡接管和浏览器扩展的覆盖范围不同。系统代理需要应用主动遵循代理设置；TUN 模式通过虚拟网络接口接收符合路由条件的流量，但仍受排除项、权限和规则影响；浏览器扩展通常只影响对应浏览器。它们不能仅凭同一个连接图标判断效果。
出口 IP：做连接前后的对照
打开IP 查询页，记录当前显示的公网地址、运营商和地区。再连接所选线路，用同一浏览器重新查询。地区数据库可能更新滞后，判断时优先比较地址本身，不要只看地图上的地名。
- 保存基线。断开待测客户端，确认其他代理扩展或网络客户端没有接管浏览器，再记录查询结果。
- 选择地区并接通。记下当前线路名称和工作模式，不要在测试过程中来回切换。
- 发起新请求。重新加载查询页面。若结果疑似来自缓存，可关闭旧标签页，再用新窗口打开查询页。
- 对照规则。若查询页被设为直连，IP 不变可能符合配置。临时让该站点走代理后复查，再恢复原来的规则。
- 验证目标应用。浏览器出口变化只能证明这次浏览器请求的路径发生变化，其他应用仍需单独检查。
不同线路也可能共用出口地址，因此切换线路后 IP 没变，不一定是切换失败。反过来，IP 改变也不代表所有协议都被接管。若查询服务分别提供 IPv4 和 IPv6 结果，应分开对照，避免只看到其中一种地址就下结论。
浏览器无痕窗口主要隔离部分本地会话和存储，不会自动绕过系统代理，也不是独立的网络出口。它适合辅助排除登录态与缓存干扰，不适合证明整个设备的流量路径。
DNS 检查：解析位置不等于出口位置
DNS 负责把域名转换为地址。网页访问可以走代理，解析却仍交给本地网络；也可能由浏览器的安全 DNS、客户端内置解析器或远端代理处理。出口 IP 检查与 DNS 检查观察的是不同环节。
使用可信的 DNS 检测页面时，先了解它展示的是解析服务器的地址与归属，而不是你的网页出口。检测页面通常通过专用域名触发查询，再观察递归解析器。公共 DNS 服务可能使用分布式部署，显示地区与所选线路不同，本身不足以证明泄漏。
更值得关注的是：本来希望经远端解析的域名，是否意外交给了本地网络的解析服务。先查看客户端对代理域名、直连域名分别使用哪个解析器，再检查浏览器是否启用了独立的安全 DNS。使用加密 DNS 可以保护解析传输的一部分，但“加密”不等于“经当前代理线路发送”。
命令行能检查什么
Windows 可以在终端使用下面的命令，查看默认解析服务器与域名回答。示例域名仅用于测试解析，不代表 CPUVPN 节点或服务入口。
nslookup example.commacOS 和 Linux 上若已安装相关工具，也可使用该命令；dig example.com 可作为另一种查询方式。这类工具通常不会遵循浏览器的 HTTP 代理设置。TUN、DNS 劫持或系统解析配置可能改变其路径，所以命令输出不能直接代表浏览器实际使用的解析器。
修改 DNS 配置后应重新发起查询，必要时清理对应系统或应用的 DNS 缓存。缓存里的旧回答不等于当前仍向旧解析器发请求。不要为了让检测页面“看起来一致”而盲目替换所有 DNS 设置，那可能影响本地站点和内部网络域名。
按现象定位：先查规则，再查应用
下面的表格按可见现象定位检查入口。它不是故障判决书：同一种现象可能来自不同环节，应通过单项改动与复查缩小范围。
| 可见现象 | 可能原因 | 优先检查 |
|---|---|---|
| 浏览器出口 IP 没变 | 系统代理未启用、扩展覆盖设置，或查询站点命中直连 | 检查代理入口与该域名的规则命中 |
| 浏览器正常，桌面应用失败 | 应用不遵循系统代理，或使用独立网络配置 | 核对应用代理设置与虚拟网卡接管范围 |
| 出口已改变，目标网站仍拒绝访问 | 账户地区、平台策略、出口信誉或服务端故障 | 先区分拒绝页面与网络连接错误 |
| 部分域名失败，其他网站正常 | 域名解析、分流规则或目标服务异常 | 比较解析结果、规则命中与错误类型 |
| IPv4 符合预期，IPv6 仍是原网络 | 当前模式未覆盖 IPv6 或存在相关绕过规则 | 查客户端 IPv6 支持与实际路由 |
| 切换网络后才失效 | 旧连接、路由或解析状态没有及时更新 | 重建连接，再检查系统代理与新请求 |
“无法解析域名”“连接超时”和“平台明确拒绝访问”应分开记录。前者优先看 DNS，中间一种可能涉及路由、线路或目标服务，后者还可能与账号权限和地区规则有关。仅凭一个错误页面，不能断定客户端没有生效。
分流规则与平台权限怎么查
规则模式下，一部分流量直连、一部分走代理是正常设计。查看客户端连接列表或诊断信息时，重点看目标域名命中了哪条规则、最终选择了哪个出口。若客户端没有这些信息，就用目标应用的实际行为与出口查询做交叉验证，不要编造不存在的菜单位置。
许多客户端的“全局”只是把已经进入代理内核的请求统一交给某个出口，并不自动接管所有应用。它可以帮助定位分流问题，但前提是该请求确实进入客户端。验证完成后应恢复适合日常使用的规则，避免本地业务也被不必要地转送。
- ✅ Windows：确认系统代理设置与客户端状态一致；需要虚拟网卡接管时，核对其权限和运行状态。部分程序使用独立代理配置，不一定跟随系统设置。
- ✅ macOS：按客户端要求检查 VPN 配置、网络扩展或代理授权；不同实现需要的权限不同，不必寻找所有类型的授权开关。
- ✅ Android：检查 VPN 授权与按应用路由名单。应用被排除时，即使状态栏显示连接，也可能继续直连。
- ✅ iOS：检查系统 VPN 状态与客户端规则；浏览器之外的应用仍需实测，不能把一次网页查询当作整个系统的结论。
- ✅ Linux：确认桌面代理、终端环境与虚拟网卡路由各自的配置。终端程序未必读取桌面环境中的代理设置。
同时运行多个代理客户端或浏览器扩展，会让设置归属变得模糊。测试时保留待测客户端，暂时停用其他会改变代理或解析路径的工具；如果设备受单位管理，不要擅自修改受管网络策略。
IPv6、WebRTC 与订阅配置的边界
IPv6 应作为独立路径检查。如果目标应用使用 IPv6，而当前代理模式仅覆盖 IPv4，就可能出现部分请求绕过预期出口。优先使用客户端提供的 IPv6 接管或兼容设置。若临时关闭系统 IPv6 用于定位，应记录原配置并在测试后恢复，不把它当成通用修复。
WebRTC 检测可能显示本地地址、经过隐私处理的主机名或公网候选地址。看到本地地址不等于网页流量已经绕过代理；若出现非预期公网候选地址，则需结合浏览器策略、UDP 支持和实际路由继续排查。也不要为消除检测提示随意安装来源不明的扩展。
订阅链接用于获取节点与相关配置，不等于已经导入所有分流和 DNS 规则，具体取决于订阅格式及客户端实现。更新订阅后，还要确认选中的配置确实已启用。Shadowsocks、VMess、Trojan、VLESS、Hysteria2 与 TUIC 是不同协议或方案名称，并不能单独证明系统流量已被接管。
订阅链接可能含访问凭据。不要把完整链接、二维码或含令牌的截图发到公开讨论区。向支持人员提供错误现象时，先遮蔽凭据、账户信息和不必要的地址信息。
线路类型也不是接管范围。IEPL 专线、中转与直连描述的是不同的传输组织方式；即使选择了专线，应用没有进入客户端，仍不会按所选线路发送。先确认请求路径，再比较线路表现，排查顺序不要倒过来。
完成验证后，保留可复查结果
有效的排查记录应包含：系统与客户端名称、当前模式、所选地区、测试应用、连接前后出口、DNS 观察结果和具体错误。每次只改一个设置，再重试同一操作。这样才能分清是规则修正、解析变化，还是目标网站恰好恢复。
如果只有目标网站失败，而出口和规则均符合预期，应进一步检查网站公告、账号权限和地区限制。网络路径正常不代表平台一定允许访问，更不代表内容授权发生改变。按服务规则使用，比反复切换地区更有助于定位问题。
需要重新整理客户端接入流程，可参考使用教程；需要继续定位连接错误，可查看常见问题。保留上述对照结果再提交问题，能减少重复测试。