差友们，昨晚你们网速足够快的话，应该已经见证了一场互联网大戏——

Cloudflare 崩了。

这可不是一般的崩，是那种能让半个地球互联网一起陪葬的崩。

刚开始大伙儿还一脸懵逼，有人发现推特登不上了，好不容易登上去了吧，啥也刷不出来。

同样的，ChatGPT 也寄了，设计工具 Canva 也打不开，国外兄弟正在打 LOL 和瓦罗兰特的排位呢，直接连不上服务器了。。。

更离谱的是，当所有人想去 Down Detector 查查到底哪个网站崩了的时候，发现 Down Detector 也崩了。

好好好，想看热闹，结果自己成了热闹。

差评君昨天也亲身经历了这场灾难。

我正在 Product Hunt 给个 App 投票呢（因为投了给我打五折），结果死活点不动。后来刷朋友圈吧，又发现之前给大家推荐的网页红警也进不去了。

这一切的始作俑者，就是 Cloudflare。

大部分挂掉的网页都出现了 Error 500，清清楚楚写着 Cloudflare 炸了。

只能说一家公司打个喷嚏，全世界感冒。

眼看社交媒体不能逛，ChatGPT 不能聊，游戏不能打，全球网友开始了集体哀嚎。

有人哭诉：就因为 Cloudflare，我的 AI 女友都联系不上了。。。

——怎么和美国人形容 Cloudflare 崩了有多严重？

——你们没汉堡吃了（*点餐机崩了）

还有人截了一张动图，展示了 Cloudflare 服务中断后的互联网世界。。。

甚至有人发现了新大陆，Cloudflare 崩了之后我的生活全是蓝天白云。

就在这一片哀嚎声中，有个叫 MrShibolet 的用户发的推特，突然火了：

Cloudflare 入职第一天，推送了点更新，下午准备休息咯✌️

配图里的他站在 Cloudflare 前台前，摆着不太聪明的姿势，双手扶着衣边，倔强的嘴角微微上扬。

这条推特一下传开了，60 万次阅读，所有人都在说：兄弟第一天上班就是最后一天。。。

但其实，这哥们是整活的。

上个月 AWS 崩的时候，他也发过一模一样的推文，这次无非是把名字换成了 Cloudflare。

行了，现在你应该知道昨晚的互联网有多热闹了。。。

到这肯定有人好奇，Cloudflare 到底是个啥？凭啥它崩了，这么多网站都得跟着炸？

简单说，Cloudflare 就像是互联网的物业公司，负责网站的安全、加速、流量管理。

主要业务包括 CDN（内容分发网络）、DDoS 防护、Web 应用防火墙、DNS 服务等等。

正常情况下，你访问一个网站，就是你的浏览器直接连到网站服务器。但如果网站用了 Cloudflare，流程就变成了：

你的浏览器 → Cloudflare → 网站服务器 → Cloudflare → 返回给你。

你说绕这么大圈子图个啥呢？

图的是：又快又稳。

Cloudflare 在全球铺了 330 多个数据中心，当你访问用了 Cloudflare 的网站时，它会自动把你导向离你最近的那个数据中心，这样访问速度会快很多。

这就好比你网购，商家从本地仓发货，当然比外地的总仓要快很多。

除了快，Cloudflare 还给网站当保镖，防 DDoS 攻击、管理机器人爬虫、缓存内容减轻源服务器压力。

说白了，网站用了 Cloudflare，就相当于小区请了一个五星级物业。

有外人来了，他先站在门口验个身份，填个来访记录，把可疑的人拦在外面，确认是正经访客了再给他们套个五速鞋，加速访问。

但问题也来了——

一旦这个物业系统崩了，保安集体脑子宕机，那所有人都进不了小区——

想访问网站的人，全被 Cloudflare 拦在了门外。

按理说，一个搞互联网基础设施的公司，不应该轻易崩掉。

可一旦它崩了，那就是真正的牵一发动全身，崩一屁臭整屋。

所以，什么情况下会崩？

Cloudflare 自己发了个事故报告，我看完了只有一个感觉：这也能崩？

咱简单聊一下。

Cloudflare 有个功能叫 Bot Management（机器人管理），它不光能识别出恶意机器人 bot，还能给每个访问者打分。

网站管理员可以自己定规矩：你这访客素质得到多少分，才配来我家玩。

比如电商网站可能设置 70 分以上才能下单，防止抢购机器人；新闻网站估计 30 分就行，毕竟得让搜索引擎爬虫进来。

这个打分系统需要一个特征文件，里面记录了各种判断标准，一般有 60 种。

访问速度异常快？浏览器信息很奇怪？扣分！

IP 地址很可疑？行为模式像爬虫？扣分！

那这个文件是怎么生成的呢？

其实很简单，系统每隔 5 分钟就会向后台数据库喊一嗓子：“喂，把最新的 Bot 特征清单发我一份！”

这样频繁的更新，可以确保应对最新的威胁。

本来这套一问一答的流程跑得稳稳当当。

但在 11 月 18 号上午 11 点（UTC 时间，下同），工程师对数据库搞了一波权限微调，直接把数据库搞精神分裂了。

