Codex request timed out 全解析：8 类原因、诊断思路与一键修复

快速回答

"Codex request timed out" 不是一个 bug，而是一类现象。它背后至少有 8 类原因：网络层、代理配置、DNS、代理工具本身、Codex 服务端、请求体过大、并发限制、客户端 bug。修的前提是先定位是哪一类，否则就是瞎试。

8 类原因速览：

这篇是旧文《Codex request timed out 的 7 个修复》的深度扩展：旧文给"怎么修"，这篇给"为什么超时 + 怎么定位"。建议先读这篇建立诊断框架，再对照旧文的 7 个 fix 执行细节。

为什么先分类再修

超时的本质是：请求发出去了，但在规定时间内没收到完整响应。这个"没收到"可能发生在任何一个环节——发出前（DNS 失败）、建立连接时（TCP 不通）、TLS 握手（SNI 阻断）、传输中（丢包/重置）、服务端处理（过载）、等待响应（超时太短）。

乱修的问题是：修代理对 DNS 污染没用，换节点对请求体过大没用，调超时对限流没用。先分类，命中率才会高。

先分两层：客户端超时 vs 服务端超时

• 客户端超时：你的机器放弃等待。特征：Connection timeout after 30000ms、request timed out、fetch failed。通常是网络路径或配置问题。
• 服务端超时：请求到了服务端但响应慢。特征：等很久才报错、集中在高峰时段、前后请求都正常。

一条 curl 快速区分：

curl -sS -o /dev/null -w "HTTP %{http_code} in %{time_total}s\n" \
  https://api.openai.com/v1/models -H "Authorization: Bearer $OPENAI_API_KEY"

• 几秒内 401/200：端点健康，问题在具体请求或配置；
• 挂起/连接错误：网络根本到不了端点；
• 成功但很慢（数秒）：服务端延迟，应加大超时 + 加重试。

诊断决策树（30 秒定位）

不想看 8 类细节，可以走决策树：

1. 先跑 curl -I --max-time 20 https://api.openai.com/v1/models：
   • 超时 / 000 → 走第 2 步；
   • 快 401 → 网络通，跳到第 4 步；
2. 你是直连还是走代理？
   • 直连超时 → 大概率是网络层或 DNS（类 1 / 类 3）；
   • 走代理超时 → 用 curl -x 穿代理测，判断是节点坏（类 4）还是代理配置错（类 2）；
3. DNS 报 ENOTFOUND → 类 3；
4. 网络通但仍超时：
   • 只在长对话 / 大文件时超时 → 类 6；
   • 高频调用后开始超时 → 类 7；
   • 高峰时段、等很久才报错 → 类 5；
   • 旧版本、运行几分钟后固定超时、沙箱命令卡住 → 类 8。

8 类超时原因逐个拆解

1. 网络层

症状：connect ETIMEDOUT、curl 返回 000、所有外网请求都慢。

诊断：

curl -I --max-time 20 https://api.openai.com/v1/models
npm ping   # 同时看 npm 是否也慢，判断是不是整机网络问题

修复：确认网络本身；换网络环境；或改走国内可达的网关端点。

2. 代理配置

症状：浏览器能访问 OpenAI，终端 Codex 超时。原因是 CLI 不读系统代理。

诊断：env | grep -i proxy，确认终端里有没有代理变量。

修复：

export HTTPS_PROXY=http://127.0.0.1:7890
export HTTP_PROXY=http://127.0.0.1:7890
codex

注意：配错的代理比没有更糟——每条请求都进死隧道干等。干净测试：unset 全部代理变量再试一次。

3. DNS 污染 / 解析失败

症状：getaddrinfo ENOTFOUND、fetch failed。

诊断：

nslookup api.openai.com   # 看返回 IP 是否可疑
export NODE_OPTIONS=--dns-result-order=ipv4first  # IPv6 解析顺序问题可先试

修复：换 DNS（如 1.1.1.1 / 8.8.8.8）；或换不被污染的域名端点（网关）。

4. 代理工具本身

症状：代理进程在跑、端口也对，但就是超时。

诊断（穿过代理测）：

curl -x http://127.0.0.1:7890 -I --max-time 20 https://api.openai.com/v1/models

修复：401 = 节点可用；超时 = 节点本身被限流/挂了，换节点或换工具。

5. Codex 服务端过载

