ChatGPT、Claude、Grok 为什么同时宕机？AI 服务大规模故障背后的技术原因

2026 年 9 月 3 日上午（美国东部时间），ChatGPT、Claude 和 Grok 在同一段窗口里先后不可用。Grok 大约 9:30 起在 Web、iOS、Android 和 X 上返回「This model is overloaded」；Anthropic 报基础设施问题，Claude 聊天、Claude Code 和 API 一起受影响，大约 12:15 恢复；OpenAI 状态页写 elevated errors across ChatGPT and Codex，大约 11:00 起登录、上传、语音、搜索、Deep Research、生图都受影响，大约 12:55 标记缓解。三家都是面向大众的前端模型，重叠停机在这个行业里几乎没见过。The Verge 写得很克制：目前不清楚三家出了什么问题，也不清楚是否相关。这篇不把「Azure 背锅」写成已证实的根因，而是把官方时间线、共享云线索和级联流量拆开，并接到你能改的地方：错误 JSON、多供应商兜底，以及云端模型集体掉线时本地工具为什么还在。延伸阅读：AI 生成 JSON 错误指南、A2A vs MCP。

9 月 3 日时间线：三家各自报了什么

先按各家自己的状态页和公开口径对齐，不要先发明一条「共同事故」。xAI 一侧最早：大约东部时间 9:30，Grok 在 Android、iOS 和 Web 同时出问题，X 上的对话直接回「模型过载，请稍后或换一个模型」。事后 xAI 把这次故障连到孟菲斯数据中心停电/中断，而不是一句含糊的「我们正在排查」。这条很重要——它说明至少有一家给出了机房级解释，不能被后来的 Azure 叙事一口吞掉。

Anthropic 报的是基础设施问题导致的部分中断：面向用户的 Claude、面向开发者的 Claude Code，以及对外 API，几乎同一时段升高错误。公开时间线里，他们大约 15 分钟后声称已定位原因，中午 12:15 左右宣布恢复；随后又短暂出现过单个模型的 elevated errors。OpenAI 更晚一点：大约 10:43–11:00，状态页写 ChatGPT 与 Codex 错误率升高、性能下降。影响面不只是聊天窗口，登录、文件上传、语音、搜索、Deep Research、图像生成都被点名。当时 OpenAI 还在预热新模型 Astra，流量本身就不低。缓解措施上线后，大约 12:55 标记恢复。

同一上午，Cursor 等依赖 Claude / Grok 的编程代理也报了故障——这不是第四家大模型自己挂了，而是下游把三家当运行时。Google 的 Gemini 出现过用户投诉尖峰，但没有官方确认宕机；Ars Technica 把四家叠在一起写，是因为投诉曲线叠了，不是因为 Google 发了事故通报。读时间线时记住：重叠不等于同一根因，投诉尖峰也不等于官方确认。

先分清：官方事实、基础设施线索、不能当根因的猜测

把证据分成三层，后面才好谈「为什么同时」。第一层是官方事实：三家都确认了各自窗口内的故障；Grok 连到 Memphis 机房；Claude 说 infrastructure issue；ChatGPT / Codex 说 elevated errors。到这篇写作为止，三家没有联合根因分析，也没有互相点名。The Verge 的更新只确认服务已恢复，并写明尚未收到统一解释。

第二层是基础设施线索。多家媒体和监控聚合站提到，Microsoft Azure 在相近时段也出现用户投诉尖峰；有报告写 Azure East US 在太平洋时间约 10:26（东部约 13:26）出现 ingress 失败。East US 是大量企业 AI 流量的主区域，OpenAI、Anthropic、xAI 都在 Azure 上跑过可观的推理和网络。入口层（ingress）、负载均衡、区域路由一旦抖动，应用再不同，对外表现也会一起变成 502、超时、登录失败。这能解释「为什么看起来像一起挂」，但它仍然是线索，不是三家签字的 RCA。

第三层是不能写进架构决策的猜测：有人写成「Azure 故意掐断竞品」，有人写成「三家约好一起维护」，有人把 Memphis 和 East US 强行并成一次事故。公开材料不支持这些读法。更稳的工程结论只有两句。其一，大众 AI 产品的命运已经绑在少数云区域和少数入口设备上。其二，第一家倒下之后，用户切换和客户端重试会把压力立刻推到下一家——即使下一家自己的机房是好的。