首先，咱们要理解一下 Cloudflare 那个名叫 ClickHouse 的数据库架构，它是专门处理海量数据的。

另外 Cloudflare 的数据量是非常大，一台服务器根本塞不下。所以，他们被迫搞了个分店模式（学名叫分片存储）。

你可以把 Cloudflare 的数据库想象成一家连锁书店，在北上广都有仓库。

前台总管（代号 Default）： 它坐在总部办公室，手里只拿一张索引目录。它不存真书，只负责告诉你书在哪儿。平时系统来查数，都是直接问它。

各地分仓库（代号 r0）： 这些是分布在北京、上海、广州等地的仓库，真正的书（数据）都在这儿堆着。

原本的流程非常丝滑。

系统喊一嗓子：“给我一份 Bot 特征清单！” 前台总管（Default） 微微一笑，递出一张单子：“给，一共 60 个特征。”

特征 1: 访问速度

特征 2: IP 地址

特征 3: 浏览器类型

。。。

系统接单，一切正常。

但在 18 号一波权限调整后，把原本指向前台总管的单线电话，改成了一个连接全公司的大喇叭。

这时候，系统再喊那句老话：“给我一份 Bot 特征清单！”，问题就出现了。

因为没指名道姓，对面彻底乱套，所有人都在抢答：

前台总管：“给，这是 60 个特征！”

北京分仓库（r0-分片 1）：“俺也一样！这是 60 个特征！”

上海分仓库（r0-分片 2）：“巧了！我也有一份 60 个特征！”

广州分仓库（r0-分片 3）：“俺也一样！”

一堆分仓库冲上来对着你的耳朵疯狂复读，原本只有 60 行的特征清单，瞬间被复制成了几百行。

尴尬的是，Cloudflare 在设计系统时，为了性能考虑，给特征文件设了个上限：最多 200 个特征。

他们想着平时也就 60 多个，撑死 100 个，200 怎么着也够用了。

谁能想到这帮哥们一复读，数据量原地起飞，瞬间冲破 200 大关。

系统一看到这清单，当场两眼一黑，崩溃不干了。

这还没完，更骚的来了。

这个崩溃它不是一直崩，而是仰卧起坐的崩。

因为 Cloudflare 数据库集群的更新，是分批进行的。有些节点数据库更新了，有的还是老版本。

所以系统每 5 分钟进来抓一个数据库问话，都相当于一次开盲盒。

运气好 → 碰到老版本 → 总管答复 → 60 条特征数据 → 网站恢复了。

运气背 → 碰到新版本 → 一群人答复 → 几百条重复数据 → 网站又崩了。。。

这就是为啥一开始在用户眼里，这些网站时好时坏。

上一秒还在骂娘，下一秒突然刷出来了；刚想上推特学习，看到一半又卡了。

这张 GIF 更传神了

Cloudflare 的工程师一开始也蒙圈，看着流量忽高忽低、网站时好时坏，第一反应是：完了，是不是又被 DDoS 攻击了？

毕竟前段时间才刚挡下一个 7.3Tbps 的超级攻击，这种症状太像攻击流量的波动了。

更巧的是，连他们自己的状态页也崩了（后来发现纯属巧合），搞得工程师们一度怀疑：这是有人连我们的状态页一起攻击啊！

在尝试了限流、切换路由等各种操作后，他们终于发现了是自己人在背刺。

于是 14:24，他们赶紧停止自动生成新配置文件，手动翻出一个之前能正常工作的旧版本，测试确认没问题，然后推送到全球所有服务器，大部分服务开始恢复。

最终 17:06，所有下游服务逐步重启完成，清理掉之前的错误状态，宕机正式结束。

整个过程持续了将近 6 个小时。。。

Cloudflare 在官方事故报告里承认了自己的错误，并承诺会加强配置文件检查、审查所有模块的容错能力，具体细节差评君就不展开了。

这些措施听起来都挺合理，但每次大厂宕机后都会发类似的保证书。

上个月 AWS 崩了，这个月 Cloudflare 崩了，过段时间说不定又轮到谁。

对于大多数普通用户来说，昨天这场宕机可能就是“网站打不开了，等等就好”。但对于那些严重依赖在线服务的企业来说，这是真金白银的损失。

上个月 AWS 的宕机影响了 60 个国家 1700 多万用户 ，导致 3500 多家公司业务中断，经济损失每小时超过 7500 万美元。

这次 Cloudflare 宕机 6 小时，损失恐怕也少不了。

用户们可能什么都做不了，开发者可以考虑多云部署、备用方案，但成本和复杂度都会大大增加，小公司根本玩不起。

咱们就只能期待这些基础设施公司真的能从每次事故中吸取教训。

毕竟整个互联网就是建立在极少数基础设施公司之上，它就像一座空中楼阁，看起来宏伟无比，但地基只有那么几根柱子。

哪根柱子晃一晃，整座楼都得跟着颤。

撰文：刺猬

编辑：面线 莽山烙铁头

美编：焕妍

图片、资料来源：

Cloudflare outage on November 18, 2025

Reddit、X