全球 AI 服務 9/3 接連故障｜Claude、ChatGPT、Codex、Grok、Cursor 相繼異常
Kyle 3,467 字 · 約 11 分鐘

2026 年 9 月 3 日，Claude、Grok、ChatGPT、Codex 與 Cursor 在數小時內接連發生服務異常。這不是只有單一聊天網站打不開：受影響範圍同時涵蓋模型請求、網頁與行動 App、程式開發 Agent、CLI、雲端自動化及程式碼審查。Gemini 同期也出現零星使用者回報，但沒有 Google 官方事故公告。

各事故的開始時間接近，恢復進度卻不相同。Claude 在 9 月 4 日 00:23 結案，OpenAI 於 00:55 宣告 ChatGPT 與 Codex 恢復，Cursor 的第一批相關事故於 01:07 全部結束，但 01:42 又出現 Grok 4.6 降級。xAI 狀態首頁目前顯示沒有進行中的事故，各個 Grok 入口也標示為 available，不過原本的事故頁仍停在調查階段。現有官方資料沒有證明這些平台出自同一個根本原因。

9/3 全球 AI 服務故障概況

Claude、ChatGPT、Gemini 與 Grok 是面向一般使用者與開發者的生成式 AI 服務；Codex 與 Cursor 則把模型接進程式開發、Agent 與雲端工作流程。本文所稱的「全球 AI 服務」是指跨國提供服務的平台，不代表官方已證實每個國家與地區同時中斷。9 月 3 日的正式事故分別由 Anthropic、OpenAI、xAI 與 Cursor 公告；Gemini 僅有零星回報，未獲官方確認。這些事件不能因為發生在同一天，就直接視為同一場全球基礎設施故障。

服務台灣時間受影響範圍截至 9/4 03:18來源
Claude20:37 Sonnet 5 事故；21:26 另發生多模型事故Sonnet 5；另一筆事故涵蓋 Mythos／Fable 5.1、Mythos／Fable 5、Opus 5、Opus 4.8、Opus 4.600:23 已解決，官方表示影響於 00:16 結束Sonnet 5、多模型
Grok21:30 起；Android 於 21:43 公告網頁、iOS、Android、X 內 Grok、外掛與部分 API狀態首頁顯示無進行中事故、各入口 available；原事故頁仍未標記 resolved目前狀態、Web、iOS、Android、X、外掛、API
Cursor21:41 起；01:42 另發生 Grok 4.6 降級Grok 模型、Automations、Cloud Agents、Grok Bot、Review Agents，另有 Anthropic 與 OpenAI 上游錯誤；新事故影響 CLI、Cloud Agents、IDE、Grok Bot第一批事故 01:07 全部解決；Grok 4.6 於 02:57 部署修正後進入 Monitoring整體、Anthropic、OpenAI、Grok 4.6
ChatGPT／Codex22:43 起ChatGPT 15 個元件、Codex 4 個元件00:55 已解決OpenAI
Gemini9/3 晚間出現零星回報部分使用者回報錯誤、回應失敗或速度異常Google 沒有發布對應事故，未獲官方確認Google 狀態記錄、使用者回報整理

表中的「已解決」只代表各公司把該筆事故標記為 resolved，不代表所有帳號、地區與功能會在同一秒恢復。狀態頁通常呈現整體指標，個別使用者仍可能短暫遇到快取、排隊中請求或工作階段重連問題。


Sponsored Links

Claude 接連發生兩次故障

Anthropic 第一份事故只點名 Sonnet 5。官方在台灣時間 20:37 開始調查，20:47 表示修正已上線，20:56 將事故標記為解決；影響入口包含 claude.ai、Claude API、Claude Code 與 Claude Cowork。

第二份多模型事故在 21:26 建立，距離 Sonnet 5 結案只有 30 分鐘。官方最初列出 Mythos 5.1、Fable 5.1 與 Opus 5，21:50 再補上 Mythos／Fable 5、Opus 4.8 與 Opus 4.6。23:25 時只剩 Opus 4.8 與 Opus 5 尚未回到基準錯誤率，00:06 部署修正，00:23 正式結案。

Claude 9 月 3 日兩場故障的台灣時間線，Sonnet 5 解決後相隔 30 分鐘，Opus、Fable 等模型接著發生異常，最終於 9 月 4 日 00:23 解決
Sonnet 5 結案半小時後，多個 Opus、Fable 與 Mythos 模型接著出現異常。

