---
title: "AI 服务故障盘点：2026年9–10月 OpenAI、Claude 故障统计"
description: "汇总 2026-09-17 至 10-17 七家官方状态页登记的 110 起事件，按厂商、影响等级和持续时间拆开统计，列出代表性事件原文标题，并给出重试、降级和多供应商切换的可执行做法。"
url: https://cdnping.org/blog/ai-service-incidents-sep-oct-2026
language: zh-CN
published: 2026-10-17
category: "服务动态"
tags: ["AI 服务故障","状态页","OpenAI","Claude","容灾","API 稳定性"]
source: cdnping.org
license: Free to quote and summarize with a link to the url above.
---
# AI 服务故障盘点：2026年9–10月 OpenAI、Claude 故障统计

AI 服务故障有多频繁？2026 年 9 月 17 日到 10 月 17 日，cdnping 同步的 7 个官方状态页一共登记了 110 起事件，其中 OpenAI 25 起，Anthropic（Claude）8 起，Claude 这 8 起里有 6 起被官方标为 major。10 月 9 日到 16 日的最近 40 条事件中，有 31 条时间字段完整，它们的持续时长中位数是 146 分钟，大约两个半小时。按这个频率，调用代码里的重试、超时和备用路径不是可选项。

## 数据从哪里来，口径是什么

- 来源：cdnping 的 [API 状态页](/status) 每 15 分钟同步一次 OpenAI、Anthropic、Moonshot、Groq、Cloudflare、GitHub、Cursor 的官方状态页。本文的数字取自 2026-10-17 生成的数据快照，事件标题、等级、开始时间和结束时间都是各家状态页上的原始字段。
- 窗口：厂商汇总的窗口是 2026-09-17 至 2026-10-17。逐条事件列表只包含最近 40 条，时间范围是 2026-10-09 22:37 至 10-16 17:56（UTC）。
- 限制：cdnping 从 2026-10-17 开始自己采集，此前的事件是从状态页历史里回填的。窗口只有一个月，不能当成长期稳定性排名。
- 等级不能横向比较：none / minor / major / critical 由各家自己标注，标准不同。比如 Moonshot 这期间的 8 起事件全部标为 critical，更可能和它的标注习惯有关，不能据此得出它比别家更不稳定的结论。

## 按厂商和等级统计

| 厂商 | 事件总数 | critical | major | minor | none |
|---|---|---|---|---|---|
| OpenAI | 25 | 0 | 4 | 19 | 2 |
| Cursor | 25 | 0 | 5 | 20 | 0 |
| Cloudflare | 25 | 0 | 3 | 19 | 3 |
| GitHub | 16 | 5 | 1 | 10 | 0 |
| Anthropic（Claude） | 8 | 0 | 6 | 1 | 1 |
| Moonshot（Kimi） | 8 | 8 | 0 | 0 | 0 |
| Groq | 3 | 0 | 1 | 2 | 0 |
| **合计** | **110** | **13** | **20** | **71** | **6** |

*来源：各厂商官方状态页，经 cdnping /status 同步；窗口 2026-09-17 至 2026-10-17。*

几点观察：

1. OpenAI 事件多，但以 minor 为主。25 起里 19 起是 minor。从最近几条的标题看，多是某个功能、产品线或接口降级。
2. Claude 事件少，但 major 占比高。8 起里 6 起是 major。事件数少不等于影响小，准备预案时不能只看次数。
3. 基础设施也会出问题。Cloudflare 和 GitHub 不是模型厂商，但很多 AI 应用的网关、Workers、CI 和代码托管都依赖它们。Cloudflare 这一个月有 25 起，从最近的事件标题看，大多是某个地区节点或单项产品的问题。
4. 开发工具会被上游连带影响。Cursor 最近的事件里，有一起标题直接写的是某家上游模型出错（Elevated errors affecting Grok models），说明 IDE 类工具的可用性同时取决于自身和它调用的模型厂商。

## 按持续时间统计

10 月 9 日至 16 日的 40 条事件里，有 7 条的结束时间早于开始时间（状态页回溯修改了开始时间，或者事件是事后补登的），另有 2 条时长记为 0 分钟（标注为 Retroactive 或没有填结束时间）。去掉这 9 条后，剩下 31 条：

