整理 | 華衛(wèi)

　　半個(gè)互聯(lián)網(wǎng)又又又?jǐn)嗔恕?/p>

　　剛剛，Cloudflare 公司遭遇了持續(xù)數(shù)小時(shí)的宕機(jī)事故，導(dǎo)致多款熱門網(wǎng)站和 AI 服務(wù)下線。據(jù)報(bào)道，此次服務(wù)中斷持續(xù)約五個(gè)半小時(shí)，OpenAI 的 ChatGPT 和 Sora 均在受影響應(yīng)用之列，Claude、Shopify 以及美國(guó)新澤西州公共交通系統(tǒng)的官網(wǎng)也出現(xiàn)了故障。

　　神秘流量激增，

　　導(dǎo)致大范圍宕機(jī)

　　據(jù)外媒報(bào)道，美國(guó)東部時(shí)間 11 月 18 日凌晨 5 點(diǎn) 20 分左右，Cloudflare 首次發(fā)現(xiàn)平臺(tái)出現(xiàn)異常流量。約一個(gè)半小時(shí)后，該公司在狀態(tài)頁(yè)面更新公告，告知客戶此次宕機(jī)事件，服務(wù)中斷表現(xiàn)為出現(xiàn)錯(cuò)誤提示及延遲升高?！癈loudflare 內(nèi)部服務(wù)出現(xiàn)故障。部分服務(wù)可能會(huì)間歇性受到影響，”Cloudflare 在美國(guó)東部時(shí)間早上 7 點(diǎn)前不久發(fā)布的公告中表示。

　　而受此次宕機(jī)影響的并非僅有面向網(wǎng)站的 CDN 服務(wù)。故障還波及了其應(yīng)用服務(wù)產(chǎn)品套件，該套件為云端及本地工作負(fù)載提供 CDN 功能，同時(shí)保護(hù)這些工作負(fù)載的應(yīng)用程序接口免受惡意流量攻擊。

　　Cloudflare 在今年 7 月的一篇博客指出，全球約 20% 的網(wǎng)站依賴其管理和保護(hù)流量。據(jù) DownDetector 稱，此次宕機(jī)事件影響了包括 X、Spotify、OpenAI 的 ChatGPT、特朗普的社交媒體網(wǎng)站 Truth Social、在線設(shè)計(jì)平臺(tái) Canva 以及電影評(píng)分應(yīng)用 Letterboxd 等，甚至 DownDetector 自己的網(wǎng)站也曾短暫受到影響。

　　此次宕機(jī)還影響了至少另外兩項(xiàng)服務(wù)。在故障排查過(guò)程中，Cloudflare 工程師關(guān)閉了倫敦地區(qū)的 WARP 虛擬專用網(wǎng)絡(luò)（VPN）服務(wù)。此外，部分用戶無(wú)法正常使用該公司的 Cloudflare Access 零信任網(wǎng)絡(luò)訪問（ZTNA）工具。ZTNA 產(chǎn)品的用途與 VPN 類似，但能提供更優(yōu)的安全性和性能。

　　美國(guó)東部時(shí)間 11 月 18 日上午 8:09，該公司表示，問題“已查明，正在實(shí)施修復(fù)”，但恢復(fù)過(guò)程并不算順利。美國(guó)東部時(shí)間 11 月 18 日上午 8 點(diǎn) 13 分左右，Cloudflare 重新啟用了倫敦地區(qū)的 WARP 服務(wù)。據(jù) Cloudflare 稱，控制面板服務(wù)已于美國(guó)東部時(shí)間上午 9:34 恢復(fù)。上午 9 點(diǎn) 42 分，該公司在狀態(tài)頁(yè)面宣布，工程師已修復(fù)宕機(jī)的根本原因。接下來(lái)的幾個(gè)小時(shí)里，Cloudflare 持續(xù)監(jiān)控恢復(fù)進(jìn)程，并“尋找加速全面恢復(fù)的方法”。最終，此次服務(wù)中斷于上午 11 點(diǎn) 44 分結(jié)束。

　　Cloudflare 的一位發(fā)言人向外媒證實(shí)，在發(fā)布第一份狀態(tài)更新之前，他們發(fā)現(xiàn)“旗下一項(xiàng)服務(wù)出現(xiàn)異常流量激增”，這 “導(dǎo)致部分流經(jīng) Cloudflare 網(wǎng)絡(luò)的流量出現(xiàn)錯(cuò)誤”?！拔覀?nèi)珕T出動(dòng)，確保所有流量無(wú)誤。之后，我們將集中精力調(diào)查流量異常激增的原因?！盋loudflare 在聲明中說(shuō)道。