共享云与入口层：为什么会「看起来像一起挂」

2026 年的前端模型看起来是三家公司、三套产品、三套 Tokenizer，底层却经常共享同一类东西：云账号、区域、GPU 配额、全球任播入口、身份和计量控制面。训练可以各建机房，推理要靠近用户、要弹性、要过企业采购，于是 Microsoft Azure 成了最常见的公约数。Gemini 当天基本没挂，最干净的解释不是「Google 模型更稳」，而是它的主路径走 Google Cloud，不跟另外三家抢同一条 East US 入口。

层	坏了会看见什么	会不会三家一起中招
模型权重 / GPU 集群	某个模型过载、某个快照 500	通常不会；除非真的共用同一机房
区域网络 / ingress	登录失败、全站超时、API 与网页一起挂	会；共享区域时这是最像「同时」的一层
身份 / 配额控制面	能连上但发不出请求，Token 刷新失败	会；控制面常比数据面更集中
客户端重试 + 用户切换	第二、第三家突然被打满	会；即使根因互不相干也会叠在一起

所以「同时宕机」在系统里常常是入口和控制面的语言，不是「三家的 Transformer 同时算崩了」。ChatGPT 连 Codex、上传、语音、Deep Research 一起报错，更像共用网关或身份层出了问题，而不是某一颗聊天模型抽风。Claude 把聊天、Claude Code 和 API 绑在同一次 infrastructure issue 里，也是同一类信号：对外产品名很多，对内可能就几条入口。你不需要等官方 RCA 才能改设计——只要假设「入口层会按区域同时失败」就够了。

级联、重试风暴与 Memphis

共享云解释「为什么会叠」，级联解释「为什么第二、第三家会更惨」。ChatGPT 一不可用，默认下一步不是等待，而是打开 Claude 或 Grok。上千万会话在几分钟里换供应商，等于给本来可能已经受损的共享入口再加一波突发。客户端和 Agent 框架更糟：超时后立刻重试、换 key、换模型，没有 jitter，也没有「这次是基础设施，不要再打了」的信号。这就是经典的重试风暴。第一家的故障，会在第二家的日志里变成「无缘无故的过载」。

Grok 的 Memphis 说明必须单独留着。xAI 公开把故障连到自己的数据中心，时间上还早于 ChatGPT 的状态页。它可能是独立事故，刚好和另外两家叠在同一上午；也可能和更广的网络/电力/云连接有关。在没有三家联合时间线之前，正确写法是并列，而不是合并。工程含义反而更清楚：你的兜底名单里如果只写「OpenAI 挂了就切 xAI」，当天早上这条策略会先死在 Grok 上。

Cursor 当天的故障是级联的产品形态。编辑器并不训练模型，它把 Claude 和 Grok 当运行时；上游一抖，补全、Agent 和工具调用一起停。2026 年大量内部 Agent 都长这样：MCP 工具、A2A 任务、自家 HTTP JSON，最后仍要打到两三家云端模型。单点不在你的业务代码，而在你默认的那一个 model 字段。相关背景见 MCP 与 JSON Schema 和无状态 MCP。

控制面比模型本身更脆

GPU 集群健康，并不能让用户发出去的请求成功。登录、上传、语音、搜索同时失败，说明坏的是网关、身份、对象存储入口或共享边缘，而不是某一层 decoder。页面上的「模型过载」经常是假症状：真正过载的是入口连接数、证书校验或令牌服务。状态页本身也会滞后——用户先在 DownDetector 上看到尖峰，官方文案后到。排障时不要只盯模型名，先看错误信封里的 httpStatus、code 和是否 retryable。

把厂商返回的散装错误收成同一份信封，比在 UI 上写「AI 出错了」有用得多。下面这份 JSON 只描述：哪家、什么状态、能不能重试。业务层不要去解析各家原文；原文进日志，信封进熔断。

