摘要：Codex 429 Too Many Requests表示请求被限流，来源分三类：官方容量或短时限制、API额度与支出上限、第三方网关合成错误，处置方式完全不同。
- 先读完整error.code与Retry-After，容量类遵守等待，不要连点重试。
- 额度类429等待与换网络都不补余额，按credit与spend limit对应项处理。
- 第三方网关合成的upstream_reset_replay_refused要查连接重置，不是真限流。
适用人群：使用Codex CLI、桌面端或经第三方网关接入的开发者与团队。
任务跑到一半，Codex回一句Codex 429 Too Many Requests，紧接着是「请稍后再试」。429是所有报错里最容易误伤自己的一个：连续狂点重试会加重排队，换网络对余额类限流毫无作用，而把网关合成的错误当成官方限流，则会查错方向。本文按「判断来源—成因对照—按error.code分流处理—请求路径影响」展开，把三类429彻底分开。
目录
- 一、快速判断：Codex 429来自哪一端
- 二、Codex 429的四类来源对照
- 三、按error.code分流的五步处理
- 四、Codex 429的产生端：目标服务还是网关
- 五、常见问题 FAQ
- 总结
一、快速判断：Codex 429来自哪一端
| 现象 | 可能原因 | 优先排查 |
|---|---|---|
| 响应带Retry-After与turn_rate_limit_exceeded | 官方容量或短时限制 | 停止连点，等满指定时长后小请求复测 |
| 提示credit、spend或usage limit相关字样 | API额度或支出上限 | 按认证方式进入额度分支（步骤3） |
| 经第三方网关出现，errorCode为upstream_reset_replay_refused | 网关合成的连接重置错误 | 查传输层，不当限流处理（步骤4） |
| 同一时段大量用户同时出现 | 官方容量事件 | 查状态页，等待恢复 |
429只是一个状态码，不带正文无法定因。拿到完整error.code、Retry-After、认证方式与错误产生端这四项信息之前，任何「恢复操作」都是猜测。
二、Codex 429的四类来源对照
| 来源 | 典型特征 | 可控性 |
|---|---|---|
| 官方容量/短时限制 | error.code为turn_rate_limit_exceeded，响应带Retry-After（有案例为205秒），文案为at capacity | 低，遵守等待与退避 |
| API余额或支出上限 | credit_balance_exhausted、organization_spend_limit_exceeded等明确code | 高，补余额或调上限 |
| 项目或组织usage limit | organization_usage_limit_exceeded，平台级用量上限 | 中，申请提额 |
| 第三方网关合成429 | upstream_reset_replay_refused，连接重置被网关包装为429 | 中，维护者查传输失败 |
一个常见的推理错误要避开：用「我周额度还有余额」证明「限流不可能」并不成立。已有案例返回turn_rate_limit_exceeded、capacity文案和Retry-After，但这些信息不足以推导具体计数方式、并发上限或是否按出口IP限流，应以完整响应和官方说明为准。
认证与链路的长期配置方法，可参考ChatGPT网络专题。
三、按error.code分流的五步处理
1.读完整响应
记录429完整正文、error.code、Retry-After、响应头、认证入口、所用模型、是否经过中转、时间与request ID，停止一切额外连点与并行重试。
判定：要素齐全才进入分流，并确认响应是OpenAI返回还是第三方网关产生——只看HTTP状态码无法区分。
2.速率与容量类处理
有Retry-After先按值等待（案例值为205秒，不是统一等待时长）；无该头时，用有次数与总时长上限的指数退避加随机抖动，避免多个客户端同时重试。slow_down等速率线索归本分支：降低发送频率、拆小任务。
判定：等待后用同认证、同模型的小任务验证，真实完成再逐步恢复工作量；失败返回对应code分支，不无限重试。
3.额度类分流（仅API Key认证）
credit_balance_exhausted给正确的API组织补余额；organization_spend_limit_exceeded由管理员调整组织支出上限或等周期重置；project_spend_limit_exceeded核对项目级上限；organization_usage_limit_exceeded申请提高平台用量上限。
注意：ChatGPT订阅与API是两套计费，付订阅费不等于给API充值；平滑请求速率补不回余额。
4.网关合成429（第三方OpenCodex仓库案例）：
errorCode为upstream_reset_replay_refused的错误，是OpenCodex网关对连接重置拒绝不安全重放的合成错误，不是OpenAI官方统一错误码，不能推广到所有中转，不建议盲目打开retryOnReset。
维护者处理路径：确认请求是否已执行，未执行才评估重放；保留连接重置记录与请求实际发送次数，查传输失败日志。
5.条件性绕过与失败下一步
重登后短暂恢复、某模型小请求曾成功都属于个案线索。所有分支失败时，保留脱敏响应、request ID、时间、客户端版本与网关日志，按实际产生端（OpenAI或网关）分别反馈。
四、Codex 429的产生端：目标服务还是网关
HTTP 429只说明「请求被拒绝」，不说明「谁拒绝的」。它可能来自OpenAI目标服务，也可能由第三方网关自己产生：官方限流等Retry-After、补额度即可；网关合成错误要查网关自己的传输日志。方向定错，后续全白查——对着合成错误调重试节奏越调越乱，对着真实限流改网关配置改完照弹。
判别靠两样东西：error.code与网关传输日志。网关合成错误带有网关自己的errorCode标识，与官方限流的错误码族不同，仅凭HTTP状态码无法区分。每遇到429，把响应里的code与网关日志中同一request ID的记录并排看，产生端一目了然。
团队层面两条纪律：各成员用各自的授权账号，由客户端或调度层统一控制并发与指数退避，避免多客户端同时重试——出口本身不控制请求节奏；经网关接入的，把合成错误与上游真实状态分开统计，别让合成错误污染限流判断。
固定归属线路只对日志归因与对照有帮助，没有被证明能够解除余额、容量或速率限制；排查顺序不能倒置。
五、常见问题 FAQ
Codex 429 Too Many Requests是账号被封了吗？
不是。429是限流状态码，来自容量、额度或网关三类来源，与账号封禁无关。按error.code分流后，等待或补足对应额度是主要路径。
为什么额度还有余额还是429？
周额度尚有剩余，也不能排除其他短时限制或服务容量拒绝。已有案例返回turn_rate_limit_exceeded、capacity文案和Retry-After，但这些信息不足以推导计数方式、并发上限或是否按出口IP限流，以完整响应和官方说明为准。
重登或新开聊天能解除429吗？
不能作为已验证方案。有个案重认证后短暂恢复，也有新开聊天仍失败的反例。失败下一步：保留脱敏响应、request ID、时间、版本与网关日志，按实际产生端反馈。
第三方网关一直报429怎么办？
先看errorCode是不是upstream_reset_replay_refused——那是OpenCodex网关对连接重置的合成错误，不是真限流。维护者确认请求是否已执行、查传输失败日志，不要盲目换账号、换出口或打开retryOnReset。
怎样降低429出现的频率？
速率类按Retry-After等待并平滑请求；余额或支出上限按对应code处理；服务容量问题可能仍需等待；网关合成429查其传输日志。固定出口没有被证明能够解除这些限制。
相关文章推荐
 |
Selected model is at capacity 是什么意思？2026年Codex模型爆满的4类原因与3套恢复方案 |
 |
Codex app-server is not available怎么解决？2026年报错的5类成因、排查顺序与网络出口选型 |
 |
Codex 地区不支持怎么办？2026 年原因排查与跨境访问解决方法 |
总结
Codex 429 Too Many Requests的处理主线：读全error.code、Retry-After与响应头，定位429是OpenAI返回还是网关产生；容量类遵守等待，额度类按对应code补足，网关合成错误交维护者查传输层。重登与新开聊天只是条件性绕过，不是修复。团队场景由各成员使用自己的授权账号，并发与退避交给客户端和调度控制。需要固定归属线路做日志归因对照的读者，可注册IPdodo海外AI网络。
原文链接：https://www.ipdodo.com/news/23722/
