博客 / 服务动态

AI 服务故障盘点：2026年9–10月 OpenAI、Claude 故障统计

2026-10-17cdnping 编辑部约 6 分钟读完

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 状态页 每 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，更可能和它的标注习惯有关，不能据此得出它比别家更不稳定的结论。

#按厂商和等级统计

来源：各厂商官方状态页，经 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 条：

来源同上；样本 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 开发直接相关的部分。

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

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

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

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

#排查顺序

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

#响应码对照

#写进代码的应对做法

#1. 带退避的有限重试

只对可重试的错误重试，最多三四次，间隔指数增长并加随机抖动。下面是一个与具体 SDK 无关的 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（AGI Plan 是 cdnping 的商业合作方）。它同时兼容 OpenAI 和 Anthropic 两种接口格式，Claude Code、Codex 等工具只改一个接口地址，就能用同一份额度在多个能力组之间切换。网关本身也是一层依赖，它公开了逐小时、逐能力组的成功和失败计数，cdnping 在 /status/agiplan 镜像展示，接入前可以先看。AGI Plan 明确说明自己不是官方授权渠道；部分模型标注为“仅境外”，以其 模型页 为准，使用时请遵守各服务条款和当地法规。

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

#下一步可以做的事

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