{
  "ok": false,
  "provider": "openai",
  "httpStatus": 503,
  "code": "elevated_errors",
  "retryable": true,
  "occurredAt": "2026-09-03T15:00:00Z",
  "message": "ChatGPT and Codex are returning elevated errors"
}

同一上午你可能会同时收到 OpenAI 的 elevated errors、Anthropic 的 infrastructure issue、xAI 的 overloaded。字段名不同，决策应当相同：可重试的进熔断冷却，不可重试的换供应商，信封对不上 Schema 的当硬失败，不要用正则从 HTML 错误页里抠。把真实失败样本丢进 JSONVue：格式化看字段，校验看语法，JSON Schema 卡必填键，Diff 对比三家信封少了什么。云端集体掉线时，本地解析仍然能做——这正是浏览器内工具的价值。

对 Agent / JSON 管道：多供应商不是口号

「多云」如果只写在 PPT 上，当天早上帮不了你。有效的多供应商是运行时策略：主路径、明确的 fallback 顺序、熔断阈值、以及一份所有供应商都必须填的错误信封。不要在失败时对同一家连打二十次；不要把 fallback 写成「随机挑一个还活着的」。Google 当天能用，是因为它不在同一条入口命运里——这正好说明兜底名单里应当有一家主路径不同的供应商，而不是三家都挂在 Azure East US。

策略本身就该是 JSON，并且和业务 Schema 分开版本。下面这份配置不关心模型商标，只关心：先打谁、失败后打谁、错误率到多少切断、信封里哪些键是硬门闩。

{
  "policy": "failover",
  "primary": "openai",
  "fallbacks": ["anthropic", "xai", "google"],
  "circuitBreaker": {
    "errorThreshold": 0.3,
    "windowSeconds": 60,
    "cooldownSeconds": 120
  },
  "errorEnvelope": {
    "required": ["ok", "provider", "code", "retryable"]
  }
}

还有一条容易漏：工具参数 JSON 和最终答复 JSON 不是同一跳。MCP tools/call、OpenAI function arguments、你自己的 HTTP body，在模型挂掉时会以不同形状失败。把「模型不可用」和「参数不合 Schema」收成同一种 toast，后面的复盘会改错旋钮。本地校验仍然要做，理由和 Structured Output 那篇相同：形状层和可用性层不是一回事。云恢复之后，把当天的失败信封留下来当夹具，比再写一篇复盘邮件有用。

常见问题 FAQ

这是微软在掐竞品吗？

公开材料不支持这种读法。更接近的解释是共享区域入口和级联流量。Azure 投诉尖峰是线索，不是三家联合签署的根因。架构决策应建立在「入口层会按区域失败」上，而不是建立在动机猜测上。

是不是该立刻自训模型、离开云？

不是同一层问题。这次 demonstratum 的是推理入口和供应商集中度，不是「必须自建千亿模型」。多数团队更该做的是：多一条主路径不同的兜底、熔断、以及统一的错误信封。自训解决不了你把所有流量打进同一区域 ingress 的问题。

Gemini 没事，是不是证明它更可靠？

只能证明当天它的主路径不在同一条共享命运里。Google Cloud 也会有区域事故。不要把一次重叠故障读成模型质量排名；要读成依赖图谱：你的备用供应商是否真的备用。

我的产品明天最少该改什么？

三件能当天做完的事：给所有模型调用加上统一错误信封；主路径失败后切到另一家云上的模型，而不是同一家的另一个快照；重试加 jitter 和熔断，避免自己变成下一家的攻击流量。用 JSONVue 把三家失败样本和这份信封 Schema 对一下。

总结与下一步

9 月 3 日的故事可以压成一句：大众 AI 已经是共享云上的入口服务，模型商标不同，命运却会在同一条区域链路上重叠。Memphis、East US ingress、用户切换，可能是三条线，也可能有交集；在官方 RCA 出来之前，不要把它们捏成一个阴谋，也不要当成互不相干的倒霉。

下一步很具体：把失败收成 JSON，把兜底写成策略，把熔断阈值当成会回放的配置。模型会恢复，状态页会变绿；你的 Agent 会不会在下一次区域入口抖动时再次全体沉默，取决于现在是否还把 "model": "唯一那一家" 写死在代码里。