ChatGPT 7月23日故障复盘：不是全球全面宕机，但影响了哪些用户？

2026年7月23日，OpenAI旗下的ChatGPT、Codex及API出现服务异常。OpenAI官方将其描述为“错误率升高”（elevated error rates），因此更准确的说法是服务降级或部分故障，而不是已经证实的全球全面宕机：不少用户遇到问题，但现有证据并不能证明所有账户、订阅方案或地区都受到同样影响。3029

7月23日ChatGPT到底出了什么问题？

用户反映，ChatGPT请求无法发送、长时间卡住，或者历史对话无法加载。网页端和移动端体验均出现问题，Codex以及OpenAI API也被列入受影响服务。222932

“错误率升高”这一表述值得注意。它说明请求失败的比例高于正常水平，但并不等于所有用户都完全无法访问服务。30

科罗拉多大学信息技术部门发布的服务提醒也记录了同一事件。该提醒称，OpenAI正在与一家下游基础设施提供商合作，尝试恢复正常服务，并表示服务在7月23日较早时候已经恢复。不过，OpenAI自己的事故记录直到次日仍在持续监控恢复情况。2930

影响范围有多大？

与Downdetector相关的报道显示，7月23日下午3点前不久，用户报告数量超过300条，其中接近90%的投诉与ChatGPT有关。22

但这300多条报告不能直接等同于总宕机时长，也不能代表所有失败请求的数量。故障追踪网站统计的是主动提交报告的用户，结果可能受到用户知情程度、地理位置以及问题可见度影响。相比单纯查看报告数量，OpenAI官方使用的“错误率升高”更能反映此次事件的技术范围。2230

现有报道可以确认，ChatGPT及其他相关OpenAI服务都出现了用户影响，但无法确认每一位用户、每个订阅层级或每个地区都经历了同样的故障。因此，将其称为“部分故障”或“性能下降”，比说“ChatGPT完全宕机”更严谨。

OpenAI如何调查并修复故障？

根据OpenAI状态页，事件处理大致经历了标准的故障响应流程：

1. OpenAI开始调查受影响服务的问题；
2. 公司确认错误率升高，并着手实施缓解措施；
3. 缓解措施上线后，团队持续监控恢复情况；
4. 事件最终于7月24日（星期五）19:33 UTC标记为解决，受影响服务被称为已完全恢复。30

不同公开记录中的恢复时间并不完全一致。科罗拉多大学的通知称，ChatGPT、OpenAI API和Codex在7月23日下午3点36分已通过修复恢复服务；而OpenAI状态页则继续保留该事件，并延长了恢复监控时间。2930

这可能意味着不同服务或地区的恢复速度并不一致，也可能只是各方记录的时间点不同，或者OpenAI在多数用户恢复使用后仍选择继续观察。现有公开材料不足以确定其中哪一种解释是最终原因。

此外，OpenAI在可见的事故更新中没有公布详细技术根因。大学IT提醒中提到的“下游基础设施提供商”，是目前较明确的基础设施背景线索，但不能被当作完整的因果解释。29

与7月25日故障相比，有哪些区别？

7月23日的事件并非孤立事故，而是OpenAI一段连续不稳定时期的一部分。7月25日，ChatGPT、Codex和OpenAI API再次出现错误率升高。用户报告称对话无法访问、提示词卡住，并出现503错误；其中一个内部错误标签阻止请求抵达OpenAI服务器。《The Next Web》称，这已经是该公司四天内发生的第四次服务中断。7

另有报道将7月25日的事件描述为波及多个国家的更广泛全球故障，用户无法加载对话、访问保存的历史记录或运行提示词。315

两次事件的区别在于：7月23日更接近一次影响明显、但未必覆盖所有用户的服务降级；7月25日则出现了更广泛、更容易被用户感知的消费端和开发者服务故障报道。

与4月20日的故障相比如何？

4月20日的ChatGPT中断也获得了更多集中报道。Moneycontrol援引的数据称，Downdetector上相关报告超过1720条，问题包括网关错误、登录失败和无法加载对话；TechRadar则报道，OpenAI将其归类为至少持续90分钟的部分故障。1112

4月20日的报道还提到，用户无法访问项目，部分情况下正在进行的工作也受到影响。OpenAI大约在美国东部时间下午1点部署缓解措施，随后继续监控恢复情况。14

因此，更清晰的比较是：4月20日是一次规模更大、报道更集中的ChatGPT中断；7月下旬则在数天内连续出现涉及ChatGPT、Codex和API的多起事件。现有来源并没有证明这些故障具有相同的技术原因。

对企业和职场用户意味着什么？

普通用户最直接的症状是提示词发送失败、页面加载异常以及对话无法访问。对于企业团队，影响可能不止是ChatGPT网页打不开：使用OpenAI API或Codex的组织，可能面临自动化请求失败、任务延迟、开发流程中断，或依赖模型响应的系统出现积压。6

目前没有公开且可靠的数字能够量化这次故障造成的商业损失。不同组织的工作负载、依赖程度和备用方案各不相同，因此也没有足够证据支持具体的金额估算。

对于将OpenAI服务用于生产环境的团队，这次事件至少提出了几项可靠性问题：

• 请求失败时，系统是否采用带退避机制的重试，而不是造成重复执行？
• 应用能否区分“服务商临时出错”和“请求已经成功完成”？
• API降级时，排队任务是否可观测、可追踪？
• ChatGPT或Codex不可用时，用户能否切换到已经记录的备用方案？
• 多步骤或自主运行的工作流，能否安全失败，而不是执行到一半后悄然停止？6

尤其对于自动化代理或多步骤任务，团队还应检查故障期间的任务是否安全中止，是否出现“部分完成但没有明确恢复点”的情况。6

为什么预测市场也关注ChatGPT故障？

7月多次服务中断还引起了预测市场的注意。一些市场按照某个特定日期内，OpenAI是否将事件官方归类为“部分故障”或“全面故障”来结算；另一些市场则关注ChatGPT在7月可能出现多少个故障日。1820

这些市场可以反映公众对AI服务可靠性的关注度，但市场价格并不是判断故障原因、严重程度或未来发生概率的独立证据。它们反映的是交易行为以及具体合约的措辞，而不是经过验证的可靠性指标。

结论：真正值得关注的不是一次“宕机”数字

7月23日的ChatGPT事件确实是一次影响OpenAI服务的故障，涉及ChatGPT、Codex和API。但最有力的证据支持“错误率升高”和“服务性能下降”这类表述，而不是“全球完全宕机”。Downdetector相关报道记录了300多条用户报告；OpenAI状态页则显示，事件经历了调查、实施缓解措施和恢复监控，最终于7月24日19:33 UTC标记为解决。2230

这次事件更大的意义，在于它所处的连续故障背景：7月23日之后，7月25日又发生了另一场更严重的服务中断，而4月20日的事件已经显示，ChatGPT故障可能同时影响对话、项目和依赖API的工作流程。

对于在生产环境中使用AI的企业来说，关键并不是记住某一次故障的报告数量，而是提前建立可观测性、合理重试、安全失败机制和切实可用的备用方案。这样即使模型服务出现波动，业务也不至于“卡在半路”。