我當時正在使用 Opus 與 Fable，工作進行到一半時，請求突然開始回傳 500 與 529。打開 Claude Status 後，第一眼只看到 Sonnet 5 的事故已修復；沒多久官方又建立多模型事故報告，才列出 Opus、Fable 等受影響模型。這段第一手紀錄能說明事故的使用者端現象，但不能證明兩份事故存在因果關係。

ChatGPT 與 Codex 錯誤率升高

OpenAI 在台灣時間 22:43 開始調查 ChatGPT 與 Codex 錯誤率升高。官方事故頁把影響分成兩個產品群組：ChatGPT 有 15 個受影響元件，Codex 有 4 個，範圍不只是一款 GPT 模型，也不是只有 ChatGPT 網頁版。

23:17 的更新表示緩解措施已套用，事故進入觀察。OpenAI 最後在 9 月 4 日 00:55 宣布所有受影響服務已完全恢復。官方頁沒有公布技術根本原因，因此不能把這次錯誤直接歸因於特定模型、雲端區域或網路供應商。

這筆事故對一般對話與開發工作造成不同風險。ChatGPT 可能出現對話失敗、串流中斷或功能無法載入；Codex 則可能在讀取專案、執行工具或雲端任務進行中停止。即使兩者出現在同一份事故報告，也應分開判斷未完成工作是否已經寫入檔案或遠端環境。

Grok 網頁、App、X 與部分 API 同時異常

xAI 在台灣時間 21:30 對 Grok 網頁版、iOS、X 內的 Grok、Office／Workspace 外掛及 us-west-2 API 區域發布模型故障公告。Android 版在 21:43 另行建立事故，顯示問題橫跨多個使用入口。

各事故頁的公開說明相當簡短，只表示 Grok 正在發生問題，團隊正在恢復服務。xAI 狀態首頁截至 9 月 4 日 03:18 已顯示「No incidents declared」，網頁、iOS、Android、X 內 Grok、外掛及各 API 區域也標示為 available。

不過，9 月 3 日建立的 Grok 網頁、iOS、Android、X 內 Grok、外掛與 us-west-2 API 事故頁，仍只有 Investigating 更新，沒有補上 resolved 或影響結束時間。較準確的說法是目前服務頁面已顯示可用，但這批事故記錄尚未完整結案，無法從官方公告確認確切恢復時間。

Cursor 同時受到多起事故影響

Cursor 在 21:41 公告服務降級，受影響項目包含所有 Grok 模型、Automations、Cloud Agents、Grok Bot 與 Review Agents。23:33 時官方表示已找到原因並處理緩解措施，最後於 9 月 4 日 01:07 將整體事故標記為解決。

除此之外，Cursor 還分別建立兩份上游供應商事故。Anthropic 模型錯誤從 22:17 開始，影響 Fable 5.1、Fable 5、Opus 5、Opus 4.8 與 Opus 4.6，於 00:31 恢復；OpenAI 模型錯誤從 23:17 開始，可能造成 Agent 回合失敗，於 01:05 恢復。

第一批事故結束後，Cursor 在 01:42 又公告 Grok 4.6 服務降級，影響 CLI、Cloud Agents、IDE 與 Grok Bot。官方於 02:57 表示修正已部署並進入 Monitoring，截至 03:18 尚未正式標記為 resolved。

Cursor 的時間線顯示，使用多模型的開發工具不一定能靠切換供應商避開事故。工具本身的 Automations、Cloud Agents 或 Review Agents 可能正在降級，上游 Claude、Grok、OpenAI 模型也可能各自異常；兩層狀態都要確認。

Gemini 有零星回報，但沒有官方事故

Gemini 在同一晚也出現零星回報。Gulf News 依據 Downdetector 等使用者回報整理指出，部分地區有人遇到錯誤訊息、回應失敗或速度異常；這類資料能反映個別使用者當下的問題，但不能直接代表整體服務中斷。

Google 的 Gemini 官方事故記錄沒有列出 9 月 3 日對應事件，Google 也沒有發布與上述回報相符的事故公告。因此本文把 Gemini 和四家已公告的事故分開標示：它屬於未獲官方確認的零星使用者回報，不能寫成已證實的全球故障。

多起事故是否來自同一個原因

目前沒有官方證據能把四家事故串成同一個根本原因。Anthropic 表示已找到多模型錯誤的原因，未公開技術內容；OpenAI 只公布緩解與恢復進度；xAI 沒有提供技術說明；Cursor 的部分事故則明確標示為 Anthropic 或 OpenAI 上游問題。