　　值得一提的是，在 X 平臺(tái)上，有網(wǎng)友評(píng)價(jià)，“Cloudflare 的 Rust 重寫版本并未經(jīng)得起時(shí)間的考驗(yàn)?！? 月 26 日，。該公司稱，得益于 Rust 語(yǔ)言的特性，此次重構(gòu) “速度更快、安全性更高”。

　　Cloudflare 故障報(bào)告中，專門指出了導(dǎo)致這次宕機(jī)的那行 Rust 代碼。

　　“一行 Rust 代碼崩潰，導(dǎo)致全球一半的流量癱瘓?！辈簧偃苏J(rèn)為，寫過(guò) Rust 的都知道隨意使用 unwrap 都不是一個(gè)好習(xí)慣。也有人指出，“只有當(dāng)配置文件有問題時(shí)，unwrap 才會(huì)失敗?！?/p>

　　還有一位聲稱“朋友在 Cloudflare 工作”的人士表示，“宕機(jī)是因?yàn)橛袀€(gè)工程師試圖修改一份舊配置文件，刪掉了一堆看起來(lái)已經(jīng)過(guò)時(shí)的代碼行。結(jié)果發(fā)現(xiàn)，正是這些代碼行在維持著他們路由系統(tǒng)的穩(wěn)定。配置文件一經(jīng)部署，一半的監(jiān)控系統(tǒng)直接變紅報(bào)警，整個(gè)網(wǎng)絡(luò)開始出現(xiàn)一些甚至他們內(nèi)部文檔都無(wú)法完全解釋的異?，F(xiàn)象。修復(fù)過(guò)程得找回一份塵封已久的備份，回滾一連串自動(dòng)重載操作，還要想辦法讓一個(gè)徹底亂了套的服務(wù)器集群恢復(fù)正常運(yùn)行?！?/p>

　　并且，其透露，“當(dāng)時(shí)（Cloudflare）辦公室里滿是紅牛罐子，大家都在暗自慌神，還有個(gè)資深開發(fā)者一直在重復(fù)念叨‘啥也別碰’?！?/p>

　　官方披露：

　　宕機(jī)的深層原因

　　Cloudflare 運(yùn)營(yíng)著全球約 20% 網(wǎng)站所依賴的內(nèi)容分發(fā)網(wǎng)絡(luò)（CDN）。該平臺(tái)通過(guò)創(chuàng)建網(wǎng)站內(nèi)容的多個(gè)副本，并將其分布在全球各地的數(shù)據(jù)中心來(lái)運(yùn)作。當(dāng)用戶訪問網(wǎng)頁(yè)時(shí)，Cloudflare 會(huì)從距離用戶最近的數(shù)據(jù)中心加載內(nèi)容。該公司表示，這種架構(gòu)能為全球 95% 的人口提供 50 毫秒或更低的延遲。

　　除了提升網(wǎng)站速度，Cloudflare 的平臺(tái)還有其他用途。將流量處理任務(wù)卸載到 CDN 可減輕網(wǎng)站運(yùn)營(yíng)商的服務(wù)器負(fù)載，進(jìn)而提高運(yùn)營(yíng)效率。此外，Cloudflare 還提供網(wǎng)絡(luò)安全功能，能夠過(guò)濾惡意機(jī)器人程序及其他威脅。

　　關(guān)于造成流量激增的原因，當(dāng)晚，Cloudflare 首席技術(shù)官 Dane Knecht 在 X 平臺(tái)的帖子中透露，此次宕機(jī)由公司的惡意機(jī)器人流量過(guò)濾功能引發(fā)，并非攻擊所致。這位高管強(qiáng)調(diào)，“我們的機(jī)器人防護(hù)功能所依賴的一項(xiàng)服務(wù)中存在潛在漏洞，在一次常規(guī)配置變更后開始崩潰，進(jìn)而導(dǎo)致我們的網(wǎng)絡(luò)及其他服務(wù)大范圍出現(xiàn)性能下降?！?/p>

