Cloudflare 收购 Replicate 之余，还挂了一波，导致 X、ChatGPT 瘫痪...

CF 收购 Replicate

近日，Cloudflare 宣布将收购 AI 平台 Replicate（Cloudflare to Acquire Replicate to Build the Most Seamless AI Cloud for Developers^[1]），目标是把 Workers 打造成对开发者来说最无缝的一体化 AI 云：未来开发者只需一行代码，就能在 Cloudflare 全球网络上调用和部署任意模型。Replicate 提供 5 万多个可用于生产环境的模型和活跃的开发者社区，将在并入后全面开放给 Workers AI 用户，用于构建无服务器应用，并支持自定义模型与复杂推理流水线。Cloudflare 认为这笔收购能够进一步抽象掉 GPU、基础设施和后端架构的复杂性，让不同水平的开发者都能更轻松地构建可扩展、快速且可靠的 AI 应用。Replicate 团队也表示，希望借助 Cloudflare 的全球网络，把原本门槛很高的 AI 部署，变成真正大众化的开发基础设施。交易预计在未来两个月内完成，仍需满足常规交割条件。

CF 故障

刚才我的 ChatGPT、X 全都挂了，换个节点可以访问了。太难了，以后使用 ChatGPT 不光要关注节点、网络、OpenAI Status^[2]、还要关注一下 Cloudflare Status^[3]...

故障描述

原因分析

下面是基于公开信息和 Cloudflare 以往事故做的一些技术推测，仅供参考，并非官方结论：

• 核心控制/配置服务异常（比如 Workers KV / 配置存储之类）
• 今年 6 月 Cloudflare 有一次大事故，就是底层存储供应商故障 → 导致 Workers KV 崩掉 → 一堆产品的配置/鉴权/路由都拿不到，返回 500。(Cloudflare service outage June 12, 2025^[4])
• 现在也是 “大面积 500 + Dashboard / API 也挂掉”，很像是核心内部服务/配置层出问题，而不是单一 PoP 宕机。
• 全局路由 / Anycast 网络控制出错
• Cloudflare 是 Anycast 全球网络，路由策略、BGP 广告、内部服务发现一旦出 bug 或操作失误，很容易出现：某些地区找不到正确上游、或者被导向“坏后端”。
• 这类问题常见表现就是：大量 500 / 超时，而不是 4xx。
• 配置发布 / 部署错误：
• cloudflare 自己也经常在复盘里承认：新的 WAF 规则、路由策略、内部服务配置等，一旦以“全网发布”的方式推错版本，很容易被放大成整体性故障。
• 这次 500 + Dashboard / API 一起挂，也说明很可能是内部控制平面本身就依赖了这次出问题的那部分服务。
• 和计划内维护冲突 / 触发链式反应
• Cloudflare 在多个机房有计划维护（EWR、FRA 等），不排除存在：维护 + 某个新配置/迁移、触发之前没暴露的系统缺陷、放大为全网级别的问题。

为何 Cloudflare 挂了，会拖着 X、ChatGPT 一起？

可以简单理解为：Cloudflare 是互联网的“高速公路 + 收费站 + 安检门”，很多大站的流量入口都经过它。很多网站用 Cloudflare 做：

• CDN / 反向代理：用户访问 example.com，请求其实先打到 Cloudflare 边缘节点，再由它转发到源站。
• DDoS 防护 / WAF：所有请求先经过 Cloudflare 的“防火墙规则”（安全策略和规则检查）。
• DNS 解析：域名可能直接交给 Cloudflare 做权威 DNS，或者用户本地用的是 1.1.1.1 公共 DNS。

所以当 Cloudflare 自己的全球网络出问题时，会出现几种典型现象：

• 500 错误
• 用户访问网站 → 实际命中的是 Cloudflare 的边缘节点。
• 边缘节点内部出错 / 无法访问源站 → 返回 500（来自 Cloudflare，而不是源站应用本身）。
• DNS 解析异常
• 如果权威 DNS 出问题，域名直接解析不到 IP，用户就“连不上这个网站”。
• 或解析延迟飙升，让你感觉“网特别卡，什么都在转圈”。
• 部分地区 / 部分 ISP 特别惨
• Anycast + 路由异常时，某个地区的用户刚好被路由到“坏节点”。
• 于是你会看到：“有人能上，有人完全打不开”。

其他影响

像 X、ChatGPT 这种服务，本身的核心 API 不一定全部跑在 Cloudflare 上，它们一般会混用多家基础设施。但仍然有很多潜在依赖链可能被波及：

• 外围组件走 Cloudflare
• 官网、文档、静态资源、图标、脚本、遥测等，很多是经由 Cloudflare 或托管在使用 Cloudflare 的域名上。
• 某个关键脚本挂了，前端应用可能直接初始化失败，看起来就是“服务炸了”。
• 第三方依赖链路
• 页面里的字体、图标库、分析脚本、CDN 资源等都可能挂在 CF 上。
• 这些资源超时 / 报错时，前端逻辑会卡死或者异常，用户能感知到的就是“页面怎么一点反应都没有”。
• DNS / 网络路径依赖
• 一些区域用户的 DNS 解析走 1.1.1.1 或 Cloudflare 边缘节点；
• 如果这些节点炸了，你访问任何站（如 ChatGPT）都可能“感觉像全网断了一样”。
• 整体互联网拥塞 / 报障风暴
• Cloudflare 一挂，全球大量网站报错，用户疯狂刷新、各种监控也在重试；
• 网络上多了一大堆失败重试流量，进一步挤占资源。
• 其他云服务（比如 OpenAI）即便没直接出故障，也可能因为周边网络环境恶化而出现抖动。

最终你看到的体验就会变成：“感觉今天整个互联网都不太稳定：X 挂、ChatGPT 经常抽风（顺带一提，它平时也会自己抽风，不一定是 CF 的锅）、各种网站莫名其妙 500…”

教训

站在架构师视角，这类事件其实非常典型，会自然联想到几点：

• 单一大供应商的系统性风险
• Cloudflare 这种“超级中枢”的问题在于：一旦中枢挂了，影响的是整个生态，而不仅仅是自己的 SLA（Service Level Agreement, 服务等级协议）。
• 如果你把 DNS、CDN、WAF、API 网关、Zero Trust、Workers 等全都压在同一家，就会天然承受集中风险。
• 多路径 / 多供应商容灾（现实很难，但值得思考），例如：
• DNS 层：Cloudflare + Route53 / NS1 等冗余。
• CDN + 反代：Cloudflare + 自建 Nginx + 另外一层 CDN。
• 好处是可以在某一方出问题时有退路，代价是复杂度飙升、运维难度极高，很多中小团队根本扛不住。
• 前端降级策略：即便某些外部脚本 / 资源挂掉，主功能尽量可用。
• 避免一两个追踪脚本 loading 失败就把整页应用卡死。
• 关键静态资源尽量有自托管 + CDN 双通道，或者本地 fallback。
• 用户感知与状态页透明度
• 像这次这样的大故障，状态页 + 社交媒体同步非常关键。
• 能帮助用户区分：是“我本地网烂了”，还是“世界真的塌了”。

References