症状：集中在高峰时段、热门模型；等很久才超时；前后请求正常。

修复：不是网络问题。加大超时、加重试，或换有富余容量的上游网关分散峰值压力。

6. 请求体过大

症状：长对话、塞了大文件后超时；缩短后恢复正常。

修复：精简上下文（只发任务相关代码）；codex logout && codex login 清本地会话缓存；重启本地 daemon。

7. 并发限制

症状：高频调用后开始超时，用量面板出现 429 / 限速警告。

修复：不是网络问题。降低并发、等配额重置、提升档位，或通过网关在多上游间分摊。

8. 客户端 bug

症状：旧版本才出现的超时；运行几分钟后固定超时；沙箱里 ls 都卡住（exit 124）。

修复：

npm install -g @openai/codex@latest
codex logout && codex login
# macOS 沙箱静默阻断网络时：
codex --sandbox danger-full-access "your prompt"

一句话记忆法

• 类 1 / 3 / 4（网络 / DNS / 代理工具）→ 换通路；
• 类 2（代理配置）→ 改变量；
• 类 5 / 7（服务端 / 并发）→ 调上游或配额；
• 类 6（请求体过大）→ 减负；
• 类 8（客户端 bug）→ 升版本。

更粗暴的记法：网络问题换通路，配置问题改变量，服务端问题调配额，客户端问题升版本。

一键修复清单（按优先级）

1. curl 定位（1 分钟）——先分"客户端/服务端/网络不可达"；
2. 清理代理变量测一次（1 分钟）——排除"配错的代理比没有更糟"；
3. 更新 CLI + 重新登录（2 分钟）——排除旧版 bug 与过期 token；
4. 加大超时 + 重试（SDK 用户）——排除"等太短"；
5. 精简上下文 + 清会话缓存——排除"请求太大"；
6. 看用量面板——排除限流 / 配额；
7. 换国内可达网关端点——一次性消掉网络 / DNS / 代理三类原因。

预防措施

• 长期使用，优先网关直连：把 OPENAI_BASE_URL 指向国内可达、原生支持 /v1/responses 的端点（如 TeamoRouter），从源头消掉 DNS 污染、SNI 阻断、节点限流；
• 给超时与重试设合理值：交互短任务 30-60s，长 Agent 任务 120-300s + 2-3 次重试；
• 控制并发：避免一个 Key 多个工具共享导致 429；
• 保持 CLI 最新：超时类 bug 常随版本修复；
• 沙箱网络注意：macOS 上 shell 命令超时先查沙箱网络开关。

常见疑问（FAQ）

Q：超时和"被墙 / 被封"是一回事吗？ 不是。超时是"请求发出去了没收到响应"；被封是"请求被拒绝处理"（区域 / IP / 鉴权）。前者调网络与超时，后者要换接入方式。网关能解决前者的大部分，对后者也需要走合规接入。

Q：为什么时好时坏？ 间歇性超时通常指向负载、限流或路由抖动，不是硬配置错误。优先查限流，再走网关分散上游波动。

Q：超时值设多少合适？ 没有万能值。短交互几秒，大重构可能几分钟。起步 120-300s + 重试，再按你实际最长任务微调。

Q：重试越多越好吗？ 不是。端点真挂了，狂重试只是延长等待。保持 2-3 次，让错误浮出来才能定位根因。

Q：VPN 能一劳永逸吗？ 有时能（如果是路由问题），但抖动的 VPN 本身也会造成超时。更稳的是换一个稳定可达的网关端点，而不是依赖隧道。

Q：8 类原因里，最常见的是哪几类？ 在国内网络环境下，最常见的是网络层、代理配置和 DNS（类 1 / 2 / 3），而且它们经常一起出现——所以"换国内可达的网关端点"能一次性消掉这三类。

Q：换了网关是不是就一劳永逸了？ 对网络 / DNS / 代理类超时基本是。但请求体过大、并发限制、客户端 bug 这类与网络无关，网关解决不了，仍要按类处理。

小结

Codex request timed out 的 8 类原因，各有各的修法。先分类、再动手：用 1 分钟 curl 定位层，用一键修复清单按优先级试，最后用网关直连做预防。推荐配合旧文《Codex request timed out 的 7 个修复》的执行细节一起用。注册 TeamoRouter，把网络 / DNS / 代理三类超时一次消掉。