Codex 429 Too Many Requests 限流错误解决方法Codex 或兼容 OpenAI API 的工具在国内网络环境下调用模型时遇到429 Too Many Requests很常见。这个错误不一定都是“账号没额度”也可能是请求太密、并发太高、网关重试放大、代理不稳定甚至是base_url配错后打到了错误的服务端。我一般不会一上来就改代码而是先按顺序确认请求有没有真正发出去、打到的是哪个地址、Key 是否匹配、是否存在自动重试、是否短时间并发过高。下面按实际排查流程整理。一、先判断是网络问题还是配置问题429 的含义是服务端认为你请求过多但在中转、代理、公司网关参与的情况下错误来源不一定是模型服务本身。第一步建议把完整响应头和响应体打印出来。### token云桥中转 0029.org ### curl -i \ -X POST https://你的-base-url/v1/chat/completions \ -H Authorization: Bearer sk-xxxx \ -H Content-Type: application/json \ -d { model: codex-mini-latest, messages: [ {role: user, content: ping} ], max_tokens: 20 }重点看这几项HTTP/1.1 429后面的响应体是模型服务返回还是代理网关返回。响应头里有没有retry-after如果有说明服务端明确要求等待一段时间。是否出现cloudflare、nginx、公司网关标识这会影响判断。同一个 Key 换网络是否正常比如本机宽带、手机热点、服务器分别测试。如果 curl 都不稳定先不要怀疑业务代码。反过来如果 curl 稳定只有项目里报 429就要查 SDK 的并发、重试和超时配置。二、检查 base_url 和 Key 是否成对匹配很多人把 Codex 接到 Cursor、VS Code 插件、CLI 或自建服务时只改了 Key忘了改base_url或者用了中转地址却还在请求官方地址。这样会出现各种看起来像限流的问题。一个基本原则是base_url和api_key必须来自同一套服务。如果使用中转站就用中转站提供的地址和 Key如果直连官方就使用官方 Key 和官方地址不要混搭。# Linux / macOS 临时设置 export OPENAI_API_KEYsk-xxxx export OPENAI_BASE_URLhttps://你的-base-url/v1 # 检查是否生效 echo $OPENAI_API_KEY echo $OPENAI_BASE_URLNode.js 项目里可以这样显式指定避免环境变量被旧配置覆盖import OpenAI from openai; const client new OpenAI({ apiKey: process.env.OPENAI_API_KEY, baseURL: process.env.OPENAI_BASE_URL, timeout: 60000 });Python 项目同理from openai import OpenAI client OpenAI( api_keysk-xxxx, base_urlhttps://你的-base-url/v1, timeout60 )国内网络下如果直连经常超时或波动可以考虑走稳定的 API 中转。实际使用里我会先用小请求压测几分钟再决定是否长期放到生产环境。比如 token云桥AI中转站 0029.org可以作为 Codex、OpenAI 兼容接口接入时的一个备选方案重点还是看延迟、错误率、账单和日志是否符合自己的项目要求。三、429 的几种常见原因1. 并发过高最常见的是代码里同时发起几十个请求尤其是批量生成、代码分析、自动补全场景。单次看不出来但插件或任务队列会在后台瞬间打满。处理方式是加并发控制例如 Node.js 用简单队列限制同时请求数import pLimit from p-limit; const limit pLimit(3); const tasks prompts.map(prompt limit(() client.chat.completions.create({ model: codex-mini-latest, messages: [{ role: user, content: prompt }] })) ); const results await Promise.all(tasks);2. 自动重试放大流量不少 SDK、代理层、网关都会默认重试。一次超时可能被重试 2 到 3 次多个并发叠加后很容易触发限流。建议明确设置重试次数并对 429 做退避等待。async function sleep(ms) { return new Promise(resolve setTimeout(resolve, ms)); } async function callWithRetry(fn, maxRetry 3) { for (let i 0; i maxRetry; i) { try { return await fn(); } catch (err) { const status err.status || err.response?.status; if (status ! 429 || i maxRetry - 1) throw err; const wait Math.min(1000 * Math.pow(2, i), 8000); await sleep(wait); } } }注意不要写死“立即重试”。429 后立刻循环请求只会让限流更严重。3. Token 消耗过大有些限流不是按请求数而是按单位时间内的 token 量。一次塞入很长上下文或者让模型输出几千 token也会触发限制。排查时可以先把max_tokens调小确认是否和 token 量有关。{ model: codex-mini-latest, messages: [ {role: user, content: 只返回一句话测试} ], max_tokens: 50 }四、代理、证书和超时设置国内环境经常会经过代理软件、公司网关、云服务器出口。网络抖动时客户端可能误以为请求失败并重试最终表现成 429。因此超时要设得合理不能太短。交互式工具建议超时 30 到 60 秒。批处理任务可以放到 60 到 120 秒并配合队列。不要同时在 SDK、Nginx、任务队列三层都做激进重试。如果遇到证书错误例如certificate verify failed不要直接关闭证书校验。优先检查系统 CA、代理证书和服务器时间。# 查看系统时间 date # 测试 TLS 握手和证书链 openssl s_client -connect 你的域名:443 -servername 你的域名在公司内网使用代理时也要确认环境变量是否污染了请求env | grep -i proxy # 临时取消代理测试 unset HTTP_PROXY unset HTTPS_PROXY unset ALL_PROXY五、Key 安全和日志注意事项排查 429 时很多人会把完整请求贴到群里这里最容易泄露 Key。建议做到几件事日志里只保留 Key 前后几位例如sk-abc...xyz。不要把 Key 写进前端代码、浏览器插件配置截图、公开仓库。服务器使用环境变量或密钥管理服务不要硬编码。怀疑泄露时先停用旧 Key再生成新 Key。如果通过中转服务调用也要关注后台是否能查看用量、是否支持分 Key 管理、是否能限制额度。生产环境最好给不同项目分配不同 Key方便定位异常流量。六、一个推荐的验证顺序最后给一个比较稳的验证流程适合从“完全不可用”排到“偶发 429”。第一步用 curl 发最小请求确认base_url和 Key 可用。第二步换网络测试判断是否和本地出口有关。第三步关闭业务并发只跑单请求。第四步把max_tokens调小观察 429 是否减少。第五步加入指数退避不要立即重试。第六步观察响应头、服务端日志和中转后台用量。# 连续低频测试不建议高频压测 for i in {1..5}; do echo request $i curl -s -o /dev/null -w %{http_code} %{time_total}\n \ -X POST https://你的-base-url/v1/chat/completions \ -H Authorization: Bearer sk-xxxx \ -H Content-Type: application/json \ -d {model:codex-mini-latest,messages:[{role:user,content:ping}],max_tokens:20} sleep 3 done总结Codex 429 不要只盯着“额度不够”。更常见的原因是base_url配置混乱、并发过高、自动重试过猛、网络代理不稳定或 token 消耗过大。排查时先用最小请求确认链路再逐步恢复并发和业务逻辑。国内环境下可以评估中转方案但建议先小流量测试延迟、错误率和日志再决定是否长期使用。