“代理已开启”只说明一个开关的状态。基础网络、内核、请求入口、规则和出站节点需要分别确认。
先把“无法连接”分成两种症状
记录一个本来能够正常访问的地址，再记录一个失败的地址。完全退出客户端后，检查系统是否还保留着指向本机的手动代理；在自己的设备上恢复此前的正常网络设置，再访问第一个地址。如果此时也失败，问题可能位于无线连接、路由器、登录认证或运营网络，暂时不要调整节点。
若退出客户端后基础网络正常，而启用代理才失败，把排查范围收缩到客户端链路。不要用一个偶尔故障的网站作为唯一证据，也不要把网页证书警告直接归为网络断开。记录错误文字和出现时间，有助于区分超时、拒绝连接与域名解析失败。
确认配置真正被内核使用
配置出现在列表中，不等于它已经启用。检查当前使用的配置、代理组是否有可选节点，以及日志是否出现加载失败。不同版本的状态入口和菜单名称可能变化，请以实际界面为准。若日志指向格式错误、不存在的规则集或代理名称，先修复对应配置，不必反复点击系统代理开关。
为了保留回退路径，先备份，再暂时停用最近新增的扩展配置或脚本；若恢复后即可使用，逐项恢复修改，找出引入问题的那一项。不要删掉全部订阅来验证一个小改动。确认内核正常运行后，再继续检查请求入口。
判断应用是否把请求交给客户端
系统代理需要应用遵循操作系统的代理设置，因此浏览器正常而另一程序失败并不矛盾。打开失败地址的同时观察客户端连接记录：若没有相关连接，优先检查该应用自己的代理选项、浏览器扩展或既有 VPN 设置；若能看到连接，再分析它选择了什么策略。
手动代理的主机、协议和端口需要与实际监听一致。端口号应读取当前配置，不要照搬网上某个默认值。命令行程序也可能依赖环境变量。先确认一种明确的接入方式能工作，再考虑是否需要 TUN 接管其他流量。
使用命中记录区分规则问题与节点问题
有连接记录却失败时，查看目标域名、命中规则和最终代理。预期应代理的请求若走了直连，检查规则顺序和当前模式；预期直连的内网请求若被送到外部节点，检查内网规则。规则判断与节点连通性是两件事，应分别验证。
在授权使用的配置中选择另一个节点，保持目标地址和接入方式相同再测试。仅一个节点失败时，可能是该出口链路问题；所有节点失败而直连正常时，应继续查看节点地址解析、认证或提供方状态。这些是依据对照结果的推断，不能只凭红色延迟标签下结论。
恢复后完成验证，再停止改动
修复后连续打开两个不同站点，确认连接记录符合预期，再重启客户端复测一次。若两次均能稳定访问，就保留当前设置，停止同时修改 DNS、TUN 和规则。一次性“全套优化”会让故障再次出现时无法定位。
仍未解决时，整理操作系统、客户端与内核版本、失败范围、发生时间，以及去除敏感信息的错误片段。订阅链接、访问令牌、节点密码和完整配置不应公开。若访问恢复但只有某个程序异常，转向该程序的接入设置；若出现 bind 或 listen 报错，阅读端口冲突排查。
相关问题
延迟测试有数字，为什么网页仍然打不开？
测试地址与实际网站不同，测试结果只反映特定探测请求。还要检查网页请求的规则、节点、DNS 与应用代理入口。
先重新安装能解决吗？
重装无法直接修复基础网络或远端节点故障。先用日志和对照测试定位；需要重装时先备份，使用官方安装包。
资料与适用范围
本文以原创步骤解释操作思路，不声称已经在所有设备和版本上实测。菜单名称、默认值与兼容条件可能随版本变化，请结合当前项目说明核对。
需要修正内容？请阅读反馈与纠错，不要公开完整订阅或账户凭据。
