ChatGPT全球宕机，Codex也断了

ChatGPT正在经历一次影响范围广、产品链条长的全球性服务中断，登录、注册、聊天界面、历史对话和消息发送同时出现异常，OpenAI的代码平台Codex以及多个API接口也未能幸免。

此次故障始于美国东部时间8月19日晚间约8点，北美、欧洲以及其他地区的用户陆续报告服务不可用。对中国用户来说，主要感受可能是页面长时间加载、历史对话无法打开，或者在发送消息时收到请求失败、并发请求过多等提示。

截至北京时间8月20日发稿，OpenAI已经在官方状态页确认相关服务存在登录异常，并将事件标记为已经定位问题、仍在处理中。官方目前表示，工程团队正在推进修复方案落地，但尚未公开披露故障根因，也没有给出完整恢复的明确时间点。

这次到底哪里出了问题

这不是一次单独的聊天消息发送失败，而是覆盖账户、会话、历史数据和开发者工具的多层服务异常。

ChatGPT的登录和注册功能首先受到影响。部分用户无法登录已有账号，新用户也无法完成注册，这意味着问题可能不只发生在对话推理服务本身，而是已经波及身份认证、账户会话或相关基础服务。对于已经登录的用户，页面也未必能够正常使用，因为前端仍需要持续向后端请求账户信息、会话列表和权限状态。

历史对话无法加载是本次故障中最容易引发焦虑的症状。用户打开ChatGPT后，左侧边栏可能一直停留在加载动画，过去保存的聊天记录看起来像是突然消失，点击历史会话也无法进入。需要强调的是，历史对话无法显示不等于数据已经被删除，它更可能意味着负责读取会话索引或返回历史记录的服务暂时不可用。

消息发送失败则暴露了请求链路的另一层问题。受到影响的用户可能会看到并发请求过多、请求失败或页面无响应等提示，即使用户实际上只发送了一条消息。这类报错不一定代表单个用户真的发起了过量请求，也可能是后端服务拥塞、请求重试机制堆积，或者网关无法正确判断上游服务状态后的统一错误反馈。

从用户体验看，这次故障像是把ChatGPT拆成了几个同时失灵的环节：用户无法进入系统，已经进入系统的用户读不到历史记录，能够看到聊天窗口的用户又发不出消息。它影响的不是某个模型的回答质量，而是整个产品从登录到推理再到数据读取的完整链路。

Codex为什么也会跟着中断

Codex是OpenAI面向软件开发场景提供的AI编程代理和代码工作平台，它不仅负责生成代码，也可以参与代码理解、修改、测试和任务执行。

本次故障同时影响Codex，说明受影响的可能是OpenAI更底层的共享基础设施，而不是ChatGPT网页端的单一前端故障。ChatGPT、Codex和OpenAI API虽然面向不同用户，但它们在身份认证、请求调度、模型推理、任务队列、配额控制和账户权限等环节上，可能共享部分平台能力。

开发者对Codex故障的感受通常比普通聊天用户更直接。普通用户可能只是暂时无法问一个问题，而编程代理往往需要连续执行多个步骤：读取项目文件、规划修改、调用模型、运行命令、分析测试结果，再决定下一步动作。如果服务在任务执行中间发生中断，影响就不只是一次回答失败，还可能导致任务停滞、上下文丢失或需要重新开始。

这也是AI编程代理与传统聊天机器人的重要区别。聊天服务的故障通常表现为一条消息没有返回；代理服务的故障则可能打断一条持续数分钟甚至更久的自动化任务。对于正在进行代码审查、批量重构或持续集成流程的团队来说，平台不可用会直接转化为开发流水线的等待时间。

API异常意味着什么

OpenAI API是开发者通过程序调用模型和相关能力的服务接口，本次事件中该平台同样出现了大范围异常。

OpenAI状态页显示，最多有12个API接口出现运行异常。参考资料没有列出这12个接口的完整名称，因此不能据此判断是某一款模型、某一类推理接口，还是账户、文件、批处理和工具调用等外围能力受到影响。但可以确定的是，影响面已经超出ChatGPT消费端产品。

API故障的外溢效应通常更大。许多第三方应用不会直接展示OpenAI的错误，而是表现为AI功能失效、回复超时、任务队列积压或页面一直转圈。用户看到的可能是一个无法生成摘要的办公工具、一个停止回复的客服机器人，或者一个代码审查任务迟迟没有结果，但真正的故障源头可能位于上游模型服务。

