---
title: "10 月 6 日 ChatGPT 挂了、Codex 和 API 报错：4 步判断是官方故障还是你的网络"
description: "OpenAI 状态页记录 10 月 6 日 ChatGPT、Codex、API 同时出现错误率上升。本文还原事件，并给出 4 步排查法和 429、503 的退避做法，帮你分清官方故障与本地网络。"
url: https://cdnping.org/blog/openai-outage-2026-10-06-chatgpt-codex-api
language: zh-CN
published: 2026-10-19
category: "排障指南"
tags: ["ChatGPT","Codex","OpenAI API","故障排查","状态页"]
source: cdnping.org
license: Free to quote and summarize with a link to the url above.
---
# 10 月 6 日 ChatGPT 挂了、Codex 和 API 报错：4 步判断是官方故障还是你的网络

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

以下内容截至 2026 年 10 月，事件信息来自 [OpenAI 状态页历史记录](https://status.openai.com/history)，状态页时间未标注时区，这里不换算。

## 10 月 6 日发生了什么？

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

| 事故标题（概括） | 影响范围 |
|---|---|
| ChatGPT 对话错误率上升 | ChatGPT 对话 |
| Codex Cloud 错误率上升 | Codex Cloud |
| API 平台登录与管理接口错误率上升 | API Platform 登录、管理 |
| 多个产品错误率上升 | 对话、图像生成、Spaces 与 Pages、API rehydration、Dots |
| ChatGPT、Codex、API（含 Agents API）错误率上升 | 跨产品 |
| ChatGPT Go 对话错误率上升 | ChatGPT Go |
| Responses API 处理大 PDF 出错 | Responses API |

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

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

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

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

判断表：

| 现象 | 更可能的原因 |
|---|---|
| 状态页有事故，边缘探测也异常 | 官方故障 |
| 状态页无事故，探测正常，只有你失败 | 本地网络、代理或账号侧 |
| 连接超时、证书或 DNS 报错 | 本地网络 |
| 连接正常，返回 429 / 503 | 限流或模型过载，按下文退避 |

更完整的检查可以看 [ChatGPT 挂了吗？三步判断是服务故障还是自己的网络问题](/blog/is-chatgpt-down-or-my-network)和[开发者网络自检清单（2026 版）](/blog/developer-network-self-check-2026)。

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

[OpenAI API 更新日志](https://developers.openai.com/api/docs/changelog)在 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 更新日志](https://learn.chatgpt.com/docs/changelog)显示，Codex CLI 0.162.0（2026-10-08）的修复项包括“遵守服务端对可重试的 Responses 与 WebSocket 失败给出的 Retry-After 建议”。如果你的版本更旧，在故障期间升级到这个版本或更新版本，可以减少盲目重试；具体行为以该版本的官方说明为准。

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

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

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

## 参考来源

- [OpenAI 状态页历史记录](https://status.openai.com/history)
- [OpenAI API 更新日志](https://developers.openai.com/api/docs/changelog)
- [ChatGPT / Codex 更新日志](https://learn.chatgpt.com/docs/changelog)