Blog / Service updates

Claude 故障多吗：2026 年 9–10 月官方状态页事件统计与应对

2026-10-19cdnping editors6 min read

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

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

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

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

• 官方状态页事件：cdnping 的 API 状态页 每 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 出了几次故障？

按事件等级拆开：

窗口：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 的 30 天历史，或者直接去 Anthropic 官方状态页.

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

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

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

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

等级和组件怎么读，可以看 怎么看 OpenAI 状态页和 Claude 状态页。同一时期 OpenAI 和 Claude 的完整盘点，见 AI 服务故障盘点：2026年9–10月.

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

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

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

另一个侧面数据来自 OpenRouter 的公开 API。在 cdnping Model monitor 的同一快照里，Anthropic 一款主力模型在 OpenRouter 上列出的 8 个推理供应商（包括 Anthropic 官方、Amazon Bedrock、Google Vertex、Azure 等）近 30 分钟和近 1 天的可用率都是 100%。这说明当时托管在不同云上的同一模型都正常，也说明 Claude 有多条接入路径，后面讲降级时会用到。同一模型在不同供应商之间可用率的差异，见 How Much Availability Varies When the Same Model Switches OpenRouter Providers.

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

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

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

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

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

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

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

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

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

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

结果怎么读：

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

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

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

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

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

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

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

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

错误类型以 Anthropic 官方错误文档 为准。官方 SDK 自带重试，可以通过 max_retries 调整次数，不需要自己再包一层无限重试。

#重试骨架示例

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、云厂商托管与聚合网关.
2. 换模型降级。非关键任务（分类、格式化、摘要）可以临时切到其他厂商的模型，关键任务排队等恢复。
3. 聚合网关。例如 AGI Plan（AGI Plan 是 cdnping 的商业合作方）同时兼容 Anthropic 和 OpenAI 两种接口格式，改一个接口地址就能用同一份额度在多个能力组之间切换；它公开逐小时、逐能力组的请求成功和失败计数，cdnping 在 /status/agiplan 镜像展示。AGI Plan 明确说明自己不是官方授权渠道。选择任何第三方接入前，都应先读它的数据政策。

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

#自己留一份可用率记录

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

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

• 平时：收藏 /status/anthropic，它保留 30 天历史，官方事件和 cdnping 自己的探测放在一起看。
• 出问题时：先看 /down/claude，再按上面四步排查。和 ChatGPT 的判断方法基本一致，也可以参考 ChatGPT 挂了吗？三步判断.
• 每周回顾：Stability report 每周一自动生成，可以订阅。

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