部落格 / 服務動態

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），口徑見 資料方法。
• 檢查一遍自己的呼叫程式碼：有沒有超時、有沒有區分可重試錯誤、有沒有熔斷、有沒有一條備用路徑。四項裡缺哪項，先補哪項。