先看现象，不要连续乱换设置

先记下设备、客户端版本、当前节点、规则或全局模式，以及报错原文。用同一个浏览器打开一个平时可直连的网站和一个当前出问题的网站。前者正常、后者失败，与两个都失败不是同一个问题。排查时每轮只改一项，否则恢复了也不知道是哪项起作用。

现象优先检查暂时不要做
直连网站也打不开Wi-Fi、蜂窝数据、认证页、遗留代理反复换海外节点
浏览器正常，某个软件失败该软件是否使用系统代理重装全部客户端
只有某个网站失败目标站状态、账号、规则命中认定整个网络都坏了
所有代理节点均失败订阅有效性、端口、DNS、网络对照直接关闭系统防火墙

第一层：建立一份不经过客户端的基线

  1. 在客户端中正常断开，关闭系统代理和 TUN；不要仅点窗口右上角关闭。某些客户端关窗口后仍留在托盘。
  2. 重新访问平时能直连的网站。如果仍失败，检查系统代理是否残留，或换手机热点测试。酒店、校园和公共 Wi-Fi 先完成它们自己的认证。
  3. 如果换到另一张网络就恢复，先把问题缩小到原网络。不要把运营商、路由器或认证问题当作账号失效。
Windows PowerShell；macOS / Linux 把 curl.exe 改成 curl
curl.exe --noproxy "*" --connect-timeout 8 --max-time 20 -I https://example.com

返回 HTTP 状态行说明至少收到了 HTTP 响应，不要求一定是 200。某些网站拒绝 HEAD 请求会返回 405，可以换成普通 GET。超时、域名无法解析、证书报错要分别记录；不要把这些不同错误都写成“连不上”。example.com 只作为基础连通目标，不能证明你的实际服务可用。

第二层：确认本地代理端口确实在服务

到客户端设置中读取实际 HTTP 或 mixed 端口。下例的 7890 只是演示，可能与你的软件不同。127.0.0.1 指当前电脑；把它填到另一台手机上，不会连接到这台电脑。不要拿 SOCKS 端口配成 HTTP，也不要把控制面板端口当作代理端口。

Windows：先测本地端口，再显式经过代理访问
Test-NetConnection 127.0.0.1 -Port 7890
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 8 --max-time 20 -I https://example.com

端口测试的 TcpTestSucceeded 为 True，仅说明 TCP 端口可连；第二条才开始检验代理是否能取回网页。端口拒绝连接时，先启动客户端内核并核对端口，不必切换节点。显式代理成功而浏览器失败时，检查浏览器扩展、系统代理和自动配置脚本。

第三层：从日志区分解析失败与出口失败

  1. 固定一个节点，打开客户端连接记录，访问一次出问题的网站，找到对应域名。确认这条连接命中的规则与实际出口，不凭节点列表的勾选位置判断。
  2. 出现 lookup、resolve 或 DNS timeout 时，先查 DNS 和节点域名解析。出现 connect timeout、connection refused 时，再查节点地址、端口、订阅和本地网络限制。
  3. 换一个已知可用节点，在同一张网络复测。再固定该节点换手机热点。这个两轮对照能区分线路问题和接入网络问题。

第四层：网站拒绝，不等于代理没工作

HTTP 403、429、登录验证或地区提示，通常意味着你已经到达某个服务器或网关，但请求被策略、限流、账号状态等条件拦下；不能单靠状态码确认响应来自目标站本体。检查页面内容、服务状态和账号权限。连接工具不会自动赋予账号订阅资格，也不能保证第三方服务接受某个出口。

证书错误应先检查系统日期、目标域名、客户端更新和受管理网络的证书配置。不要把 curl -k 或关闭证书验证当作常规修复；那会掩盖另一个问题。

验证是否修好，以及怎样提交有效反馈

  1. 回到日常使用的规则模式，在原网络中重试实际失败的网页和软件。
  2. 退出再启动客户端，确认修复仍有效；同时检查国内网站没有被影响。
  3. 仍失败时提供：时间与时区、设备和客户端版本、接入网络类型、错误原文、命中的规则和已做过的对照。隐藏订阅链接、token、账号和完整出口地址后再分享日志。

最终目标不是看到一个绿色按钮，而是能在正常配置下完成原本失败的操作。保留有效配置的备份；不需要的临时代理和测试改动应及时撤销。