先判断故障范围：不是所有“打不开”都一样
VPN 客户端显示“已连接”，通常只说明客户端认为隧道或代理连接已经建立；它不能证明每个应用的流量都已正确转发，也不能保证 DNS 解析、分流规则和目标网站都正常。因此，先别急着删除配置或连续切换所有选项，按现象缩小范围，通常更容易找到原因。
先确认设备本身能否上网：断开 VPN 后，用同一个 Wi-Fi 或移动网络打开几个平时可访问的网站；再重新连接 VPN，分别测试浏览器和另一个应用。如果断开 VPN 也无法上网，问题更可能在路由器、运营商网络或设备本身。如果只有某个网站或某个应用异常，则还要考虑站点故障、应用代理设置或分流规则。
记录故障开始时间、当前网络类型、客户端名称、所选线路，以及错误提示。不要在记录中包含密码、完整订阅链接或未遮挡的配置二维码。随后依次完成以下五步，每完成一步就重新测试一次；如果恢复，就不必继续改动其他设置。
- ✅ 断开 VPN 后先确认本地网络是否可用。
- ✅ 对比浏览器与其他应用，判断是单个应用还是全设备异常。
- ✅ 一次只调整一个设置，避免多个变化叠加后无法判断原因。
- ❌ 不要因客户端显示已连接，就认定全部应用都已经走 VPN。
第 1 步：重连并检查当前网络
先在客户端中断开连接，等待连接状态变为断开，再重新连接。若状态没有变化，完全退出客户端后重新打开，并确认没有同时运行另一个代理或 VPN 客户端。多个工具可能争用系统代理、虚拟网卡或路由，表现为客户端显示连接成功，但应用请求没有按预期通过。
接着更换网络环境进行对照：例如从 Wi-Fi 切换到移动网络，或改用另一条可信的网络连接。如果新网络下可以访问，问题可能与原网络的 DNS、路由器设置、网络限制或临时连通性有关；如果不同网络都一样，则继续检查设备和客户端设置。测试完成后切回日常网络即可，不必为了排错重置路由器或清除所有网络配置。
桌面设备还可以检查系统日期和时间是否自动同步。时间明显错误可能影响证书验证或安全连接，但不应把调整系统时间当作常规“加速”方法。移动设备则检查飞行模式、蜂窝数据权限和应用的后台网络权限；若只有锁屏或切换应用后断网，重点查看系统的省电与后台限制。
第 2 步：检查 DNS、系统代理与分流模式
DNS 负责把域名转换为网络地址。隧道已建立但网页一直转圈、提示找不到服务器，可能与设备自定义 DNS、浏览器的安全 DNS、Android 的私人 DNS，或客户端的 DNS 规则不匹配有关。作为排查，可以暂时将设备 DNS 恢复为自动，关闭自定义 DNS 或浏览器安全 DNS进行对照；如果问题消失，再根据客户端说明逐项恢复设置，而不是长期关闭所有 DNS 保护功能。
然后核对客户端的运行模式。系统代理通常只影响遵循系统代理设置的应用；有些命令行程序、游戏或特定应用可能绕过系统代理。TUN 模式通过虚拟网络接口接管更广范围的流量，但需要客户端支持并取得系统授权。两种模式并非可以随意同时开启，具体名称和行为以当前客户端说明为准。
如果使用规则模式，访问请求可能按域名、IP 地址或应用规则直连，也可能被送入代理。故障若集中在个别网站或软件，可以临时切到客户端提供的全局代理模式进行对照；全局模式恢复访问，通常说明需要进一步检查规则、域名解析或应用是否遵循系统代理。测试后应恢复适合日常使用的模式，避免让本来需要直连的本地服务也经由代理。
不同平台可重点检查的位置略有不同：
- Windows、macOS、Linux：检查系统代理开关、客户端的系统代理状态和 TUN 授权。退出客户端后若系统仍保留手动代理地址，可按客户端说明恢复自动设置。Linux 桌面环境和命令行程序的代理配置可能彼此独立，不要默认一个开关能覆盖所有程序。
- Android：检查系统 VPN 权限、私人 DNS、始终开启 VPN，以及“无 VPN 时阻止连接”等选项。后者在 VPN 断开或配置异常时可能阻止其他流量，排查时先了解其用途再决定是否临时调整。
- iOS：确认系统 VPN 配置处于预期状态，并检查相关应用是否允许使用蜂窝数据。若仅某个浏览器异常，可分别测试浏览器的安全 DNS或内容过滤设置，不要直接删除不明配置文件。
如果希望确认服务入口和使用方式，可以从VPNZK 免费VPN了解服务信息；排查设备本身时，仍应以当前客户端的实际设置和系统提示为准。
第 3 步：更换线路并验证是否为单节点问题
一条线路无法访问，不代表整个客户端或账户都不可用。选用客户端内另一条可用线路测试，并保持其他设置不变。如果新线路恢复访问，故障更可能与原线路的临时状态、目标网络路径或特定目的地兼容性有关。若多个线路在同一网络下都无法访问，则返回检查 DNS、代理模式和本地网络，不要只靠反复点击节点列表解决。
测试时尽量使用同一个网站或应用，并留意是所有目标都失败，还是特定区域、服务或协议连接失败。不同线路的入口、出口和转发方式可能不同，网络环境也会影响实际表现。节点名称或地理位置本身不能保证访问结果；应以客户端当前可选配置和实际测试为准。
如果客户端提供线路延迟测试，可以把它作为初步筛选参考，但延迟测试成功不等于网页访问一定正常：测试目标可能与故障网站不同，DNS、分流和目标站点状态仍可能造成差异。也不要仅凭一次测试就删除订阅或重装客户端。
第 4 步：核对协议兼容性与配置更新
协议影响客户端与服务端之间如何建立连接，不等同于线路的快慢等级。Shadowsocks、VMess、Trojan、Hysteria2、WireGuard 等名称对应不同协议或方案，客户端内核支持范围和参数要求可能不同。不要通过手动修改节点前缀，试图把一种协议“改成”另一种；协议名称、认证信息和传输参数必须与服务端配置匹配。
如果近期更新过客户端、切换过内核或导入过新的配置，检查客户端是否支持所选线路的协议与参数，并确认配置确实已加载。必要时按客户端提供的订阅更新功能刷新配置，再重新选择线路。更新订阅会重新获取配置，不等于修复设备的 DNS 或系统代理，也不应把完整订阅链接粘贴到陌生的在线转换工具中。
切换协议只适合作为有依据的兼容性测试：例如客户端明确提示协议不受支持，或服务提供方建议使用另一种配置时，再按说明操作。每次更改后都要记录原设置，验证后保留有效配置；如果无法确认某个选项的作用，先不要同时改动传输、加密、端口和路由参数。
- ✅ 确认客户端及其内核支持当前配置所用协议。
- ✅ 配置更新后检查线路列表和当前选中的线路。
- ✅ 只有在兼容性提示或服务说明支持时才测试切换协议。
- ❌ 不要把协议名称、端口或认证字段当作可随意替换的参数。
第 5 步：恢复临时设置，并向支持渠道提供有效信息
完成对照测试后，把临时关闭的 DNS、系统代理、浏览器设置或全局模式恢复到原先适合自己的状态。若排查中曾关闭防火墙、安全软件或系统的 VPN 保护选项，应及时恢复；不建议为了让连接成功而长期关闭防护。接着重新连接，分别测试常用网站和应用，并确认系统代理没有遗留错误地址、移动设备没有启用会阻断非 VPN 流量的选项。
如果仍无法恢复，联系服务支持时提供有助于复现问题的信息：设备系统与版本、客户端名称及版本、使用 Wi-Fi 还是移动网络、故障发生的大致时间、测试过的线路、具体报错，以及是否只有某些应用受影响。可附上已遮挡用户名、订阅地址、节点凭据和个人信息的设置截图；不要发送密码、完整订阅链接或未经检查的完整日志。
说明自己已经做过哪些测试也很重要，例如断开 VPN 后本地网络是否正常、换网络是否有变化、切换线路是否恢复，以及是否临时调整过 DNS 或代理模式。这样可以帮助支持人员区分账户或线路侧问题与设备配置问题，减少重复尝试。如果客户端有“诊断”或“导出日志”功能，先查看其中是否包含令牌或个人信息，再决定是否提交。
归纳起来，排查顺序是：确认本地网络可用，重连并排除代理冲突，检查 DNS 与分流，再单独更换线路，最后核对协议兼容性并向支持渠道提交必要信息。保持一次只改一个设置、及时恢复临时选项，通常比同时重装应用、重置网络和更换配置更容易定位“已连接却无法上网”的真正原因。