---
title: "Claude 故障多吗：2026 年 9–10 月官方状态页事件统计与应对"
description: "统计 2026-09-17 起 Anthropic 官方状态页的 Claude 故障事件数与等级，说明数据怎么读、哪些不能下结论，并给出判断是否真故障的命令和 API 重试、降级做法。"
url: https://cdnping.org/blog/claude-outage-history-2026
language: zh-CN
published: 2026-10-19
category: "服务动态"
tags: ["Claude","服务状态","故障统计","API 可用性","重试与降级"]
source: cdnping.org
license: Free to quote and summarize with a link to the url above.
---
# Claude 故障多吗：2026 年 9–10 月官方状态页事件统计与应对

按 cdnping 同步的 Anthropic 官方状态页记录，从 2026-09-17 到 2026-10-17 这一个月里，Claude 共有 8 起公开事件，其中 6 起被官方标为 major。这个数字说明 Claude 故障并不罕见，但也谈不上“天天挂”。对使用者来说，更要紧的是判断自己遇到的那一次到底是官方故障，还是自己的网络、额度或客户端出了问题。

下面先摆数据，讲清楚它能说明什么、不能说明什么，再给出遇到“Claude 用不了”时的检查步骤，以及写 API 调用时的重试和降级做法。

## 数据从哪里来，窗口是多长？

本文所有数字来自 cdnping 在 2026-10-17 生成的数据快照，分两部分：

- 官方状态页事件：cdnping 的 [API 状态页](/status/anthropic) 每 15 分钟同步一次 Anthropic 官方状态页，事件等级（critical / major / minor / none）直接沿用官方标注，cdnping 不做二次评级。本文统计窗口从 2026-09-17 开始，到快照生成时为止，约 30 天。
- cdnping 自己的边缘探测：从 Cloudflare 边缘每 5 分钟探测一次 `api.anthropic.com`。cdnping 从 2026-10-17 才开始采集，快照里的探测记录只覆盖约 85 分钟（全部 API 合计 242 次探测），只能当作“当时的样子”，不能当作长期统计。

口径细节见 [数据方法](/methodology)。数据以 CC BY 4.0 开放，接口是 `/api/status`。

## 2026 年 9–10 月，Claude 出了几次故障？

按事件等级拆开：

| 事件等级（官方标注） | 事件数 |
|---|---|
| major | 6 |
| minor | 1 |
| none | 1 |
| 合计 | 8 |

窗口：2026-09-17 至 2026-10-17，来源：Anthropic 官方状态页，经 cdnping 同步。

关于这组数字，有两点要说明。

第一，8 起里有 6 起是 major，比例很高。这不一定说明 Claude 的事故更严重，也可能与 Anthropic 的标注习惯有关：同样程度的降级，有的厂商标 minor，有的标 major。等级由各家自己定，只适合同一家跟自己的历史比较。