社群也出現另一種兩階段推測：Anthropic 修復 Sonnet 5 的過程，可能牽動共用系統，讓 Opus、Fable 等模型接著故障；大量 Claude 使用者發現服務異常後，又可能在短時間內湧向 ChatGPT、Grok、Gemini 或 Cursor，造成負載轉移與雪崩效應。這個說法能解釋事故接連出現的表面順序，但目前只是使用者推測。Anthropic 沒有表示兩份事故存在因果關係，其他平台也沒有把故障原因歸結為 Claude 使用者湧入。

Axios 與部分媒體提到 Microsoft Azure 同時出現異常，將它列為可能因素。這只能視為依時間重疊與雲端供應關係提出的推測，不能改寫成「Azure 導致所有 AI 網站故障」。幾筆事故的開始時間、影響產品與恢復時間也不完全相同。

較準確的結論是：9 月 3 日晚間，多家全球 AI 服務分別公告異常，部分工具也受到上游模型供應商連帶影響。除非公司後續發布事故檢討報告，否則不能進一步斷言它們來自同一雲端、同一部署錯誤或同一場攻擊。

500、529 與服務狀態應如何判讀

錯誤碼Anthropic 定義處理方式
500 api_error系統內部發生未預期錯誤查狀態頁並以有限次數的指數退避（exponential backoff）重試
529 overloaded_errorAPI 暫時過載等待容量恢復，不要持續密集重送
429 rate_limit_error速率限制、用量級距（usage tier）每月支出上限，或 Claude Code 工作區支出上限檢查帳號與工作區限制，不要和 529 混為一談

Anthropic 建議對 500 使用指數退避，也就是每次失敗後逐步拉長等待時間；官方 SDK 對連線錯誤、速率限制與 5xx 暫時性失敗預設會自動重試兩次。若狀態頁已有事故，持續手動重送通常無法排除上游問題，還可能讓未完成請求更難追蹤。

AI 工作中斷時的應對方式

AI 服務故障時，不一定只能等待官方修復。先確認模型供應商與使用工具的事故範圍，再嘗試切換入口或退回舊模型，並保存尚未完成的工作；不同版本與入口的可用狀態可能不一致，仍要分別測試。

伺服器故障或負載過高時，可以考慮退回一個模型版本，舊模型可能仍可使用。故障期間，我在 Claude Desktop 把模型退回 Opus 4.8 後可以繼續使用；Claude Code 改用 Opus 4.8 仍然報錯，直到退回 Opus 4.7 才能繼續工作。這也顯示同一模型版本在不同入口的狀況可能不一致，個別請求成功不代表整體服務已經恢復。

  • 先查模型供應商與使用工具兩層狀態頁，例如同時確認 Anthropic 與 Cursor。
  • 伺服器故障或負載過高時，可以考慮先退回一個模型版本測試；若仍然報錯，就再確認更舊版本或其他入口是否可用。
  • 程式修改維持小批次提交，讓中斷後能從 Git 狀態確認已完成範圍。
  • 長任務把需求、決策與驗收條件放在專案文件，不只留在雲端對話。
  • API 整合保留請求識別碼，並限制自動重試次數，避免重試流量放大問題。
  • 切換備援模型前，先確認工具格式、權限、上下文與輸出差異是否相容。

9 月 3 日的事故顯示，備援不只是準備另一個模型名稱。同一晚可以同時出現供應商模型故障、開發工具自身功能降級，以及另一家上游服務異常。能降低損失的關鍵，是讓任務狀態可以保存、重建與人工接手。

常見問答

9 月 3 日的 AI 服務是否都已恢復？

Claude 與 OpenAI 的相關事故已在 9 月 4 日凌晨結案。xAI 狀態首頁目前顯示 Grok 各入口可用，但原事故頁仍未標記 resolved；Cursor 的第一批事故雖已結案，之後新增的 Grok 4.6 降級事故截至 03:18 仍在 Monitoring。Gemini 則沒有 9 月 3 日的官方事故可供判定。

Claude 修好 Sonnet 是否造成 Opus、Fable 故障？

目前不能這樣判定。兩份事故報告前後只隔 30 分鐘，但 Anthropic 沒有公布技術原因，也沒有表示第二場事故由第一場修正引起。

Claude 529 是否代表帳號用量已達上限？

不是。Anthropic 將 529 定義為服務暫時過載；組織速率限制、usage tier 每月支出上限或 Claude Code workspace 支出上限會使用 429。一般自行設定的 API spend limit 則可能回傳 400。

同時訂閱多家 AI 就不會中斷嗎？

不一定。這次多家服務在同一晚分別異常，Cursor 又同時受到自身功能與多個上游模型影響。備援還要包含本機保存、可恢復的任務狀態，以及人工接手流程。

參考來源

Post Views: 58
Tags:
Sponsored Links

發佈留言