Claude Code 报 529 Overloaded 是服务崩了吗？原因与应对

在使用 Claude Code 的过程中，终端突然开始刷 529 Overloaded · Retrying in 29s · attempt 8/10，等待几分钟后仍然没有恢复，于是不少人开始怀疑：是自己的账号出问题了，还是本地网络被墙了？同一时间段里，往往有一批人遇到完全相同的报错，恢复时间也基本一致——这本身就说明问题不在单个用户身上。

下面把这轮故障里出现的现象、误判和可行做法整理一遍，方便下次再遇到时快速定位，少走弯路。

529 到底是什么：服务端容量不足

529 并不是标准的 HTTP 状态码，而是服务方自定义的一个状态，用来表示服务整体过载，也就是请求量超过了当前可用的推理容量。返回体通常长这样：

{
  "type": "error",
  "error": {
    "type": "overloaded_error",
    "message": "Overloaded",
    "details": null
  },
  "request_id": "req_011CeM3g41NWFbyqTvdfSKP9"
}

关键点有三个：

• 它是全局性的，而不是针对某个账号的限额；
• 它不是网络层错误，换节点、换 VPN、换 DNS 都不会改善；
• 它通常会在一定时间后自行恢复，但持续时间不可预期。

很多人第一反应是“我号是不是没了”，这属于对错误类型的误读。账号层面的问题会返回 401/403，配额问题返回 429，只有 529 才代表“服务方自己扛不住了”。

客户端那串重试提示在做什么

Retrying in 29s · attempt 8/10 表示客户端正在做指数退避重试：间隔会从几秒逐步拉长到几十秒甚至几分钟（有人看到过 3m 26s 这种量级），最多重试 10 次。到上限后就会放弃本次请求。

因此有两个常见误会：

• 以为卡死了：其实它一直在按计划重试，只是间隔很长，看起来像没反应；
• 以为换网络能救：切了好几次节点依旧跑不动，正说明问题不在链路。

真正有效的做法只有两种：等，或者换一条当前还有余量的路径。

遇到 529 的检查清单

按顺序做，通常几分钟内就能判断出结论：

1. 先查官方状态页（如 status.claude.com）。如果显示容量异常或事故进行中，那就不用再折腾本地环境，等公告即可。
2. 换更轻量的模型试一次。多轮反馈表明，同一个时间段里较大的模型可能持续 529，而较小的模型（如 Sonnet 系列）仍可正常出结果。用 /model 切换后重跑一条简单指令即可验证。
3. 确认不是认证问题。如果报错里带 401、invalid_api_key 之类字样，才需要重新登录或更换密钥；纯 overloaded_error 不要动凭证。
4. 降低并发。同时开多个会话、跑并行子任务、批量改文件，都会成倍放大请求量，在容量紧张时更容易被拒。先降到单会话单任务。
5. 减少单轮上下文。超长会话每次都要重新发送大量内容，等于持续给已经拥堵的服务加压。可以新开会话、把任务拆小。
6. 手动退避。不要连续狂敲回车触发新一轮请求，给它几分钟冷却时间，比反复重试更省时间。
7. 长时间任务考虑更稳的运行环境。如果任务是挂着跑批处理、要连续在线几小时，本地机器休眠、Wi-Fi 抖动都会让重试链路中断。这类场景可以把会话放到长期在线的远程 Mac 上运行（整机在新加坡机房、按月租用、远程连接），网络环境相对稳定，不会因为本地待机把正在重试的会话掐掉——但这只解决“别断线”，解决不了服务方本身的过载。

恢复节奏为什么每次不一样

容量问题的持续时间取决于请求高峰与扩容速度，没有固定规律。有人十几分钟就恢复正常，也有人等了一两个小时。能做的判断只有两条：状态页是否转绿、自己发一条最简单的请求能否通过。

需要提醒的是，状态页、模型可用性、各套餐的限额策略都属于时效性较强的信息，具体以官方最新说明为准，不要照搬旧经验。

不建议做的事：第三方中转与共享账号

每次大规模故障，都会有人问“有没有量大管饱的中转”。这里需要说清楚风险，而不是给路径：

• 数据暴露：代码、提示词、密钥都会经过第三方服务器，是否留存日志、留存多久完全不可控；
• 凭证风险：共享或转售的账号、密钥可能被多人复用，一旦触发风控，损失的是你自己的项目和额度；
• 稳定性反而不如官方：中转层本身也会过载、也会跑路，故障时你将面临“上游挂了 + 中间商也挂了”的双重不可用；
• 合规问题：绕过平台的使用限制、买卖账号，通常违反服务条款，可能导致封禁。

更稳妥的替代是走官方支持的接入方式：官方订阅、官方 API，或在主流云平台上提供的托管接入渠道。这些渠道同样可能遇到容量问题，但至少责任边界清晰、数据流向可控。

几个降低被打断概率的习惯

• 关键任务错峰：把大批量生成、全仓库重构放到非高峰时段；
• 任务拆小、勤落盘：每完成一个可验证的小步骤就提交一次，故障恢复后不用从头再来；
• 脚本化重试：对必须跑完的批处理，用外层脚本捕获 overloaded_error 后延时重跑，而不是靠人盯着；
• 保留一条轻量通道：主模型不可用时，先用小模型完成格式整理、单测补全这类不依赖强推理的工作；
• 关注官方状态与公告：故障期间的“补偿”“重置”之类说法，在官方未明确之前都只能当作传闻。

小结

529 Overloaded 是服务端容量不足的信号，不是账号异常，也不是本地网络故障。遇到时的正确顺序是：看状态页 → 换轻量模型验证 → 降并发降上下文 → 等待恢复。真正需要警惕的是病急乱投医——换节点、买中转、借账号，既解决不了容量问题，还会额外引入数据与合规风险。把任务拆小、把重试脚本化，才是能在下一次故障里少损失时间的方式。