　　同時(shí)，Cloudflare 發(fā)言人也向外媒提供了更詳細(xì)的最新進(jìn)展。據(jù)稱，“此次宕機(jī)的根本原因是一個(gè)自動(dòng)生成的威脅流量管理配置文件。該文件的條目數(shù)量超出預(yù)期規(guī)模，引發(fā)了為 Cloudflare 多項(xiàng)服務(wù)處理流量的軟件系統(tǒng)崩潰。”發(fā)言人表示，“需要明確的是，目前沒有證據(jù)表明這是攻擊行為或惡意活動(dòng)導(dǎo)致的。我們預(yù)計(jì)，事件結(jié)束后流量會(huì)自然激增，部分 Cloudflare 服務(wù)可能會(huì)出現(xiàn)短暫性能下降，但所有服務(wù)將在未來(lái)幾小時(shí)內(nèi)恢復(fù)正常?！?/p>

　　在后續(xù)發(fā)布的博客中，Cloudflare 進(jìn)一步解釋了出現(xiàn)故障的完整經(jīng)過(guò)、受影響系統(tǒng)和處理流程。據(jù)稱，“問題是由于我們數(shù)據(jù)庫(kù)系統(tǒng)的一項(xiàng)權(quán)限更改觸發(fā)的，該更改導(dǎo)致數(shù)據(jù)庫(kù)向一個(gè)由 Bot 管理系統(tǒng)使用的功能文件中輸出了多個(gè)條目。該功能文件的大小隨后翻倍。預(yù)期之外的大功能文件隨后被傳播到構(gòu)成我們網(wǎng)絡(luò)的全部機(jī)器上。這些設(shè)備上運(yùn)行的網(wǎng)絡(luò)流量路由軟件會(huì)讀取這份特征文件，確保機(jī)器人管理系統(tǒng)能及時(shí)應(yīng)對(duì)不斷變化的威脅。該軟件對(duì)特征文件的大小設(shè)有限制，而此次文件大小翻倍后超出了這一限制，導(dǎo)致軟件故障?！?/p>

　　具體來(lái)說(shuō)，“機(jī)器人管理”模塊正是此次宕機(jī)的根源。據(jù)介紹，Cloudflare 的機(jī)器人管理模塊包含多個(gè)系統(tǒng)，其中一款機(jī)器學(xué)習(xí)模型會(huì)為流經(jīng)其網(wǎng)絡(luò)的每一項(xiàng)請(qǐng)求生成機(jī)器人評(píng)分。客戶借助這些評(píng)分決定是否允許特定機(jī)器人訪問其網(wǎng)站。該模型的輸入數(shù)據(jù)是一份 “特征” 配置文件，這份特征文件每幾分鐘更新一次，并同步至整個(gè)網(wǎng)絡(luò)，使其能夠應(yīng)對(duì)互聯(lián)網(wǎng)流量的變化。

　　而正是底層 ClickHouse 查詢行為的一項(xiàng)變更，導(dǎo)致生成的文件中出現(xiàn)大量重復(fù)的 “特征” 行。這一變化改變了此前固定大小的特征配置文件的尺寸，引發(fā)機(jī)器人模塊觸發(fā)錯(cuò)誤。結(jié)果是，負(fù)責(zé)為客戶處理流量的核心代理系統(tǒng)，向所有依賴該機(jī)器人模塊的流量返回了 HTTP 5xx 錯(cuò)誤碼。這一問題還影響了依賴核心代理的 Workers KV 和 Access 服務(wù)。

　　其做出的變更是，讓所有用戶都能獲取其有權(quán)訪問的表的準(zhǔn)確元數(shù)據(jù)。但問題在于，他們過(guò)去的代碼中存在一個(gè)預(yù)設(shè)前提：此類查詢返回的列列表只會(huì)包含 default 數(shù)據(jù)庫(kù)的內(nèi)容，該查詢不會(huì)對(duì)數(shù)據(jù)庫(kù)名進(jìn)行過(guò)濾。隨著他們逐步向目標(biāo) ClickHouse 集群的用戶推出這一顯式權(quán)限，上述查詢開始返回列的 “重復(fù)項(xiàng)”，這些重復(fù)項(xiàng)來(lái)自存儲(chǔ)在 r0 數(shù)據(jù)庫(kù)中的底層表。不巧的是，機(jī)器人管理模塊的特征文件生成邏輯，正是通過(guò)這類查詢來(lái)構(gòu)建本節(jié)開頭提到的文件中的每個(gè)輸入 “特征”。

