部落格 / 排障指南

10 月 6 日 ChatGPT 掛了、Codex 和 API 報錯：4 步判斷是官方故障還是你的網路

2026-10-19cdnping 編輯部約 3 分鐘讀完

ChatGPT 掛了、Codex 報錯、API 返回錯誤，如果發生在 2026 年 10 月 6 日，多半是官方故障：OpenAI 狀態頁當天記錄了多起事故，其中一條的標題就是“Elevated errors across ChatGPT, Codex, and the API including the Agents API”。不過每次遇到報錯，都值得用幾分鐘把官方故障和自己的網路問題分開，下面是做法。

以下內容截至 2026 年 10 月，事件資訊來自 OpenAI 狀態頁歷史記錄，狀態頁時間未標註時區，這裡不換算。

#10 月 6 日發生了什麼？

狀態頁當天列出的事故不止一條，按標題歸納如下：

此外當天還有 Work 模式錯誤、Computer Use 異常等條目，這裡不展開；各條目的恢復狀態以狀態頁為準。之後幾天仍有相關記錄：10 月 7 日有 Codex 與 Work 模式效能下降，10 月 13 日和 14 日分別有 Codex、ChatGPT Work 的效能下降，10 月 15 日出現標題為“Widespread feature degradation”的事故。具體根因和時長以狀態頁事故詳情為準，本文不做推測。

#怎麼快速判斷是官方故障還是自己的網路？

按從外到內的順序查，每一步都能排除一類原因。

1. 看官方狀態頁。 開啟 status.openai.com，找當天的事故。有對應條目，基本可以確認是服務端問題。
2. 看多人報告和探測。 狀態頁有時會滯後。cdnping 的 /down/chatgpt 和 /down/codex 綜合官方狀態頁、每 5 分鐘的 API 探測和使用者一鍵報告，可以看到有沒有別人同時遇到問題。
3. 看邊緣探測。 /status/openai 從 Cloudflare 邊緣每 5 分鐘探測 OpenAI 的 API 入口。如果邊緣探測正常而你本地失敗，問題更可能在你這一側。
4. 測本地到 API 的連線。 在 cdnping 首頁測首次連線（含 DNS 與 TLS 握手）和往返。首次連線超時或遠高於平時，說明本地網路、DNS 或代理有問題；連線正常但請求返回 5xx，則回到官方故障。

判斷表：

更完整的檢查可以看 ChatGPT 掛了嗎？三步判斷是服務故障還是自己的網路問題和開發者網路自檢清單（2026 版）。

#429 slow_down 和 503 server_is_overloaded 是什麼意思？

OpenAI API 更新日誌在 9 月 2 日更新了錯誤說明，讓應用能區分兩種情況：

• 429，code 為 slow_down：流量增長過快。
• 503，code 為 server_is_overloaded：模型臨時過載。

兩類響應都可能帶 Retry-After 頭。有這個頭，至少等它指定的時間再重試；沒有，就用指數退避。

簡單的客戶端寫法思路：

重試次數 n = 0
迴圈：
  請求失敗且狀態碼為 429 或 503：
    若響應有 Retry-After：等待不少於該值
    否則：等待 min(上限, 基數 × 2^n) 再加一點隨機抖動
    n += 1，超過最大次數則放棄並報錯

不要在收到 503 後立刻併發重試，那隻會加重過載。

#Codex 會自己處理重試嗎？

ChatGPT 更新日誌顯示，Codex CLI 0.162.0（2026-10-08）的修復項包括“遵守服務端對可重試的 Responses 與 WebSocket 失敗給出的 Retry-After 建議”。如果你的版本更舊，在故障期間升級到這個版本或更新版本，可以減少盲目重試；具體行為以該版本的官方說明為準。

另外，故障期間 Codex 報錯不一定要立刻排查配置：先按上面的 1、2 步確認是不是官方問題，確認後等待恢復通常比改配置更省事。Codex 相關的容量報錯可以參考10 月 Codex 頻繁報錯、“Selected model is at capacity”，狀態頁的讀法見怎麼看 OpenAI 狀態頁和 Claude 狀態頁。

#小結：下次遇到報錯先做什麼

先看狀態頁，再看 /down 與 /status 的探測，最後測本地連線。三步裡任何一步給出明確結論就可以停下。如果你要長期監控自己的呼叫質量，可以參考 API 可用率測試怎麼做。

#參考來源

• OpenAI 狀態頁歷史記錄
• OpenAI API 更新日誌
• ChatGPT / Codex 更新日誌