对企业系统而言，API的稳定性不是附加指标，而是生产系统的一部分。一个应用如果把核心流程全部绑定在单一模型供应商上，那么供应商宕机时，应用自身即使服务器、数据库和前端都正常，也无法完成关键功能。

这次事件还提醒开发者区分两类问题：模型不可用和平台不可用。模型不可用可能只影响某一个模型或某一类请求，平台不可用则可能连身份验证、任务创建、配额检查和错误回调都受到影响。后者更难通过简单重试解决，因为重试请求本身可能进一步增加系统压力。

故障时间线：从异常到公开确认

本次故障大约在美国东部时间8月19日晚8点开始出现，最初由用户侧的登录失败、页面加载异常和历史对话不可见等现象暴露出来。

美国东部时间晚8点15分，也就是故障开始约14分钟后，OpenAI已经在状态页将相关事件标记为问题已定位、仍在处理中。这个时间点说明官方已经确认异常并完成了初步范围判断，但定位问题不等于服务已经恢复，通常还需要部署修复、观察错误率，并确认不同地区和不同产品线的请求是否重新稳定。

目前已知影响范围可以概括为以下几类：

• ChatGPT账号登录异常；
• ChatGPT新用户注册失败；
• 聊天界面无法正常加载；
• 历史对话记录无法读取；
• 消息发送失败或出现并发请求过多提示；
• Codex相关功能受到影响；
• OpenAI API最多12个接口出现运行异常。

截至发稿，OpenAI尚未公开说明根因，也没有确认是否涉及数据丢失、网络攻击、数据库故障或具体云基础设施问题。没有官方复盘之前，对原因进行确定性判断都不可靠。

历史记录消失，是真的丢数据吗

历史对话在页面上消失，通常首先说明读取链路异常，而不是底层数据已经永久丢失。

ChatGPT的历史记录一般需要经过身份认证、会话索引查询、权限校验和内容读取等多个步骤。只要其中一个环节失败，前端就可能显示空白列表、无限加载或暂时没有历史记录。对于用户而言，看到的是“聊天没了”；对于系统而言，可能只是没有成功返回会话列表。

但这并不意味着用户可以忽视数据备份。ChatGPT并不是严格意义上的版本控制系统，也不应该被当作唯一的代码仓库、研究数据库或企业文档存储。代码、配置、实验记录、客户资料和重要决策内容如果只保存在聊天历史中，本来就存在平台故障、账号权限变化、误删和导出不完整等风险。

更稳妥的做法是把ChatGPT当成工作流中的处理层，而不是唯一的数据层。代码应该进入Git仓库，研究资料应该进入可检索的文档系统，关键提示词和结构化结果应该保存到本地或企业自己的数据库。这样即使聊天服务暂时中断，用户也能在其他工具中继续工作，而不是从记忆中重建上下文。

对普通用户和开发者分别意味着什么

普通用户面对这次故障时，最重要的是确认问题是否来自平台，而不是反复修改密码或清空本地数据。

如果页面持续加载、多个设备同时无法登录，或者身边不同地区的用户都出现相同问题，优先查看OpenAI官方状态页和可靠的第三方故障监测信息。不要在故障期间反复刷新、连续提交登录请求或重复发送同一条消息，这些操作通常无法加快恢复，还可能造成重复任务或进一步触发风控。

已经打开的对话也不应被强制刷新或关闭。若当前页面仍能看到重要内容，可以先将关键文本复制到本地文件。对于正在运行的长任务，用户需要记录任务目标、已经完成的步骤和最后一次成功输出，待服务恢复后再判断是否需要重新执行。

开发者则需要检查自己的错误处理和降级策略。最基本的措施包括设置合理的连接超时、指数退避、最大重试次数和幂等机制，避免服务异常时所有客户端同时高频重试。

更成熟的系统还应该将模型调用与业务状态解耦。一次模型请求失败，不应让整个订单、工单或代码任务进入不可恢复状态。系统应该保存任务状态、输入内容和中间结果，并允许在服务恢复后继续执行。

对于关键业务，多模型或多供应商架构也值得重新评估。这里的重点不是简单地把一个模型名称替换成另一个模型，而是把不同模型的能力差异、上下文限制、工具调用方式、数据合规要求和成本纳入统一路由。只有这样，备用模型才是真正的故障转移能力，而不是宣传页面上的备选项。

这次宕机暴露了什么

这次事件最值得关注的不是ChatGPT短时间内能否恢复，而是AI服务已经成为越来越多工作流的基础设施。

