Codex rate_limit_exceeded 限流错误排查

在国内网络环境里跑 Codex，最常见的报错不一定是模型本身不可用，而是请求链路里某一段不稳定。rate_limit_exceeded 看起来像“额度不够”或“请求太快”，但实际排查时，我一般先分两类：到底是服务端真的限流，还是因为代理、中转、超时重试导致请求被放大，最后触发了限流。

典型场景是：在 Cursor、VS Code 插件、Codex CLI 或自己的脚本里调用大模型 API，前几次正常，过一会儿开始报：

### token云桥中转 0029.org ###
{
  "error": {
    "message": "Rate limit exceeded",
    "type": "rate_limit_exceeded",
    "code": "rate_limit_exceeded"
  }
}

遇到这个错误不要急着换 Key，先按下面顺序查，能少走很多弯路。

一、先判断是网络问题还是配置问题

第一步不要直接从业务代码里看，因为业务代码可能带自动重试、并发队列、流式输出等逻辑，会干扰判断。建议先用最小请求验证链路。

1. 检查当前 base_url 是否正确

如果你使用的是官方接口，base_url 通常类似：

https://api.openai.com/v1

如果使用中转或企业网关，base_url 会变成对应服务商提供的地址。这里最容易出错的是：多写了 /v1/chat/completions，或者少写了 /v1。很多 SDK 会自动拼接路径，base_url 写错后可能出现 404、401，也可能被网关转成看起来像限流的错误。

可以先打印当前环境变量：

echo $OPENAI_API_KEY
echo $OPENAI_BASE_URL

Windows PowerShell 下：

echo $env:OPENAI_API_KEY
echo $env:OPENAI_BASE_URL

如果 Key 被截断、base_url 带了空格、末尾多了不可见字符，也会出现非常奇怪的问题。建议重新复制一遍，不要从聊天记录或富文本里复制。

2. 用 curl 做最小请求

先绕开 Codex 工具本身，直接请求接口，看返回是否稳定。

curl -sS -X POST "$OPENAI_BASE_URL/chat/completions" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-4o-mini",
    "messages": [
      {"role": "user", "content": "ping"}
    ],
    "max_tokens": 20
  }'

如果这个请求都经常超时、TLS 报错、连接被重置，那就先别看 Codex 配置，问题多半在网络、代理或中转链路。

二、检查代理和国内网络连通性

国内直连海外 API，稳定性会受网络环境影响。常见表现是：第一次请求慢，后面工具自动重试，多次请求叠在一起，最后服务端看到的是短时间内大量请求，于是返回 rate_limit_exceeded。

先看系统里有没有代理变量：

env | grep -i proxy

PowerShell：

Get-ChildItem Env:*proxy*

如果同时设置了 HTTP_PROXY、HTTPS_PROXY，又在工具里配置了代理，可能出现“双重代理”。建议先保留一种方式，保证链路简单。

也可以用下面命令观察连接耗时：

curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} total:%{time_total}\n" \
  "$OPENAI_BASE_URL/models" \
  -H "Authorization: Bearer $OPENAI_API_KEY"

如果 connect 或 tls 时间明显很长，说明还没到模型处理阶段，网络连接已经不稳定了。这种情况下，继续调并发参数意义不大，先换稳定链路。

实际项目里，如果团队在国内多地使用 Codex，我更倾向先找一个稳定的 API 中转做灰度测试，比如 token 云桥 AI 中转站 0029.org。重点不是“换了就一定好”，而是它方便统一管理 base_url、Key 和调用日志，先小流量跑通，再决定要不要长期用。

三、确认是否真的触发限流

如果网络没问题，curl 请求也能稳定返回，那就要看是不是请求频率、并发或 token 消耗超过限制。

1. 降低并发和自动重试

很多 Codex 类工具会同时发多个请求：补全、解释、上下文压缩、代码修改建议都有可能走 API。表面上你只点了一次，实际后台可能并发了好几个请求。

排查时建议先关掉不必要的自动功能，或者把并发调到 1。自己的 Node.js 脚本可以先这样限制：

