记录一下那天晚上的排查过程。在公司内网调 claude-3-5-sonnet-20241022，错误体是 {“type”:”error”,”error”:{“type”:”overloaded_error”}}，可 status.anthropic.com 上没有任何故障，同一份脚本从家里宽带跑就正常，内网出口走的是自建 Squid。
刚开始盯着「客户端重试间隔太短，同一个连接池被自己打满」，折腾了半个多小时，排掉了。
排查方向其实有限，先把可能性排一排。代理层把偶发的 5xx 一律改写成 529，看起来像服务端过载。还有一种是请求头里缺 anthropic-version，网关直接返回一个笼统的错误。
还有一种情况，SDK 把流式请求失败也归到过载分支，日志误导了判断。
先绕过代理直连一次，确认是不是网关改写
curl -sS https://api.anthropic.com/v1/messages -H "x-api-key: $ANTHROPIC_API_KEY" -H "anthropic-version: 2023-06-01" -H "content-type: application/json" -d '{"model":"claude-3-5-sonnet-20241022","max_tokens":32,"messages":[{"role":"user","content":"ping"}]}'接着抓一次原始响应头，看有没有网关自己的标记
curl -i -o body.txt -D head.txt https://api.anthropic.com/v1/messages -H "x-api-key: $ANTHROPIC_API_KEY" -H "anthropic-version: 2023-06-01" -d @payload.json本地复现时开 SDK 的调试日志，确认真正的失败层
ANTHROPIC_LOG=debug python -c "import anthropic;c=anthropic.Anthropic();print(c.messages.create(model='claude-3-5-sonnet-20241022',max_tokens=16,messages=[{'role':'user','content':'hi'}]))"别只看报错消失，验证要多做一步。直连与走代理两条路径都返回 200，响应头里不再出现网关注入的 X-Cache 标记，连续 50 次调用没有一条 529。
提醒一点。状态页只反映官方区域，中间任何一层反代都可能捏造出过载错误，先分清是谁回的包再谈重试策略。报错文案容易误导，真正的原因往往在相邻那一层的日志里。