第二，快照里的“最近事件”列表覆盖 2026-10-09 到 2026-10-16，共 40 条，其中没有 Claude 的事件。也就是说，这 8 起都发生在 9 月 17 日到 10 月 9 日之间。快照里没有这 8 起的标题和持续时长明细，所以本文不逐条列出。要看事件原文，打开 [/status/anthropic](/status/anthropic) 的 30 天历史，或者直接去 [Anthropic 官方状态页](https://status.anthropic.com)。

## 和同期其他服务比，算多还是少？

同一窗口、同一口径（都来自各家官方状态页，经 cdnping 同步）下的事件数：

| 服务 | critical | major | minor | none | 合计 |
|---|---|---|---|---|---|
| Claude | 0 | 6 | 1 | 1 | 8 |
| OpenAI | 0 | 4 | 19 | 2 | 25 |
| Cloudflare | 0 | 3 | 19 | 3 | 25 |
| Cursor | 0 | 5 | 20 | 0 | 25 |
| GitHub | 5 | 1 | 10 | 0 | 16 |
| Kimi（Moonshot） | 8 | 0 | 0 | 0 | 8 |
| Groq | 0 | 1 | 2 | 0 | 3 |

这张表不能直接读成“谁更稳定”，原因有三个：

1. 发布门槛不同。有的厂商一个地区、一个次要功能出问题就会开事件，有的只在大面积影响时才发。事件多可能只是更透明。
2. 等级标准不同。Kimi 的 8 起全部是 critical，GitHub 也有 5 起 critical，Claude 一起都没有，这更多反映各家的标注方式，不是严重程度的真实排序。
3. 组件范围不同。一家的状态页可能同时覆盖网页端、API、编程工具和控制台，事件数自然会多。

等级和组件怎么读，可以看 [怎么看 OpenAI 状态页和 Claude 状态页](/blog/how-to-read-ai-status-pages)。同一时期 OpenAI 和 Claude 的完整盘点，见 [AI 服务故障盘点：2026年9–10月](/blog/ai-service-incidents-sep-oct-2026)。

## 快照那一刻，Claude API 的情况如何？

cdnping 在快照时（探测节点位于丹佛 DEN）对 `api.anthropic.com` 的结果：

| 指标 | 数值 |
|---|---|
| 当时是否可达 | 是 |
| 最近一次往返 | 77 ms |
| p50 | 73 ms |
| p95 | 84 ms |
| 窗口内成功率 | 100% |
| 官方状态页整体指示 | none（无进行中事件） |

这是 2026-10-17 约 85 分钟的探测，节点在美国，只说明那段时间从 Cloudflare 边缘到 Claude API 入口是通的、延迟稳定。它不代表你在国内本地的体验，也不代表模型推理本身没有排队或降级。

另一个侧面数据来自 OpenRouter 的公开 API。在 cdnping [模型监测](/models) 的同一快照里，Anthropic 一款主力模型在 OpenRouter 上列出的 8 个推理供应商（包括 Anthropic 官方、Amazon Bedrock、Google Vertex、Azure 等）近 30 分钟和近 1 天的可用率都是 100%。这说明当时托管在不同云上的同一模型都正常，也说明 Claude 有多条接入路径，后面讲降级时会用到。同一模型在不同供应商之间可用率的差异，见 [同一模型换个 OpenRouter 供应商，可用率能差多少](/blog/same-model-different-providers-uptime)。

## “Claude 用不了”时，怎么判断是不是官方故障？

很多“Claude 挂了”的体感，其实来自本地网络、代理出口、账号额度或客户端版本。下面按从外到内的顺序排查。

### 第一步：看官方和第三方状态

1. 打开 [Claude 挂了吗](/down/claude)。这个页面综合了官方状态页、每 5 分钟的 API 探测和用户一键报告。用编程工具的话，看 [/down/claude-code](/down/claude-code)。
2. 用命令行读官方状态页的整体指示（Statuspage 的标准接口）：

```bash
curl -sL https://status.anthropic.com/api/v2/status.json
```

返回里 `status.indicator` 为 `none` 表示官方没有进行中的事件；`minor`、`major`、`critical` 表示有。

3. 如果官方有事件，而且受影响的组件和你用的产品对得上，基本可以确定是官方问题，等恢复即可，不必改本地网络。

### 第二步：确认 API 入口是否可达

不带密钥请求一次 Messages 接口，只看能不能连上：

```bash
curl -sS -o /dev/null \
  -w 'code=%{http_code} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} total=%{time_total}\n' \
  https://api.anthropic.com/v1/messages
```

结果怎么读：

| 现象 | 大概率原因 |
|---|---|
| 返回 401 或 405，耗时正常 | 网络通，入口正常，问题在密钥、额度或客户端 |
| DNS 阶段失败或很慢 | 本地 DNS 或代理的 DNS 设置 |
| connect 超时 | 出口线路或代理不通 |
| TLS 阶段失败 | 中间设备干扰，或代理配置问题 |
| 返回 5xx | 入口侧异常，回到第一步核对官方状态 |

### 第三步：在浏览器里测一次

打开 cdnping [在线测速](/)，它会测到 Claude API 的“首次连接”（含 DNS 和 TLS 握手）和“往返”（连接复用后 3 次请求的中位数）。和其他 AI API 放在一起对比：只有 Claude 慢或失败，再查 Claude；所有境外 API 都慢，问题多半在你的出口。

### 第四步：检查出口和分流

如果用了代理，打开 [IP 与环境检测](/ip)，看多出口检测里 Claude 那一项走的是哪个出口、是否和其他服务一致，以及大陆分流检测的结果。出口不一致、IPv4 和 IPv6 走了不同线路，都会表现成时好时坏。Claude Code 用户可以按 [Claude Code 连接超时和报错怎么排查](/blog/claude-code-connection-troubleshooting) 里的四层清单逐项检查。

Claude 的服务有地区限制，请在服务条款和当地法规允许的范围内使用，本文不讨论绕过限制的方法。

## 写 API 调用时，怎么应对 Claude 故障？

官方故障无法避免，能做的是让自己的程序在故障时少丢请求、不卡死。

### 按错误类型区分要不要重试

| HTTP 状态 | Anthropic 的错误类型 | 要不要重试 |
|---|---|---|
| 400 / 401 / 403 / 404 | 请求、认证、权限、资源错误 | 不重试，修请求或配置 |
| 413 | 请求体过大 | 不重试，缩短输入 |
| 429 | rate_limit_error | 重试，优先遵守 `retry-after` 响应头 |
| 500 | api_error | 有限次重试 |
| 529 | overloaded_error | 重试，并考虑切到备用路径 |

错误类型以 [Anthropic 官方错误文档](https://docs.anthropic.com/en/api/errors) 为准。官方 SDK 自带重试，可以通过 `max_retries` 调整次数，不需要自己再包一层无限重试。

### 重试骨架示例

```python
import random, time
import anthropic

client = anthropic.Anthropic(max_retries=0, timeout=60)  # 关闭 SDK 自带重试，由下面的逻辑控制

RETRYABLE = {429, 500, 529}

def call_with_retry(**kwargs):
    for attempt in range(5):
        try:
            return client.messages.create(**kwargs)
        except anthropic.APIStatusError as e:
            if e.status_code not in RETRYABLE or attempt == 4:
                raise
            ra = e.response.headers.get("retry-after")
            delay = float(ra) if ra else min(30, 2 ** attempt) + random.random()
            time.sleep(delay)
        except anthropic.APIConnectionError:
            if attempt == 4:
                raise
            time.sleep(min(30, 2 ** attempt) + random.random())
```

几处设计：指数退避加随机抖动，避免大量客户端在同一秒一起重试；设上限，5 次之后交给上层处理；显式设置超时，不让一个卡住的请求占住进程。

### 降级：故障持续时切到哪里

重试只能应付几秒到几分钟的抖动。遇到持续时间较长的 major 事件（例如半小时以上），需要提前准备好备用路径：

1. 同一模型的其他托管方。前面 OpenRouter 的数据显示，同一个 Claude 模型同时托管在 Anthropic 官方、Amazon Bedrock、Google Vertex 等平台上。官方入口出问题时，云厂商托管的实例不一定受影响，反过来也一样。三种接入方式各自的取舍见 [官方 API、云厂商托管与聚合网关](/blog/official-api-vs-cloud-vs-gateway)。
2. 换模型降级。非关键任务（分类、格式化、摘要）可以临时切到其他厂商的模型，关键任务排队等恢复。
3. 聚合网关。例如 [AGI Plan](https://agiplan.dev)（AGI Plan 是 cdnping 的商业合作方）同时兼容 Anthropic 和 OpenAI 两种接口格式，改一个接口地址就能用同一份额度在多个能力组之间切换；它公开逐小时、逐能力组的请求成功和失败计数，cdnping 在 [/status/agiplan](/status/agiplan) 镜像展示。AGI Plan 明确说明自己不是官方授权渠道。选择任何第三方接入前，都应先读它的数据政策。

不管选哪条路，都要在平时测通，不要等故障发生时才第一次配置。

### 自己留一份可用率记录

官方状态页反映的是厂商认定的事件，不等于你的请求成功率。可以在自己的调用层记录每个请求的状态码和耗时，按小时汇总成功率，做法和口径见 [自己测 AI API 的可用率](/blog/measure-ai-api-uptime-yourself)。下次再讨论“Claude 最近是不是很不稳定”，就能拿自己的数据说话。

## 怎么持续跟踪 Claude 的状态？

- 平时：收藏 [/status/anthropic](/status/anthropic)，它保留 30 天历史，官方事件和 cdnping 自己的探测放在一起看。
- 出问题时：先看 [/down/claude](/down/claude)，再按上面四步排查。和 ChatGPT 的判断方法基本一致，也可以参考 [ChatGPT 挂了吗？三步判断](/blog/is-chatgpt-down-or-my-network)。
- 每周回顾：[稳定性周报](/reports) 每周一自动生成，可以订阅。

本文的局限：cdnping 的事件同步窗口只有一个月，自有探测不到两小时，所以只能回答“这一个月里官方公布了多少起事件”，回答不了“Claude 长期可用率是多少”。更长时间的数据会随周报逐步积累。