Claude 报 500/529 错误：怎么判断是服务故障还是本地问题

某天下午开始，调用 Claude 的接口成片返回 500 Internal server error 和 529 Overloaded，流式输出卡住不出字，思考过程也看不到。第一反应几乎都是怀疑自己：有人反复切换代理节点，有人重装客户端，有人干脆退出登录想重来一次，结果连登录页都进不去，只能干等。还有人盯着刚刷新的额度发愁，担心这一下午的失败请求把配额耗光。

这类场景在每次模型服务波动时都会重演。它其实可以拆成三个问题：怎么快速确认是不是服务端挂了、故障期间该做什么不该做什么、以及直连和中转到底怎么选。下面按这个顺序整理成一套可复用的流程。

先看错误码，再决定要不要折腾本地环境

不同的报错指向完全不同的责任方，先定性再动手，能省掉大量无用排查。

如果报错文本里已经明确写了这是 server-side issue（服务端问题，通常是临时的），那就不要再动自己的配置了——换节点、重装、清缓存都不会让它变快。

判断顺序

1. 打开官方状态页（status.claude.com），看有没有处于 Investigating / Identified / Monitoring 阶段的未决事件。故障通报通常会分批说明「哪些模型已恢复、哪些仍在处理」，别只看标题就下结论。
2. 横向换一个入口：同一账号分别用网页端、桌面端、命令行工具各发一个最小请求，看是否全都失败。
3. 纵向换一个模型：是全部模型都不可用，还是只有某个模型在报错。前者多半是平台级问题，后者可能是单模型容量问题。
4. 看时间线是否吻合：同一时间段出现大量同类报错，基本可以判定为服务端故障，而不是你的网络。

故障期间的稳妥做法

• 不要退出登录、不要清 cookie。认证服务和推理服务经常是两套系统，前者抖动时退出就登不回去，反而把可用的会话弄丢。
• 不要把重试写成循环轰炸。改成带抖动的指数退避，失败几次就停下来看状态页，避免自己给自己叠加上游限流。
• 长任务要能断点续跑。把输入、已完成片段和请求标识落盘，恢复后从断点继续，而不是从头再来一遍。

import random, time, httpx

def call_with_backoff(payload, max_retries=4):
    for attempt in range(max_retries):
        try:
            resp = httpx.post(url, json=payload, timeout=60)
            if resp.status_code in (429, 500, 502, 503, 529):
                raise RuntimeError(f"upstream {resp.status_code}")
            resp.raise_for_status()
            return resp.json()
        except Exception:
            if attempt == max_retries - 1:
                raise
            delay = min(2 ** attempt, 30) + random.uniform(0, 1)
            time.sleep(delay)

• 记录请求时间和返回码。真有计费或配额争议时，这些日志是唯一能拿出来的证据，比事后回忆有用得多。

流式中断、看不到思考过程，多半不是你的网络

「能拿到回复，但一个字一个字卡住」或「干脆没有思考过程」是服务端降级时的典型表现：流式依赖长连接，后端排队或超时的时候最先坏的就是它。可以先做两个验证：把 stream 关掉再请求一次，看非流式是否正常；再检查自己的链路里有没有做缓冲的中间层（反向代理、企业网关），必要时关掉响应缓冲。

同时把 SDK 超时和重试参数调合理：流式场景超时设得太短，会把正常的慢响应误判成失败，反而触发更多重试。

直连挂了、中转却能用的原因与代价

故障期间确实存在「官方直连全挂、部分第三方中转还能用」的情况。常见原因有几种：中转方有多个上游来源和多个区域路由，某些来源没有受影响；或者它做了队列、缓存和失败重放。但这背后有取舍需要想清楚：

• 模型来源不透明：同一个名字背后可能对应不同来源，版本、上下文长度、参数支持度未必一致，返回可能是缓存结果或降级模型，「看起来成功」不等于真的成功。
• 数据经过第三方：提示词和输出都会落到别人的日志里，涉密或有合规要求的业务不适合走这条路。
• 配额与计费口径不同：用量统计、限流规则和官方对不上，出问题很难追溯。

所以更稳妥的分工是：中转可以作为应急渠道或非敏感场景的低成本选择，生产链路仍以官方直连、自己维护重试与监控层为主。

关于额度与补偿，别抱预期

失败请求是否计入用量、中断期间消耗怎么算，要看官方用量面板和账单口径，自己核对一遍最可靠。不要为了「测试是否恢复」反复发大请求，也不要默认服务中断一定会补发额度或重置配额——那属于平台的自主决定，不是可依赖的规则。相关说明请以官方最新公告为准。

不要碰的几类操作

故障期间往往有人兜售「共享账号」「内部渠道密钥」「特殊线路」。这些做法存在账号被封、余额打水漂、密钥和对话数据外泄的风险，出了问题没有任何申诉空间。合规的替代路径是使用官方支持的地区与套餐、走企业合同，或者选择有明确主体和数据处理条款的云厂商托管渠道。

五分钟排查清单

1. 状态页是否有未决事件，恢复阶段通报说了哪批模型。
2. 网页端、桌面端、CLI 是否同时失败。
3. 换模型是否仍然失败。
4. 关闭流式是否恢复正常。
5. 关闭代理或换一条干净链路，是否改变结果（用最小请求测试，不要用长对话）。
6. 用量面板里失败请求的消耗是否符合预期。
7. 重试逻辑是否有上限、是否带退避和日志。

什么时候值得换执行环境

有一种情况容易和服务端故障混淆：本地网络抖动、笔记本休眠、代理掉线导致长任务中断，报错信息看起来一模一样，但状态页干干净净。如果经常需要无人值守地跑 Claude Code 这类命令行工具，可以把执行环境放到一台长期在线的远程机器上，例如整机托管在新加坡机房的独享 Mac mini，按月租用、远程连接使用，网络环境相对稳定，也不受本地合盖休眠影响。它解决的是「本地环境不稳」这一环；平台自身故障时，它一样会返回 500，重试和监控仍然要做。

小结

先查状态页定性，再看错误码分工，最后才动配置；故障期间守住「不登出、不轰炸重试、长任务能续跑」三条；直连与中转按数据敏感度和可追溯性来选。错误码和故障通报的具体表述会随平台更新变化，实际排查时以官方状态页和文档的最新说明为准。