26日凌晨 OpenAI Codex 崩了！Codex 服务全面中断，官方已恢复

核心信息：Codex 官方确认发生故障

2026 年 9 月 26 日清晨，部分 Codex 请求集中失败。OpenAI 官方状态页将本次事件标记为“Full outage”（全面故障），列出的受影响组件包括 Codex Web、Codex API、CLI 与 VS Code 扩展。官方表示受影响服务已于北京时间 07:54 恢复。

从一组中继服务的历史日志看，故障期间既出现明确的上游过载错误，也出现大量以 499 结束的 WebSocket 会话。这两类记录反映的环节不同：499 不等于已经逐条证实 OpenAI 返回了 499；它记录的是连接在响应完成前被关闭。理解这个区别，有助于避免把上游故障误读成用户主动取消。

官方时间线：北京时间 06:58 发布，07:54 宣布恢复

官方通告的关键节点

• 06:58：OpenAI 确认用户遭遇 Codex 服务中断，并称已定位内部问题。
• 07:03：确认受影响服务错误率升高，正在准备缓解措施。
• 07:19：官方表示此时通过 API key 登录可暂时恢复访问。这是当时的临时建议，不代表所有接入方式都适用，也不建议用户公开或共享密钥。
• 07:34：官方表示已识别根因，正在推进缓解。
• 07:45：实施缓解措施并观察恢复情况。
• 07:54：官方宣布受影响服务全部恢复。

这些是状态页公告时间，不是每位用户开始或结束报错的精确时间。个别用户可能在公告前遇到异常，恢复也可能因连接与重试状态而有差异。

日志里看到了什么：过载错误与 499 同时出现

明确的上游错误

在北京时间 07:44 的一次 Codex WebSocket 请求中，上游返回 service_unavailable_error，错误码为 server_is_overloaded，消息为“Our servers are currently overloaded. Please try again later.”，附带 NO_MORE_RETRY。中继服务将该轮请求记录为 502。这是一条有上游错误事件直接支持的例子，说明当时确实存在上游过载报错。

499 为什么不能按字面理解为“用户问题”

另一些请求先成功建立 WebSocket 连接、收到上游数据，却在最终完成事件到达前关闭，中继服务因此把相应轮次记为 499。在此次观测的一组日志中，06:00–07:00 有 119 条 WebSocket 轮次完成记录，其中 36 条为此类断连结算；07:00–08:00 有 44 条，其中 29 条为此类记录。这些数字是该服务的轮次样本，不代表 OpenAI 全平台请求量、受影响用户数或官方公布的事故规模。

集中发生、跨不同上游账号，并与官方 Codex 事故时间重叠，说明不能简单把这批失败归咎于用户误操作。不过，仅凭 499 本身，也无法断定每一条连接关闭前都收到了同一个过载错误；个别连接的完整事件顺序仍需要进一步核查。

遇到类似问题，建议怎么处理？

正在故障期间

先查看 OpenAI 状态页，保存未提交的工作，避免连续快速重试同一任务，尤其是具有外部写入或付费副作用的操作。不要仅因看到 499 就清除数据、重置账号或反复更换网络。确需切换接入方式时，应按官方指引核对权限并妥善保管 API key。

官方宣布恢复后

重新建立连接，先以一次小任务验证，再恢复正常使用。若仍失败，请记录发生时间、使用的 Codex 客户端与模型、错误文本和可提供给支持人员的请求标识；不要在公开反馈中粘贴密钥、Cookie 或完整业务请求正文。若有可能产生重复副作用，先检查原任务状态，不要盲目再次执行。

结论与来源

OpenAI 已确认这次 Codex 全面故障并宣布恢复；中继日志还独立记录了真实的上游过载事件。因此，把当时集中出现的错误仅解释成多个用户同时主动断线并不合理。与此同时，目前没有逐条证明所有 499 都由相同的上游过载帧直接触发。这篇回顾区分了官方事故、已确认的上游错误和仍待核实的逐请求归因，避免将它们混为同一结论。

官方来源：OpenAI Status — Issues with Codex（2026-09-26）。文中日志统计来自事故期间的中继服务历史记录，均使用北京时间（UTC+8）。