| 持续时间 | 事件数 | 占比 |
|---|---|---|
| 30 分钟以内 | 4 | 13% |
| 30–60 分钟 | 6 | 19% |
| 1–3 小时 | 10 | 32% |
| 3–10 小时 | 7 | 23% |
| 10 小时以上 | 4 | 13% |

*来源同上；样本 31 条，窗口 2026-10-09 至 2026-10-16（UTC）。*

中位数是 146 分钟。超过 10 小时的 4 起，从标题看都是某个子系统或某个地区长时间降级，例如 Cloudflare 的 “Elevated Errors in China Network Colos” 持续约 7,515 分钟（约 5.2 天），OpenAI 的 “Delayed Costs data in the Compliance API” 持续约 2,504 分钟。这类长尾事件不一定让请求失败，但会让延迟变高、部分区域报错或数据延后，排查时容易被当成自己代码的问题。

对写重试逻辑的人来说，这组数字说明多数事件不会在几秒内恢复。重试只能扛住瞬时抖动，碰上持续一两个小时的降级，要靠熔断和切换。

## 代表性事件

以下标题按状态页原文引用，等级和时长取自状态页字段。只列与 AI 开发直接相关的部分。

| 时间（UTC） | 厂商 | 状态页标题（原文） | 等级 | 时长 |
|---|---|---|---|---|
| 10-15 16:29 | OpenAI | Widespread feature degradation | major | 146 分钟 |
| 10-14 07:05 | OpenAI | Degraded performance in Codex and ChatGPT Work | minor | 167 分钟 |
| 10-14 17:00 | OpenAI | Delayed Costs data in the Compliance API | minor | 2,504 分钟 |
| 10-15 07:10 | Cloudflare | Cloudflare Workers AI Issues | minor | 146 分钟 |
| 10-15 10:47 | Cloudflare | Increased HTTP 502 Errors | minor | 591 分钟 |
| 10-10 04:13 | Cloudflare | Elevated Errors in China Network Colos | minor | 7,515 分钟 |
| 10-15 22:25 | Cursor | Elevated errors affecting Grok models | minor | 415 分钟 |
| 10-13 00:22 | Cursor | Degraded performance and errors across Cursor services | minor | 165 分钟 |
| 10-12 18:17 | Groq | Model Performance or Availability Issue | major | 18 分钟 |
| 10-12 12:21 | GitHub | Incident with Actions, Pull Requests and Issues | minor | 474 分钟 |

*来源：OpenAI、Cloudflare、Cursor、Groq、GitHub 官方状态页，经 cdnping 同步。*

最近 40 条里没有 Anthropic 和 Moonshot 的事件，它们这一个月的事件都发生在 10 月 9 日之前。逐条记录可以在 [Anthropic 状态页面](/status/anthropic) 和 [Moonshot 状态页面](/status/moonshot) 查看 30 天历史，OpenAI 的在 [/status/openai](/status/openai)。

## 出问题时先判断是谁的问题

看到报错，先花两分钟判断问题出在哪一层，再决定是等、切，还是改自己的配置。

### 排查顺序

1. 打开 [挂了吗](/down)，例如 [/down/claude](/down/claude) 或 [/down/chatgpt](/down/chatgpt)。这里把官方状态页、每 5 分钟的 API 探测和其他用户的一键报告放在一起，能看出是不是“大家都挂了”。
2. 看 [API 状态](/status)。cdnping 从 Cloudflare 边缘每 5 分钟探测一次各家官方 API 入口。边缘探测正常、你这里不正常，问题多半在你的网络或配置上。
3. 测一下自己的链路。在 [在线测速](/) 页面看各家 API 的首次连接和往返时间；在 [IP 与环境检测](/ip) 里确认出口 IP、DNS 泄漏和分流状态有没有变化。需要发给同事或贴到工单里时，/ip 可以生成带水印的结果图，导出前可以选择隐藏 IP 地址。指纹在浏览器本地计算，不上传。
4. 对照响应码，见下表。

### 响应码对照

