ChatGPT 7月23日故障：哪些服務受影響？OpenAI如何處理？

2026年7月23日，OpenAI旗下的ChatGPT、Codex及API服務出現錯誤率升高。許多使用者遇到請求失敗、載入停滯或無法開啟對話等問題，但現有資料不足以證明所有帳戶、訂閱方案或地區都同時受影響。因此，將這次事件描述為「服務效能下降」或「部分中斷」，比稱作ChatGPT全球全面停擺更準確。3029

7月23日到底發生了什麼？

使用者回報ChatGPT無法正常送出請求、回應卡住，或無法載入既有對話；問題涉及網頁版及手機版體驗。OpenAI的Codex及API也被列為受影響服務。222932

OpenAI在事件紀錄中使用的措辭是**「錯誤率升高」**。這代表請求失敗的比例明顯高於正常水平，但不等於所有使用者都完全無法登入或使用服務。30

科羅拉多大學資訊科技部門追蹤同一事件時表示，OpenAI正與下游基礎設施供應商合作，嘗試恢復正常服務。該校通知稱服務在7月23日稍早恢復；不過，OpenAI自己的事件紀錄一直監察到翌日，顯示不同使用者或服務可能不是在同一時間完全恢復。2930

影響有多廣泛？

與Downdetector相關的報道顯示，7月23日下午接近3時前，使用者回報數超過300宗，其中近九成與ChatGPT有關。22

但這個數字不能直接等同於總停機時間或失敗請求總數。故障追蹤平台只統計主動提交報告的使用者，數量會受到地區、使用者對事件的認知，以及問題是否容易被察覺等因素影響。相比之下，OpenAI官方所說的「錯誤率升高」，更能反映事件的技術性質。2230

目前資料可以確認ChatGPT及相關OpenAI服務受到影響，但不能确认每位使用者、每個訂閱層級或所有地區都出現相同故障。這也是「部分中斷」比「ChatGPT完全停擺」更精確的原因。

OpenAI如何調查及修復？

OpenAI的狀態頁面按照一般事件處理流程更新進度：

1. 先調查ChatGPT、Codex及API的服務問題。
2. 確認錯誤率升高，並著手部署緩解措施。
3. 表示緩解措施已套用，同時監察服務恢復情況。
4. 最終在7月24日星期五協調世界時19時33分將事件標記為已解決，稱所有受影響服務已完全恢復。30

不同來源記載的恢復時間並不完全一致。科羅拉多大學的通知稱，ChatGPT、OpenAI API及Codex在7月23日下午3時36分已恢復；OpenAI的狀態頁面則持續保留事件，並在翌日完成更長時間的恢復監察。2930這可能反映服務逐步恢復、不同機構採用不同更新時間點，或OpenAI在大部分使用者恢復後仍選擇繼續觀察。現有公開資料不足以确定哪一種解釋才是唯一答案。

OpenAI在可取得的事件更新中，也沒有公布詳細技術根因。大學通知提到下游基礎設施供應商，是目前較清楚的基礎設施背景線索，但不能視為完整的因果解釋。29

與7月25日故障有何不同？

7月23日的事件並非孤立事故。7月25日，ChatGPT、Codex及OpenAI API再次出現錯誤率升高；使用者回報對話無法開啟、提示停滯及503錯誤，其中部分錯誤標籤更表示請求未能抵達OpenAI伺服器。《The Next Web》稱，這是OpenAI四天內第四次服務中斷。7

其他報道則將7月25日形容為更廣泛的全球故障，指多個國家的使用者無法載入對話、查看已儲存的聊天紀錄或執行提示。315

兩個日期的差異值得留意：7月23日是一次影響顯著、但未必波及所有人的服務效能下降；7月25日則出現更廣泛、更容易被使用者察覺的消費者及開發者服務故障。

與4月20日的事件相比呢？

4月20日的ChatGPT中斷有更多公開回報。Moneycontrol引用超過1,720宗Downdetector報告，涉及閘道錯誤、登入失敗及無法載入對話；TechRadar則報道，OpenAI將事件列為至少持續90分鐘的部分中斷。1112

當日也有報道指使用者無法存取Projects，甚至可能影響進行中的工作。OpenAI約在美國東部時間下午1時部署緩解措施，之後監察服務恢復。14

較清晰的比較是：4月20日是一次規模較大、回報集中且可見度高的ChatGPT故障；7月底則在數天內反覆出現涉及ChatGPT、Codex及API的事件。現有來源沒有證明這些故障具有相同技術根因。

對企業及工作團隊有何影響？

個人使用者面對的主要症狀包括提示送出失敗、頁面載入問題及對話無法存取。對企業團隊而言，影響可能不只停留在ChatGPT介面：使用API或Codex的組織，可能遇到自動化請求失敗、工作延遲、開發流程中斷，或依賴OpenAI回應的系統出現積壓。7月事件後的安全及平台建議，也促請團隊檢查API依賴系統是否出現無提示失敗、排隊工作或明顯錯誤，以及自主任務是否能安全停止。6

公開資料沒有量化這次事件造成的商業損失，也沒有可靠證據支持任何具體金額估算。實際影響會視乎企業的工作量、系統設計及是否具備備援能力而異。

對依賴OpenAI服務的團隊來說，這次事件帶出幾個實務問題：

• 失敗請求是否採用具退避機制的重試，而不是造成重複執行？
• 應用程式能否分辨暫時性的供應商錯誤與已完成的回應？
• API效能下降時，排隊工作是否仍然可被追蹤？
• ChatGPT或Codex無法使用時，使用者能否切換至已有文件記錄的備援方案？
• 多步驟或自主工作流程能否安全失敗，而不是在半途中無提示地停止？6

為何預測市場也關注故障？

7月多次服務中斷，也引起預測市場注意。一些市場按照特定日期是否出現OpenAI官方分類的「部分中斷」或「全面中斷」來結算；另一些市場則追蹤ChatGPT在7月可能出現多少個故障日。1820

這些市場可以反映公眾對AI服務可靠性的關注，但市場價格並不是故障原因、嚴重程度或未來機率的獨立證據。價格反映交易者行為，以及每份合約的具體定義，不能取代官方狀態紀錄或技術測量。

結論：重點不只是一次故障

7月23日的ChatGPT事件確實是一次影響ChatGPT、Codex及API的OpenAI服務中斷，但最有力的證據支持「錯誤率升高及效能下降」這一描述，而不是全球全面停擺。Downdetector相關報告超過300宗，記錄了使用者可見的影響；OpenAI則由調查、部署緩解措施、監察恢復，至7月24日協調世界時19時33分將事件標記為已解決。2230

更值得企業留意的是其周邊模式：7月23日後，7月25日又發生更大規模的中斷，而4月20日的事件早已顯示，ChatGPT故障可以延伸至對話、Projects及依賴API的工作。對把AI用於生產環境的團隊而言，真正的教訓不只是計算停機次數，而是預先建立可觀測性、重試機制、安全失效處理及切實可行的備援方案。