博客 / 排障指南

10 月 6 日 ChatGPT 挂了、Codex 和 API 报错：4 步判断是官方故障还是你的网络

2026-10-19cdnping 编辑部约 3 分钟读完

ChatGPT 挂了、Codex 报错、API 返回错误，如果发生在 2026 年 10 月 6 日，多半是官方故障：OpenAI 状态页当天记录了多起事故，其中一条的标题就是“Elevated errors across ChatGPT, Codex, and the API including the Agents API”。不过每次遇到报错，都值得用几分钟把官方故障和自己的网络问题分开，下面是做法。

以下内容截至 2026 年 10 月，事件信息来自 OpenAI 状态页历史记录，状态页时间未标注时区，这里不换算。

#10 月 6 日发生了什么？

状态页当天列出的事故不止一条，按标题归纳如下：

此外当天还有 Work 模式错误、Computer Use 异常等条目，这里不展开；各条目的恢复状态以状态页为准。之后几天仍有相关记录：10 月 7 日有 Codex 与 Work 模式性能下降，10 月 13 日和 14 日分别有 Codex、ChatGPT Work 的性能下降，10 月 15 日出现标题为“Widespread feature degradation”的事故。具体根因和时长以状态页事故详情为准，本文不做推测。

#怎么快速判断是官方故障还是自己的网络？

按从外到内的顺序查，每一步都能排除一类原因。

1. 看官方状态页。 打开 status.openai.com，找当天的事故。有对应条目，基本可以确认是服务端问题。
2. 看多人报告和探测。 状态页有时会滞后。cdnping 的 /down/chatgpt 和 /down/codex 综合官方状态页、每 5 分钟的 API 探测和用户一键报告，可以看到有没有别人同时遇到问题。
3. 看边缘探测。 /status/openai 从 Cloudflare 边缘每 5 分钟探测 OpenAI 的 API 入口。如果边缘探测正常而你本地失败，问题更可能在你这一侧。
4. 测本地到 API 的连接。 在 cdnping 首页测首次连接（含 DNS 与 TLS 握手）和往返。首次连接超时或远高于平时，说明本地网络、DNS 或代理有问题；连接正常但请求返回 5xx，则回到官方故障。

判断表：

更完整的检查可以看 ChatGPT 挂了吗？三步判断是服务故障还是自己的网络问题和开发者网络自检清单（2026 版）。

#429 slow_down 和 503 server_is_overloaded 是什么意思？

OpenAI API 更新日志在 9 月 2 日更新了错误说明，让应用能区分两种情况：

• 429，code 为 slow_down：流量增长过快。
• 503，code 为 server_is_overloaded：模型临时过载。

两类响应都可能带 Retry-After 头。有这个头，至少等它指定的时间再重试；没有，就用指数退避。

简单的客户端写法思路：

重试次数 n = 0
循环：
  请求失败且状态码为 429 或 503：
    若响应有 Retry-After：等待不少于该值
    否则：等待 min(上限, 基数 × 2^n) 再加一点随机抖动
    n += 1，超过最大次数则放弃并报错

不要在收到 503 后立刻并发重试，那只会加重过载。

#Codex 会自己处理重试吗？

ChatGPT 更新日志显示，Codex CLI 0.162.0（2026-10-08）的修复项包括“遵守服务端对可重试的 Responses 与 WebSocket 失败给出的 Retry-After 建议”。如果你的版本更旧，在故障期间升级到这个版本或更新版本，可以减少盲目重试；具体行为以该版本的官方说明为准。

另外，故障期间 Codex 报错不一定要立刻排查配置：先按上面的 1、2 步确认是不是官方问题，确认后等待恢复通常比改配置更省事。Codex 相关的容量报错可以参考10 月 Codex 频繁报错、“Selected model is at capacity”，状态页的读法见怎么看 OpenAI 状态页和 Claude 状态页。

#小结：下次遇到报错先做什么

先看状态页，再看 /down 与 /status 的探测，最后测本地连接。三步里任何一步给出明确结论就可以停下。如果你要长期监控自己的调用质量，可以参考 API 可用率测试怎么做。

#参考来源

• OpenAI 状态页历史记录
• OpenAI API 更新日志
• ChatGPT / Codex 更新日志