问题排查9 分钟阅读更新于:2026-03-31

OpenAI 401 与 429 报错排查清单

基于 OpenAI 官方文档,快速定位 Unauthorized 与限流/额度类报错,并给出可落地处理步骤。

1)401:先区分认证问题还是策略问题

OpenAI 错误文档中,401 不止一种原因,包括认证失败与 IP 白名单不匹配等。不要把 401 当成单一问题。

建议先确认:当前使用的是哪把 Key、归属哪个项目、请求出口 IP 是否符合项目策略。

  • 核对 Authorization 头格式
  • 确认 Key 归属组织/项目是否正确
  • 检查 IP 白名单配置

2)429:区分速率限制与额度不足

OpenAI 常见的 429 包括“请求频率过快”和“额度/预算已用尽”,两者处理路径不同。

前者要做流量平滑与重试,后者要优先检查计费、limits 和项目预算。

3)按 RPM/RPD/TPM/TPD/IPM 理解限额

OpenAI 限额是多维度的,可能先撞到 RPM,即使 TPM 还没满,因此要同时看请求和 token 两个维度。

官方文档也强调:失败请求同样计入限额,盲目立刻重试会让问题更严重。

4)实现安全重试策略

对可重试错误使用带抖动的指数退避,并结合去重与超时预算,防止形成重试风暴。

同时把 max_tokens 调整到接近真实输出规模,因为限流计算会参考 max_tokens 的估算影响。

5)建立可执行的生产 Runbook

如果 401/429 问题反复出现,建议沉淀 Runbook:责任人、告警阈值、回滚方案、对外沟通模板。

在高峰期,标准化的短流程比临时排查更能保证恢复速度。

常见问题

为什么 token 看起来不高也会出现 429?

可能是 RPM 先触顶,或失败重试过多导致每分钟配额被提前耗尽。

如何区分额度问题和瞬时限流?

看错误文案最直接:'rate limit reached' 多为请求节奏问题,'current quota exceeded' 多与计费或额度上限有关。

出现 429 后要不要高频重试?

不建议。应先做退避重试并降低突发请求强度。

相关供应商

参考来源