ChatGPT与Codex同时宕机

7月25日,OpenAI发生突发服务故障,ChatGPT与Codex同时受到影响。官方已实施缓解措施并监控恢复,但尚未宣布事件完全解决。
OpenAI两项核心产品同时出故障
OpenAI在7月25日突发服务故障,ChatGPT与Codex均出现无法正常使用、登录异常或请求失败等情况。大量用户集中提交故障报告,第三方监测平台的异常曲线也快速上升,说明这并非少数账号、单一地区或本地网络造成的偶发问题。
ChatGPT 是 OpenAI 面向个人与团队用户提供的通用对话式AI产品,覆盖网页端、移动端、文件分析、联网搜索和多模态交互等功能。Codex 是 OpenAI 面向软件开发任务推出的AI编程代理产品,能够读取代码仓库、修改文件、执行命令并完成相对完整的工程任务。
两项产品同时受到影响,比单独一次聊天页面报错更值得关注。ChatGPT承载的是高频交互流量,Codex承载的则是持续时间更长、需要调用执行环境和代码仓库的代理任务;二者工作负载并不完全相同,却在同一时间段出现故障,意味着问题可能触及共享的身份认证、任务调度、存储、网络入口或其他基础设施层。
截至7月25日本文发稿,OpenAI官方状态信息仍显示服务正在经历问题,并称已经应用缓解措施、正在监控恢复情况。这句话意味着故障已经进入恢复阶段,但不等于所有地区、所有账号和所有功能均已恢复正常,官方也尚未将事件标记为完全解决。

