ChatGPT、Claude宕机两三小时，没人说为什么
9月3日，Anthropic的官方状态页记录得清清楚楚：13:26 UTC（北京时间21:26）开始排查"多个模型请求错误率上升"，16:16 UTC影响结束，合计约2小时50分。OpenAI的记录是14:43 UTC开始排查，16:55 UTC宣布解除，约2小时12分。
也就是说，这不是"同时宕机"，而是相隔77分钟先后失守、又在同一个下午先后恢复。中文互联网的通行解释是Cloudflare倒了、AI跟着倒，多家媒体把Cloudflare状态页上的两条问题当成了原因。但把这两条问题的原始记录逐字调出来看，时间和性质都对不上。
被当成"真凶"的两条故障，一条始于8月31日，一条始于8月27日
Cloudflare状态页直到9月4日凌晨仍挂在"活跃事件"里的两个问题，第一个编号8x66bpk6p9kk，标题是"影响R2自定义域名的HTTP/3问题"，起始时间8月31日18:47 UTC；第二个是"部分WARP用户地理位置识别错误"，起始时间8月27日18:46 UTC。两条的影响等级都标着Minor Impact（轻微影响）。
细节更能说明问题。R2那条的原始描述是"部分Firefox用户可能在R2自定义域名上遇到资源加载延迟或失败，原因是HTTP/3通告错误"——受影响面被限定在一类浏览器加一种域名配置上，9月1日Cloudflare称已定位原因，9月3日15:14 UTC转入"监控修复效果"。WARP那条是用户被第三方服务错误定位，Cloudflare说"正在与第三方提供商合作修复"，从8月27日到9月1日每天更新一句"仍在修复中"。
9月3日当天Cloudflare新开的故障只有一条："北美西部R2出现较多503错误"，影响窗口是1:04至1:28 UTC，24分钟，1:49 UTC就标记为已解决。这个结束时间，比Claude开始出问题早了11个半小时。
公告里最反常的不是宕机，是谁都没说原因
把两家公司的公告并排放，会发现措辞惊人地一致："elevated errors"（错误率上升）、"investigating"（排查中）、"identified the cause"（已定位原因）、"resolved"（已解决）。
Anthropic在13:41 UTC明确写了"我们已经定位到原因"，但直到事件关闭，状态页上没有一句话说原因是什么。OpenAI从14:43开始排查到16:55解除，全程三句更新，同样没有任何根因表述，只留下一句"部分Codex远程控制用户可能需要重新配对其移动设备"。截至发稿，两家都没有发布事后复盘。
值得注意的是Anthropic列出的受影响面：claude.ai、Claude API、Claude Code、Claude Cowork四个组件同时上榜，但故障被精确地圈在Mythos/Fable 5.1、Mythos/Fable 5、Opus 5、Opus 4.8、Opus 4.6这几个具体模型上，15:25 UTC还专门更新说"目前只剩Opus 4.8和Opus 5受影响，其余模型已回到基线错误率"。
这里要做一层分析边界的说明：如果问题出在CDN或边缘网络这类公共入口上，理论上所有模型会一起超时、一起报网络错误，不会按模型代号分批恢复。按模型分批，指向的是推理服务层自身的容量或调度问题。这是从故障形态做出的推断，不是任何一家公司给出的结论——三家都没有点名上游。
99.6%的可用率，拆开看比听起来脆
OpenAI状态页90天口径：APIs组件99.94%、ChatGPT组件99.62%、Codex组件99.98%。Anthropic给的是claude.ai 99.4%、Claude API 99.5%、Claude Code 99.44%、Claude Console 99.93%。
百分比看着都过99%，换算成绝对时长才有意义：90天约2160小时，99.62%意味着约8.2小时不可用，99.4%意味着约13小时不可用，而99.94%只有约1.3小时。同一家公司内部，面向个人订阅的入口和面向企业按量计费的接口，不可用时长差了6倍左右。更要紧的是，OpenAI状态页自己注明了口径："可用率是在所有层级、所有模型、所有错误类型上的汇总值，单个客户的可用性可能不同。"换句话说，一个只调用Opus 5的企业集成方，从这个数字里看不出自己那天经历了什么。
频次同样不是偶发。OpenAI状态页的历史记录里，9月1日到3日三天出现5条故障记录，8月11日一天有5条，7月27日也是5条。9月3日这一天，OpenAI自己也有两条：凌晨的"ChatGPT Work Mode高错误率"，以及下午这一次。
下游的传导这次有明确记录。编程工具Cursor确认其部分服务因上游模型中断受到影响，Claude Code和Codex同时进入受影响清单，意味着依赖这两个通道的agent工作流在同一天集中失效。华尔街见闻统计的DownDetector用户报告量是OpenAI超过1.2万份、Claude约1200份、Grok约1000份；这个数字属于第三方监测口径，未获公司确认。
反差点在同一个下午：据财联社报道，OpenAI当天正在发布预热下一代模型的视频（外界称GPT-6、代号Astra），评论区的高赞是"先把机房修好再炫耀"；国内厂商智谱则发声"我们还在"。
下一次宕机之前，有四件事值得盯
第一，看有没有根因复盘。事件关闭不等于原因清楚，Anthropic说"已定位原因"却不公布，是这次事件里最值得警惕的一点。
第二，看故障是按模型分批还是按网络分批，这决定了该找模型厂商还是找云厂商，也决定了企业该怎么设计多模型路由的降级路径。
第三，看上游依赖是否被点名。围绕这次事件的归因已经出现三套说法：财联社指向Cloudflare，华尔街见闻猜测与微软Azure有关，被Anthropic员工CJ Avilla在个人社交账号上转述的则是"基础设施问题"——三个版本都没有出现在任何官方公告里。xAI的状态页在9月4日凌晨无法访问，Grok一侧的官方时间线目前缺失；Gemini和微软Copilot是否真的受影响，两家媒体的说法直接互相矛盾。
第四，看合同里的可用率口径。当一个只影响特定模型的故障能被汇总成"99.5%"，按模型、按区域拆分SLA就不是采购方可以忽略的条款细节。
这场故障真正暴露的，不是某一家云厂商有多脆弱，而是整个行业在故障时依然只能给出"错误率上升"四个字——连"谁挂了、为什么挂"都说不清的系统，谈不上可靠的地基。