差友們，昨晚你們網速足夠快的話，應該已經見證了一場互聯網大戲——

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