目前能确认什么
目前可以确认的是,ChatGPT与Codex均被纳入本次事件的影响范围。IT之家在7月25日报道称,大量网友反馈OpenAI服务器发生故障,ChatGPT、Codex等服务出现宕机;在其发稿时,故障仍未修复。
DownDetector 是一个通过用户主动报告和网络状态信号识别在线服务异常的第三方监测平台。该平台上的OpenAI故障报告在短时间内明显飙升,可以作为大范围用户无法正常使用服务的旁证,但它不能单独确定故障根因,也不能精确代表OpenAI全部用户的实际受影响比例。
官方状态页是判断事件进度更可靠的一手信息来源。OpenAI目前给出的核心表述是“已应用缓解措施并监控恢复”,而不是“事件已解决”;对于正在执行代码修改、长对话分析或文件处理的用户来说,此时仍应把服务视为不稳定状态。
| 观察对象 | 已知状态 | 用户可能遇到的现象 | 当前判断 | |---|---|---|---| | ChatGPT | 被官方状态信息列入受影响服务 | 无法登录、消息发送失败、内部服务器错误、历史会话暂时不可见、响应超时 | 正在恢复,尚不能视为完全正常 | | Codex | 与ChatGPT同时出现服务问题 | 任务无法创建、代理执行中断、仓库读取或命令运行失败、任务长期排队 | 对开发流程的破坏性高于普通聊天失败 | | OpenAI API | 官方状态页以聚合方式展示可用性 | 不同模型、区域、功能和客户层级的表现可能不同 | 不能仅凭ChatGPT故障推断全部API不可用 | | DownDetector报告 | 全球故障报告显著增加 | 用户集中反馈无法访问或使用 | 可证明异常具有广泛性,不能证明技术根因 |
“宕机”不一定意味着所有接口全部不可用
服务宕机是指在线产品的全部或部分关键功能无法达到正常可用状态,包括彻底无法访问、错误率升高、响应延迟异常和功能降级。对于大型云端AI平台,宕机通常不是简单的“服务器全部关机”,而可能是部分组件故障后,错误沿调用链向上扩散。
OpenAI状态页明确提示,其可用性指标是跨套餐、模型和错误类型汇总后的结果。不同订阅层级、不同模型以及不同API功能的实际可用性可能存在差异,因此“某个用户还能发送消息”和“平台没有宕机”并不矛盾,“ChatGPT打不开”和“所有开发者接口都已中断”也不能直接画等号。
聚合状态会掩盖局部差异,这是大型平台事故中经常出现的认知偏差。例如,身份认证服务异常可能导致新登录用户完全无法进入,但已经持有有效会话的用户仍能继续使用;任务调度系统拥堵可能令Codex新任务无法启动,却不一定立刻终止已经进入执行环境的任务;对话历史索引异常也可能让侧边栏暂时变空,但不代表数据已经被永久删除。
Reddit上已有用户反馈对话和部分信息突然消失,并在退出后遇到无法重新登录的问题。现阶段没有证据表明这些对话被永久删除,更合理的处置方式是等待身份认证、会话索引和前端服务恢复,而不是连续退出登录、反复刷新或重复提交同一项高成本任务。
ChatGPT和Codex同时出问题,严重性在哪里
Codex故障对开发者的影响并不只是“少了一个聊天机器人”。传统对话失败通常只会中断一次问答,而编程代理可能正在修改多个文件、运行测试、安装依赖、读取远程仓库或等待长时间任务完成,一次中断会让用户难以判断任务到底执行到了哪一步。
代理任务具有状态性,这是Codex比普通聊天更怕宕机的原因。状态性任务会在多个步骤之间保留上下文和执行结果,如果平台在写入状态、同步日志或返回最终结果之前发生故障,用户可能看到任务一直运行、突然失败,甚至出现代码已经改动但界面没有返回完整说明的情况。
ChatGPT与Codex同时受影响,也说明AI产品越来越像生产基础设施,而不是一个可以随时关闭的实验性网页。开发者会把Codex接入代码审查、缺陷修复和测试流程,内容团队会把ChatGPT用于资料整理,企业用户则可能依赖其处理内部文档;当多个工作流都押在同一家模型供应商上时,一次平台事故就会形成明显的单点故障。
这次事件最现实的提醒不是“OpenAI不稳定”,而是高频AI用户需要重新设计故障边界。任何云服务都会发生事故,真正有差别的是团队有没有保留原始输入、任务状态和可切换的替代流程。
现在还不能断言数据库或流量激增是根因
OpenAI尚未公布本次故障的根本原因,因此不能把事故直接归因于数据库过载、模型算力不足、网络攻击或某次产品更新。官方当前只确认已经采取缓解措施并监控恢复,后续是否发布事故复盘,还要等待事件彻底结束。
级联故障是指一个基础组件发生异常后,通过依赖关系触发更多组件过载或失效。OpenAI此前在介绍其PostgreSQL扩展架构时提到,会在应用层、连接池管理器、代理层和查询层实施多级速率限制,目标之一就是防止突发流量压垮数据库实例并触发级联故障。
这段技术背景可以解释OpenAI为什么重视限流,却不能用来证明7月25日事故就是数据库问题。ChatGPT背后还包含身份系统、对话存储、推理服务、文件系统、搜索能力、内容安全组件和支付订阅等多条链路;Codex又额外依赖任务编排、隔离执行环境、代码仓库连接和日志回传,任何共享组件都可能成为故障放大器。
OpenAI披露的相关架构文章已经讨论到支撑约8亿ChatGPT用户规模时的数据库扩展问题。用户规模越大,平台越难依靠简单扩容解决所有问题,因为高峰流量会同时冲击连接数、缓存命中率、队列长度和下游服务;当自动重试叠加在一起时,原本局部的错误还可能被放大成更严重的拥塞。
历史事故说明,恢复一次不代表事件已经结束
OpenAI过去的大规模事故曾出现恢复后再次中断的情况。2024年6月的一次ChatGPT事故中,官方先完成一轮修复,随后又发生影响全部ChatGPT相关服务的重大中断;第二轮事件从格林尼治标准时间14时15分持续至17时01分,共计2小时46分钟。
历史案例的意义在于,处于“监控恢复”阶段的服务仍可能出现错误率反弹。缓存需要重新预热、积压队列需要逐步消化、被限流的请求会再次进入系统,任何一个环节恢复得过快都可能重新制造压力。
本次事件暂时也不应与DDoS攻击画等号。OpenAI曾确认2023年的一次事故与DDoS攻击有关,但每次服务异常的原因并不相同;在官方发布根因分析之前,把历史原因直接套用到当前事件,只会制造噪声。
开发者现在应该怎么处理
开发者应暂停重复创建Codex任务,并先检查本地仓库、分支状态和远程提交记录。反复提交相同任务可能在服务恢复后形成多个并行执行实例,导致重复修改、分支冲突或额外的排队压力。
当前更稳妥的处理方式包括:
- 对正在进行的代码任务执行本地状态检查,确认哪些文件已经修改;
- 在重新运行Codex前先保存或提交可确认的改动,建立清晰回滚点;
- 不把代理界面的“任务失败”直接理解为“所有修改均未执行”;
- 暂停高成本、长耗时任务,等待官方将事件标记为完全解决;
- 保留原始提示词、需求文档和测试条件,避免任务恢复后无法重建上下文;
- 在生产流程中设置超时、人工确认和幂等机制,防止恢复后重复执行。
普通ChatGPT用户则不应在对话历史暂时不可见时立刻判断数据已经丢失。会话列表、搜索索引和实际数据存储可能属于不同系统,前端暂时无法加载历史记录,并不等于底层数据已经被删除。
企业团队还应该把本次事故视为一次业务连续性测试。关键知识不应只保存在单个ChatGPT会话中,重要代码改动也不应只存在于Codex任务环境;需求、输入文件、生成结果和审核记录都应该回写到企业自己的文档、工单与版本控制系统。
这次事故暴露的是AI工作流的单点依赖
OpenAI服务故障已经从“聊天暂时不可用”升级为“生产流程可能停摆”。当ChatGPT负责知识工作、Codex负责代码执行时,两项服务同时中断会覆盖从信息获取到实际交付的完整链路,这比单一模型响应变慢更难处理。
多模型备份只能解决一部分问题,因为模型替换不等于工作流替换。其他模型可以继续回答问题,却未必能够接手Codex已经读取的仓库上下文、执行环境和任务状态;真正有效的容灾方案,需要把任务输入、执行进度和最终产物保存在供应商之外。
OpenAI目前的处置速度仍算及时,至少已经公开确认故障、实施缓解并进入恢复监控阶段。不过,在官方宣布完全解决并给出更详细说明之前,开发者不应把短暂恢复视为稳定性已经回到正常水平。
截至7月25日发稿,本次事故最准确的结论仍是:ChatGPT与Codex发生了具有广泛影响的服务故障,OpenAI已经采取缓解措施,但事件尚未被正式宣布完全解决。至于根因、具体受影响范围和是否存在数据层面的异常,还需要等待官方后续更新或事故复盘。
参考来源
- IT之家:OpenAI突发服务器故障,ChatGPT、Codex出现宕机——报道7月25日用户集中反馈及DownDetector异常情况。
- Reddit用户讨论:ChatGPT疑似宕机及登录异常——用于观察用户侧出现的会话不可见和登录失败现象。


