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 狀態頁 每 15 分鐘同步一次 Anthropic 官方狀態頁，事件等級（critical / major / minor / none）直接沿用官方標註，cdnping 不做二次評級。本文統計視窗從 2026-09-17 開始，到快照生成時為止，約 30 天。
- cdnping 自己的邊緣探測：從 Cloudflare 邊緣每 5 分鐘探測一次
api.anthropic.com。cdnping 從 2026-10-17 才開始採集，快照裡的探測記錄只覆蓋約 85 分鐘（全部 API 合計 242 次探測），只能當作“當時的樣子”，不能當作長期統計。
口徑細節見 資料方法。資料以 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 的 30 天曆史，或者直接去 Anthropic 官方狀態頁。
和同期其他服務比，算多還是少？
同一視窗、同一口徑（都來自各家官方狀態頁，經 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 |
這張表不能直接讀成“誰更穩定”，原因有三個：
- 釋出門檻不同。有的廠商一個地區、一個次要功能出問題就會開事件，有的只在大面積影響時才發。事件多可能只是更透明。
- 等級標準不同。Kimi 的 8 起全部是 critical，GitHub 也有 5 起 critical，Claude 一起都沒有，這更多反映各家的標註方式，不是嚴重程度的真實排序。
- 元件範圍不同。一家的狀態頁可能同時覆蓋網頁端、API、程式設計工具和控制檯，事件數自然會多。
等級和元件怎麼讀，可以看 怎麼看 OpenAI 狀態頁和 Claude 狀態頁。同一時期 OpenAI 和 Claude 的完整盤點，見 AI 服務故障盤點：2026年9–10月。
快照那一刻，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 模型監測 的同一快照裡，Anthropic 一款主力模型在 OpenRouter 上列出的 8 個推理供應商（包括 Anthropic 官方、Amazon Bedrock、Google Vertex、Azure 等）近 30 分鐘和近 1 天的可用率都是 100%。這說明當時託管在不同雲上的同一模型都正常，也說明 Claude 有多條接入路徑，後面講降級時會用到。同一模型在不同供應商之間可用率的差異，見 同一模型換個 OpenRouter 供應商，可用率能差多少。
“Claude 用不了”時，怎麼判斷是不是官方故障？
很多“Claude 掛了”的體感，其實來自本地網路、代理出口、賬號額度或客戶端版本。下面按從外到內的順序排查。
第一步：看官方和第三方狀態
- 開啟 Claude 掛了嗎。這個頁面綜合了官方狀態頁、每 5 分鐘的 API 探測和使用者一鍵報告。用程式設計工具的話，看 /down/claude-code。
- 用命令列讀官方狀態頁的整體指示（Statuspage 的標準介面）：
curl -sL https://status.anthropic.com/api/v2/status.json
返回裡 status.indicator 為 none 表示官方沒有進行中的事件；minor、major、critical 表示有。
- 如果官方有事件，而且受影響的元件和你用的產品對得上，基本可以確定是官方問題，等恢復即可，不必改本地網路。
第二步：確認 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
結果怎麼讀：
| 現象 | 大機率原因 |
|---|---|
| 返回 401 或 405，耗時正常 | 網路通，入口正常，問題在金鑰、額度或客戶端 |
| DNS 階段失敗或很慢 | 本地 DNS 或代理的 DNS 設定 |
| connect 超時 | 出口線路或代理不通 |
| TLS 階段失敗 | 中間裝置干擾，或代理配置問題 |
| 返回 5xx | 入口側異常，回到第一步核對官方狀態 |
第三步：在瀏覽器裡測一次
開啟 cdnping 線上測速，它會測到 Claude API 的“首次連線”（含 DNS 和 TLS 握手）和“往返”（連線複用後 3 次請求的中位數）。和其他 AI API 放在一起對比：只有 Claude 慢或失敗，再查 Claude；所有境外 API 都慢，問題多半在你的出口。
第四步：檢查出口和分流
如果用了代理，開啟 IP 與環境檢測，看多出口檢測裡 Claude 那一項走的是哪個出口、是否和其他服務一致，以及大陸分流檢測的結果。出口不一致、IPv4 和 IPv6 走了不同線路，都會表現成時好時壞。Claude Code 使用者可以按 Claude Code 連線超時和報錯怎麼排查 裡的四層清單逐項檢查。
Claude 的服務有地區限制，請在服務條款和當地法規允許的範圍內使用，本文不討論繞過限制的方法。
寫 API 呼叫時，怎麼應對 Claude 故障？
官方故障無法避免，能做的是讓自己的程式在故障時少丟請求、不卡死。
按錯誤型別區分要不要重試
| HTTP 狀態 | Anthropic 的錯誤型別 | 要不要重試 |
|---|---|---|
| 400 / 401 / 403 / 404 | 請求、認證、許可權、資源錯誤 | 不重試，修請求或配置 |
| 413 | 請求體過大 | 不重試，縮短輸入 |
| 429 | rate_limit_error | 重試，優先遵守 retry-after 響應頭 |
| 500 | api_error | 有限次重試 |
| 529 | overloaded_error | 重試，並考慮切到備用路徑 |
錯誤型別以 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 事件（例如半小時以上），需要提前準備好備用路徑：
- 同一模型的其他託管方。前面 OpenRouter 的資料顯示，同一個 Claude 模型同時託管在 Anthropic 官方、Amazon Bedrock、Google Vertex 等平臺上。官方入口出問題時，雲廠商託管的例項不一定受影響，反過來也一樣。三種接入方式各自的取捨見 官方 API、雲廠商託管與聚合閘道器。
- 換模型降級。非關鍵任務（分類、格式化、摘要）可以臨時切到其他廠商的模型，關鍵任務排隊等恢復。
- 聚合閘道器。例如 AGI Plan（AGI Plan 是 cdnping 的商業合作方）同時相容 Anthropic 和 OpenAI 兩種介面格式，改一個介面地址就能用同一份額度在多個能力組之間切換；它公開逐小時、逐能力組的請求成功和失敗計數，cdnping 在 /status/agiplan 映象展示。AGI Plan 明確說明自己不是官方授權渠道。選擇任何第三方接入前，都應先讀它的資料政策。
不管選哪條路，都要在平時測通，不要等故障發生時才第一次配置。
自己留一份可用率記錄
官方狀態頁反映的是廠商認定的事件，不等於你的請求成功率。可以在自己的呼叫層記錄每個請求的狀態碼和耗時，按小時彙總成功率，做法和口徑見 自己測 AI API 的可用率。下次再討論“Claude 最近是不是很不穩定”，就能拿自己的資料說話。
怎麼持續跟蹤 Claude 的狀態？
- 平時：收藏 /status/anthropic，它保留 30 天曆史，官方事件和 cdnping 自己的探測放在一起看。
- 出問題時：先看 /down/claude，再按上面四步排查。和 ChatGPT 的判斷方法基本一致，也可以參考 ChatGPT 掛了嗎？三步判斷。
- 每週回顧：穩定性週報 每週一自動生成，可以訂閱。
本文的侷限：cdnping 的事件同步視窗只有一個月，自有探測不到兩小時，所以只能回答“這一個月裡官方公佈了多少起事件”，回答不了“Claude 長期可用率是多少”。更長時間的資料會隨週報逐步積累。