过去，聊天机器人宕机更多意味着用户少问几个问题；现在，AI服务可能参与代码提交、客服响应、销售分析、合同审阅、数据清洗和内部知识检索。服务中断一旦发生，影响范围会沿着API、插件、SaaS产品和企业自动化流程继续扩散。

这也是AI平台与传统互联网产品的不同之处。一个社交应用短暂不可用，用户可能稍后再查看消息；但一个自动化Agent如果已经被授权修改代码、创建工单或执行多步骤任务，故障发生在不同阶段，后果并不相同。任务可能暂停，也可能因为超时、重试和状态不同步而产生重复操作。

此前公开报道中，OpenAI在2026年7月25日也曾出现ChatGPT、API和Codex同时异常的情况，相关报道提到当时有31个服务组件性能下降。7月事件与本次8月20日故障并非同一事故，官方也没有说明二者是否存在技术关联，但连续出现跨产品线故障，已经足以让稳定性成为用户评估AI平台时必须单独考察的指标。

模型能力可以通过跑分、基准测试和实际任务对比来衡量，可靠性则需要看错误率、可用性、恢复时间、故障通知和事后复盘。对企业来说，模型回答得有多聪明固然重要，但在关键时刻能否稳定返回、失败后能否恢复，往往更接近真实成本。

与单一供应商绑定的代价

单一供应商依赖是指一个系统的关键能力、账户体系和数据流全部集中在同一家服务商上，本次故障让这种依赖的风险变得可见。

单一供应商架构的优点很明确：接入更快、维护更简单、模型能力一致，团队也不需要同时适配多个平台。但它的缺点同样明确：一旦上游出现区域性或全局性故障，下游应用很难独立恢复。

对于个人开发者，这种风险可能只是几个小时无法使用；对于企业，影响可能包括客服积压、自动化流程暂停、研发任务延迟和客户投诉。真正需要计算的不是一次API调用的价格，而是AI服务中断一分钟对业务流程造成的机会成本。

因此，企业在采购AI服务时，应该把以下指标写进内部评估：服务等级协议、历史可用性、区域隔离能力、故障通知速度、数据导出能力、备用模型接入成本、限流策略和恢复后的任务一致性。没有这些指标，模型选型就容易变成只比较价格和榜单分数。

OpenAI接下来需要回答什么

OpenAI是否能够给出清晰的事故复盘，将决定用户如何理解这次故障的严重程度。

用户最关心的第一个问题是根因。是认证系统异常、共享数据库故障、流量突增、部署变更、云服务依赖，还是多个因素叠加，目前都没有公开答案。

第二个问题是数据完整性。历史对话暂时无法读取并不等于数据丢失，但OpenAI需要说明数据是否完整、是否出现写入失败，以及用户是否需要采取额外操作。

第三个问题是为什么ChatGPT、Codex和API会在同一时间受到影响。如果多个产品共享关键底层组件，平台需要说明隔离边界是否足够；如果它们本应相互隔离，则需要解释故障为何能够跨产品扩散。

第四个问题是修复后的验证方式。状态页显示服务恢复，并不代表所有地区、所有账户类型和所有接口都已经稳定。对开发者来说，真正重要的是错误率是否回到正常区间，长任务能否继续，历史会话能否完整读取，以及API请求是否仍然存在间歇性失败。

结语

ChatGPT此次全球大规模中断再次证明，AI产品正在从一个可以随时替换的效率工具，变成许多人工作流中的基础设施。

截至8月20日发稿，已知故障覆盖ChatGPT登录、注册、历史对话、消息发送、Codex和最多12个API接口，OpenAI已经确认问题并正在推进修复，但根因和完整恢复时间仍未公布。

对于用户来说，重要内容不要只放在聊天历史里；对于开发者来说，重试、状态保存和备用模型不应等到下一次宕机后才开始设计。AI平台的能力差距可能按几个百分点计算，但一次全局中断带来的可用性损失，往往是百分之百。

参考来源

• IT之家：ChatGPT突发全球大规模服务中断，OpenAI称正在修复：提供本次8月20日故障的起始时间、受影响功能、Codex异常以及OpenAI状态页信息。
• IT之家：国内科技媒体，持续跟踪ChatGPT、OpenAI及AI产业动态。

注：本文依据截至2026年8月20日发稿时可确认的公开信息撰写。OpenAI尚未公布完整事故复盘，关于底层故障原因的部分仅作风险分析，不代表官方结论。