昨天一個網站的更新，讓外國人集體斷網6小時_風聞

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

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