代理已连接但网页超时？按六个阶段缩小故障范围
代理显示已连接，但网站一直转圈时，先找到失败阶段：本地网络、客户端接管、节点连接、DNS、TLS，还是目标网站本身。错误越具体，排查范围越小。
本文不假设所有超时来自机场。按顺序做少量对照，比同时换节点、改 DNS 和重装客户端更容易保留线索。
第一步：确认原始网络可用
在安全保留现有配置的前提下，检查一个原本不依赖该代理就能访问的可信站点。公共 Wi-Fi 可能还没有完成正常登录，家中网络也可能短暂中断。
如果基础网络都不稳定，先解决这一层。不要用一个本来就不可达的目标作为“直连正常与否”的唯一判断。
第二步：请求是否进入客户端
查看与访问时间对应的连接记录，确认目标请求有没有进入客户端、命中什么规则、选择哪个出站。只看到客户端进程在运行，不等于浏览器正在使用它。
若没有对应连接，先核对系统代理、TUN 范围、浏览器扩展或应用自带设置。若进入了意外的直连规则，先解释规则匹配，再考虑节点质量。
第三步：按错误阶段走分支
| 线索 | 首先排查 | 暂时不要做 |
|---|---|---|
| 无法解析节点域名 | 入口域名与引导 DNS | 直接认定目标网站故障 |
| 无法建立节点连接 | 地址、端口、当前网络与服务状态 | 反复清空浏览器数据 |
| TLS 握手或证书错误 | 时间、服务名称、证书与参数 | 关闭证书验证当作修复 |
| 只有一个目标超时 | 目标路径、分流、目标服务状态 | 宣布全部节点不可用 |
| 多目标在同一节点失败 | 节点与接入网络对照 | 同时改所有配置 |
curl 官方的退出码说明也将解析、连接、超时与 TLS 等错误分开。即便使用其他客户端，也可以借鉴这种按阶段分类的思路；不能直接把不同软件的数字错误码当成同一种定义。
第四步：做一个小型交叉对照
保留目标 A 和目标 B，再选节点一与节点二，组成四次访问。条件允许时，用相同设备和接入网络、相近时间完成。
若只有目标 A 在两个节点都失败，调查目标或共同规则；若两个目标只在节点一失败，调查节点一及其路径；若四次都失败，回到共同因素。以上都是定位方向，不是最终归因。
必要时再换一个接入网络复测。不要在第一轮中就同时改设备、客户端、网络和节点，否则无法区分是哪个变化起效。
已经收到 HTTP 错误，算不算超时
不算同一阶段。收到 403、429 或 5xx 说明某个 HTTP 服务已经返回了响应，接下来应分析响应来自哪里及其含义。命令执行成功也不一定代表 HTTP 内容成功；curl 官方响应说明解释了两者的区别。
何时停止折腾并保留证据
重复对照没有新增信息时，记录时间、接入网络、客户端版本、失败目标与脱敏错误，提交给相应支持渠道。不要通过大量无间隔重试制造新的限流问题。