ChatGPT、Claude 和 Grok 为何在 9 月 3 日接连故障？

9 月 3 日，多个主流 AI 服务在数小时内先后出现异常：OpenAI 的 ChatGPT 和 Codex、Anthropic 的 Claude 产品，以及 xAI 的 Grok 都有用户受到影响。这种时间上的重叠是真实存在的；但现有公开证据支持的结论要更谨慎：这是几起在同一天、时间交叠的独立事件，且各家公布的原因不同，并非已被证实的“整个 AI 互联网同时宕机”。334148

当天发生了什么？

由于厂商状态页和第三方报道采用的更新时间不同，精确时间线存在些许差异。不过，几个事件的窗口足以解释为何用户会感觉它们几乎同时失效。

• **Grok：**报道援引的 xAI 事件记录显示，故障从 13:30 UTC 开始，到 17:05 UTC 结束。xAI 此后将中断归因于其位于美国田纳西州孟菲斯的计算中心发生故障。48
• **Claude：**Anthropic 报告称，多款 Claude 模型的请求错误率升高，影响范围包括 Claude.ai、API、Claude Code 和 Claude Cowork。事件在约 3 小时后结束，并于 16:16 UTC 恢复。104148
• ChatGPT 与 Codex：OpenAI 表示，从太平洋时间 07:43 开始的一项内部路由错误，导致部分用户无法在不同平台使用 ChatGPT 和 Codex；约在太平洋时间 08:17，修复方案已部署，后续继续监控恢复情况。41

用户反馈包括无法登录、对话不可用、提示词发送失败，以及网页或应用访问异常。基于 Downdetector 的报道显示，当晚约 20 时（印度标准时间），ChatGPT 的问题报告超过 4.3 万起；Claude 的影响则同时波及普通用户产品和开发者工具。2339

各平台公布的原因分别是什么？

厂商披露的解释，是不应把这些事件直接认定为单一共同故障的关键。

**OpenAI：**公司发言人称，ChatGPT 和 Codex 的问题源于 OpenAI 基础设施内部的路由错误。41

**Anthropic：**其公开状态信息将 Claude 的问题描述为基础设施故障，并确认多个模型和服务出现较高错误率；但所提供的资料没有说明究竟是哪一个具体组件失效。3948

**xAI：**事后报道指出，xAI 将 Grok 的故障与孟菲斯计算中心的中断联系起来，并向受影响的计算合作伙伴致歉。48

这些解释并不能从逻辑上排除存在某种共同依赖，但同样没有建立共同根因。

是 Azure 或其他共享服务商导致的吗？

目前没有所提供的公开证据能够确认：Microsoft Azure、网络运营商、内容分发网络（CDN）、身份认证服务，或任何其他共同供应商，导致了 9 月 3 日所有这些故障。

当时的报道之所以提到 Azure，是因为它向相关公司提供云服务，因此值得关注；但“可能存在关联”不等于“已经证明是原因”。42 尤其当故障是通过用户上报而非同一份统一技术事件记录来观察时，多个系统独立出问题也可能表现为时间上的重叠。

因此，现阶段最准确的判断是：**共享基础设施导致故障的说法尚未获证实。**在厂商直接确认或发布技术复盘之前，不应将“Azure 某区域故障造成全部事件”视为既定事实。

Anthropic 据称可使用 Colossus 1，能解释 Claude 故障吗？

现有报道不足以确认 Anthropic 对 xAI／SpaceXAI 的 Colossus 1 设施拥有何种范围的使用权限，也无法确认 Claude 的生产服务链路在这次事件发生时是否依赖该设施。孟菲斯的故障影响了 Grok，并不能单独证明它导致了 Claude 的中断。48

做可靠性分析时，这一区分尤其重要：即使某项商业算力合作真实存在，也不能由此推断某个面向用户的服务在故障当时正运行于该算力之上。

9 月 7 日印度用户报告的 ChatGPT 问题，已知什么？

另一起发生在 9 月 7 日的报告称，部分 ChatGPT 用户主要遇到内容生成失败，也有人反映浏览器端和应用端出现问题。一篇报道记录到约 261 份用户报告，其中内容生成问题占投诉的大多数。19

但这些信息不足以证明当日出现了持续的印度全国性中断，也没有确认根本原因，更没有证明它与 9 月 3 日的事件有关。外部监测服务称，其在当天 03:07 UTC 的检测中可以正常访问 ChatGPT，未发现异常响应时间或错误码；这更符合局部、间歇性或地域分布不均的异常，而不是持续全国性宕机的情形。22

给企业的启示：多厂商不等于高韧性

9 月 3 日的事件说明，一旦 AI 服务成为客服、软件开发、研究、文档处理或智能体工作流的一环，服务中断会迅速传导到实际业务。订阅多个 AI 平台可以降低单一厂商失效的风险，却不保证业务连续性：不同平台仍可能依赖相近的云、网络、浏览器、身份认证或集成路径。

更具韧性的 AI 工作流应至少包含：

• **人工兜底与持久化队列：**让关键任务可恢复、可追踪，而不是在请求失败后直接丢失。
• **厂商级故障切换：**把适合的任务路由至另一家模型供应商，但也要接受关联性故障仍可能发生。
• **防御性 API 处理：**采用有上限的超时设置、退避重试、熔断器和幂等任务设计，避免短暂故障引发重复处理。
• **降级运行模式：**事先明确没有前沿大模型时哪些服务仍可继续，例如规则路由、缓存答案、延后交付或人工审核。
• **独立监控与事件留档：**除关注厂商状态页外，也应运行自身的合成监测，并保留能够说明哪家厂商、哪个模型及哪条集成链路失效的日志。

核心结论并不是每一次同时发生的故障背后都藏着同一个原因，而是企业应当为这种可能性预作准备，并在下一次中断到来前验证备用方案是否真的可用。