| 现象 | 常见原因 | 建议动作 |
|---|---|---|
| 429 | 限流或额度用尽 | 限流时读 `Retry-After` 按退避重试；额度用尽重试无效，要检查账户 |
| 500 / 502 / 503 | 服务端或网关故障 | 有限次数重试，超过阈值后切备用 |
| 529（Anthropic 接口） | 服务过载 | 同上，适合尽快切换 |
| 连接超时、TLS 握手失败 | 网络链路或 DNS | 先排查本地网络，不要急着换供应商 |
| 401 / 403 | 密钥、权限或地区限制 | 不要重试；检查密钥和账户状态，遵守服务条款 |
| 200 但输出质量异常 | 模型侧变更或降级 | 查 [官网动态](/changes) 和 [模型监测](/models) |

## 写进代码的应对做法

### 1. 带退避的有限重试

只对可重试的错误重试，最多三四次，间隔指数增长并加随机抖动。下面是一个与具体 SDK 无关的 Python 写法：

```python
import random, time
import httpx

RETRYABLE = {408, 429, 500, 502, 503, 504, 529}

def call_with_retry(send, max_attempts=4, base=1.0, cap=20.0):
    for attempt in range(1, max_attempts + 1):
        try:
            resp = send()
        except (httpx.ConnectError, httpx.ReadTimeout):
            resp = None
        if resp is not None and resp.status_code < 400:
            return resp
        if resp is not None and resp.status_code not in RETRYABLE:
            resp.raise_for_status()          # 401/403/400 等直接失败
        if attempt == max_attempts:
            raise RuntimeError("retries exhausted")
        wait = min(cap, base * 2 ** (attempt - 1))
        ra = resp.headers.get("retry-after") if resp is not None else None
        if ra and ra.isdigit():              # 只处理秒数格式
            wait = max(wait, float(ra))
        time.sleep(wait * random.uniform(0.5, 1.0))
```

### 2. 熔断：别让重试拖垮自己

上面统计的中位时长是 146 分钟。持续降级时，每个请求都重试 4 次，只会让排队和超时更严重。一个简单的熔断规则：

- 最近 60 秒内某个供应商的失败率超过 50%，且请求数不少于 20，就把它标为“打开”，5 分钟内不再发请求；
- 5 分钟后放 1–2 个探测请求，成功再恢复。

这些阈值是示例，按自己的流量调整。

### 3. 降级而不是报错

不是每个功能都需要最强的模型。可以提前规定降级顺序，例如：

- 主模型不可用时，切到同一家的轻量模型；
- 整家不可用时，切到另一家；
- 都不可用时，返回缓存结果或明确提示“稍后重试”，并把任务放进队列。

### 4. 多供应商

这一个月里，7 家没有一家是零事件。只接一家，就要承担它的全部故障时间；接两家以上，至少在一家出事时还有路可走。实现上有两种方式：

- 自己维护：同时接入两家以上的 API，各自管理密钥、计费和接口格式差异，熔断逻辑按供应商分别计算。
- 通过聚合网关：例如 [AGI Plan](https://agiplan.dev)（AGI Plan 是 cdnping 的商业合作方）。它同时兼容 OpenAI 和 Anthropic 两种接口格式，Claude Code、Codex 等工具只改一个接口地址，就能用同一份额度在多个能力组之间切换。网关本身也是一层依赖，它公开了逐小时、逐能力组的成功和失败计数，cdnping 在 [/status/agiplan](/status/agiplan) 镜像展示，接入前可以先看。AGI Plan 明确说明自己不是官方授权渠道；部分模型标注为“仅境外”，以其 [模型页](https://agiplan.dev/models) 为准，使用时请遵守各服务条款和当地法规。

无论选哪种方式，都建议在测试环境里手动把主供应商的地址改成一个不可达的地址，确认切换路径真的能走通。

## 下一步可以做的事

- 把 [/status](/status) 或具体厂商页加进书签，出问题时第一时间看。
- 订阅 [稳定性周报](/reports)，每周一自动生成，可以看到上一周各家事件和探测数据的变化。
- 需要自己做统计的，可以直接用 cdnping 的开放数据接口 `/api/status`（CC BY 4.0），口径见 [数据方法](/methodology)。
- 检查一遍自己的调用代码：有没有超时、有没有区分可重试错误、有没有熔断、有没有一条备用路径。四项里缺哪项，先补哪项。