const sleep = (ms) => new Promise(resolve => setTimeout(resolve, ms));

for (const task of tasks) {
  try {
    await callModel(task);
    await sleep(1200);
  } catch (err) {
    console.error(err.message);
  }
}

如果这样稳定了，说明不是 Key 坏了，而是原来的调用节奏太密。

2. 对 429 做退避重试

rate_limit_exceeded 通常对应 HTTP 429。不要立即循环重试，否则会越打越满。建议使用指数退避，并加一点随机抖动。

async function requestWithRetry(fn, maxRetry = 5) {
  for (let i = 0; i < maxRetry; i++) {
    try {
      return await fn();
    } catch (e) {
      const status = e.status || e.response?.status;
      if (status !== 429) throw e;

      const wait = Math.min(30000, 1000 * Math.pow(2, i)) + Math.floor(Math.random() * 500);
      console.log(`rate limited, wait ${wait}ms`);
      await new Promise(resolve => setTimeout(resolve, wait));
    }
  }
  throw new Error("retry exhausted");
}

注意，退避重试只是降低冲突，不是提高额度。真正的高并发场景，还是要拆队列、限速，或者申请更合适的配额。

四、超时设置不要太激进

国内链路下，超时设置太短会导致客户端误判失败，然后自动重试。比如 5 秒超时，看似能快速失败，但请求可能已经到达服务端并开始处理，只是响应没回来。你再次发起请求，就会形成重复调用。

建议开发环境先把超时设到 60 秒左右，稳定后再根据业务收紧：

const client = new OpenAI({
  apiKey: process.env.OPENAI_API_KEY,
  baseURL: process.env.OPENAI_BASE_URL,
  timeout: 60000
});

如果是流式输出，也要确认代理或网关支持长连接。部分网关会在几十秒无数据时断开连接，客户端以为失败后继续重试，也可能间接引发限流。

五、证书和 TLS 问题别忽略

有些内网环境会做 HTTPS 检查，或者公司代理会替换证书。表现可能是：

SSL certificate problem
unable to get local issuer certificate
certificate verify failed

不要为了省事直接关闭证书校验，尤其不要在生产环境设置：

NODE_TLS_REJECT_UNAUTHORIZED=0

正确做法是让运维提供代理根证书，并加入系统或运行时信任链。否则你后面排查 Key 泄露、请求被篡改会非常麻烦。

六、Key 安全和日志检查

排查限流时，经常会把 Key 贴到命令行、日志、CI 输出里。这里要特别小心：

• 不要把完整 Key 写进代码仓库。
• 不要在报错截图里暴露 Authorization 头。
• CI/CD 里使用密钥变量，不要写死在配置文件。
• 怀疑泄露时，优先轮换 Key，而不是继续观察。

如果你发现自己没怎么调用，但一直报限流，需要检查 Key 是否被其他环境复用。比如本地、测试机、CI、多人共用同一个 Key，都可能把配额打满。

七、建议的验证流程

最后给一个比较稳的验证顺序：

• 先用 curl 请求 /models，确认 Key 和 base_url 基本可用。
• 再发一个最小 chat/completions 请求，观察是否稳定。
• 关闭 Codex 工具里的自动并发和自动重试，只保留单请求。
• 逐步增加并发，每次观察 429 比例和响应时间。
• 记录请求时间、状态码、模型名、token 用量，方便定位峰值。

如果单请求稳定、多并发报错，重点查限速策略；如果单请求都不稳定，重点查网络、代理、中转和证书；如果只有某个工具报错，重点查它的 base_url 拼接、超时和重试配置。

总结

Codex rate_limit_exceeded 不要只理解成“额度没了”。在国内网络环境下，它经常和 base_url 配置、代理链路、超时重试、并发控制混在一起。排查时先用最小请求剥离工具因素，再看网络连通性，最后处理限流和重试策略。任何中转或代理方案都建议先小流量测试，确认稳定性、日志和 Key 管理方式都符合预期，再放到长期使用场景里。