差友们，昨晚你们网速足够快的话最好的配资官网，应该已经见证了一场互联网大戏——
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最好的配资官网
恒盛智投提示：文章来自网络，不代表本站观点。
相关文章
热点资讯