　　由于用戶獲得了額外權(quán)限，查詢響應(yīng)現(xiàn)在包含了 r0 數(shù)據(jù)庫(kù)模式的所有元數(shù)據(jù)，導(dǎo)致響應(yīng)行數(shù)增加了一倍多，最終影響了輸出文件中的行數(shù)（即特征數(shù)量）。起初，他們還誤判觀察到的癥狀是由超大規(guī)模分布式拒絕服務(wù)（DDoS）攻擊引發(fā)，但隨后準(zhǔn)確識(shí)別出核心問題，成功阻止了這份超出預(yù)期大小的特征文件繼續(xù)傳播，并替換為早期版本。

詳細(xì)報(bào)告鏈接：

https://blog.cloudflare.com/18-november-2025-outage/

　　六年來(lái)最嚴(yán)重中斷，

　　“真相”被嘲瘋了？

　　在大范圍宕機(jī)期間，Cloudflare 的股價(jià)下跌了約 3%。

　　“鑒于 Cloudflare 服務(wù)的重要性，任何宕機(jī)都是不可接受的。網(wǎng)絡(luò)曾一度無(wú)法正常路由流量，這讓我們團(tuán)隊(duì)的每一位成員都深感痛心。我們知道，今日辜負(fù)了大家的信任?！盋loudflare 在博客中也表示。

　　并且，該公司說(shuō)明了后續(xù)加固系統(tǒng)以防止此類故障的步驟，包括以下方面：

　　按用戶生成輸入的防護(hù)標(biāo)準(zhǔn)，強(qiáng)化對(duì) Cloudflare 內(nèi)部生成配置文件的接收校驗(yàn)；

　　為相關(guān)功能增設(shè)更多全局緊急關(guān)閉開關(guān)；

　　避免核心轉(zhuǎn)儲(chǔ)或其他錯(cuò)誤報(bào)告占用過(guò)多系統(tǒng)資源；

　　全面審查所有核心代理模塊的各類錯(cuò)誤場(chǎng)景故障模式。

　　對(duì)于此次的宕機(jī)事故，Cloudflare 承認(rèn)，這是其自 2019 年以來(lái)最嚴(yán)重的一次宕機(jī)?！拔覀円酝舶l(fā)生過(guò)宕機(jī)事件，比如導(dǎo)致控制臺(tái)無(wú)法訪問，或是部分新功能暫時(shí)不可用，但在過(guò)去六年多里，從未出現(xiàn)過(guò)導(dǎo)致大部分核心流量無(wú)法通過(guò)我們網(wǎng)絡(luò)傳輸?shù)那闆r?！?/p>

　　據(jù)了解，該公司上一次重大宕機(jī)發(fā)生在 6 月，當(dāng)時(shí)其超過(guò)六項(xiàng)服務(wù)下線約兩個(gè)半小時(shí)。那次宕機(jī)由 Workers KV 數(shù)據(jù)存儲(chǔ)平臺(tái)的故障引發(fā)。

　　有網(wǎng)友評(píng)價(jià)，“這純屬 Cloudflare 自己搞砸了。一個(gè)小故障，就成了第一塊多米諾骨牌?！币灿腥苏J(rèn)為，“這次宕機(jī)本身是件小事，但它暴露了 Cloudflare 自身服務(wù)之間過(guò)度的耦合問題，導(dǎo)致控制面板也無(wú)法訪問它。如果控制面板可用，將能讓許多服務(wù)更快地部分恢復(fù)功能?！?/p>

　　還有人發(fā)出疑問：“互聯(lián)網(wǎng)真的需要如此嚴(yán)重地依賴單一供應(yīng)商嗎？”同時(shí)，亦有批評(píng)人士表示，此類宕機(jī)事件充分暴露了互聯(lián)網(wǎng)的脆弱性，尤其是當(dāng)所有人都依賴相同的服務(wù)提供商時(shí)。

　　https://siliconangle.com/2025/11/18/cloudflare-outage-briefly-takes-chatgpt-claude-services-offline/

　　https://arstechnica.com/tech-policy/2025/11/widespread-cloudflare-outage-blamed-on-mysterious-traffic-spike/

　　聲明：本文為 AI 前線整理，不代表平臺(tái)觀點(diǎn)，未經(jīng)許可禁止轉(zhuǎn)載。