DeepSeek API 503 / 服务繁忙排查指南
503 这类错误最容易让人误判成“模型挂了”。但在实际排查里，503 可能来自官方服务波动、代理网关拥塞、重试风暴，甚至是你自己的并发策略过猛。
遇到服务繁忙、网关拥塞或中转抖动时，怎么区分临时波动和系统性问题。
适合谁看
适合正在接第三方模型 API、做兼容层、排线上报错的开发者和团队。
这篇会回答
• 先确认 503 来自哪一层
• 服务繁忙时要避免重试风暴
• 要给业务链路预留降级出口
这篇在专题里的位置
围绕 401、402、429、503、504、流式输出、兼容接口、Key 管理和网关接入，先解决“能不能稳定跑起来”。
Claude API 接入清单
从模型选择、请求结构到限流与日志，梳理一份更稳的接入流程。
Claude acceleration limits 是什么，为什么刚放量就 429
根据 Anthropic 官方文档，拆开讲 acceleration limits、短时间突发流量和 rate limit 的区别，方便你判断为什么总量没超、请求还是被卡。
Claude API 401 authentication_error 怎么排查
根据 Anthropic 官方错误文档和 API 接入说明，拆开讲 Console Key、请求头、版本头和代理转发问题，方便你快速定位 Claude API 的 401 authentication_error。
先确认 503 来自哪一层
如果你前面套了中转层、反向代理或工作流平台，503 不一定是模型服务自己返回的。
第一步不是盲目重试，而是先从响应头、错误体和访问日志判断，到底是上游模型、代理节点还是你自己的应用网关在报错。
直连官方接口是否也会报错
同一时间别的模型是否正常
错误高峰是否集中在固定时段
代理层是否开启了过于激进的限流
服务繁忙时要避免重试风暴
最危险的做法不是报错本身，而是客户端同步发起大批量无退避重试，这会把短时抖动放大成连锁故障。
更稳的方式是指数退避、随机抖动，再配合并发上限和排队机制，把请求洪峰压平。
要给业务链路预留降级出口
如果摘要、改写、表格清洗这类任务允许延后，最适合切到异步队列或结果回调，而不是硬顶着同步接口等待。
对用户可见的页面则要明确提示正在排队、切换备用模型，或者让用户稍后重试，避免把 503 直接暴露成“系统不可用”。
常见问题
503 和 429 有什么区别？
429 更偏向配额或限流，说明请求频率超了控制阈值；503 更偏向服务暂时不可用，通常和上游拥塞、网关压力或节点异常有关。
服务繁忙时要不要立刻切备用模型？
要看任务时效。如果是核心链路且容错要求高，建议直接切到备用模型；如果任务允许排队，先限流和退避通常更省成本。
继续沿着这条主线看
这部分不再重新给你一堆大卡片，而是直接把下一步阅读顺序列出来，方便继续往下走。
Claude API 接入清单
从模型选择、请求结构到限流与日志，梳理一份更稳的接入流程。
Claude acceleration limits 是什么，为什么刚放量就 429
根据 Anthropic 官方文档，拆开讲 acceleration limits、短时间突发流量和 rate limit 的区别，方便你判断为什么总量没超、请求还是被卡。
Claude API 401 authentication_error 怎么排查
根据 Anthropic 官方错误文档和 API 接入说明，拆开讲 Console Key、请求头、版本头和代理转发问题，方便你快速定位 Claude API 的 401 authentication_error。
Claude API 529 overloaded 怎么处理
根据 Anthropic 官方错误文档、Rate Limits 和状态页，拆开讲 529 overloaded 与 429、401 的区别，以及线上更稳的重试、降级和观察路径。