整理 | 華衛(wèi)

　　半個互聯網又又又斷了。

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

　　神秘流量激增，

　　導致大范圍宕機

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

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

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

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

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

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

　　值得一提的是，在 X 平臺上，有網友評價，“Cloudflare 的 Rust 重寫版本并未經得起時間的考驗?！? 月 26 日，。該公司稱，得益于 Rust 語言的特性，此次重構 “速度更快、安全性更高”。

　　Cloudflare 故障報告中，專門指出了導致這次宕機的那行 Rust 代碼。

　　“一行 Rust 代碼崩潰，導致全球一半的流量癱瘓?！辈簧偃苏J為，寫過 Rust 的都知道隨意使用 unwrap 都不是一個好習慣。也有人指出，“只有當配置文件有問題時，unwrap 才會失敗。”

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

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

　　官方披露：

　　宕機的深層原因

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

　　除了提升網站速度，Cloudflare 的平臺還有其他用途。將流量處理任務卸載到 CDN 可減輕網站運營商的服務器負載，進而提高運營效率。此外，Cloudflare 還提供網絡安全功能，能夠過濾惡意機器人程序及其他威脅。

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

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

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

　　具體來說，“機器人管理”模塊正是此次宕機的根源。據介紹，Cloudflare 的機器人管理模塊包含多個系統(tǒng)，其中一款機器學習模型會為流經其網絡的每一項請求生成機器人評分。客戶借助這些評分決定是否允許特定機器人訪問其網站。該模型的輸入數據是一份 “特征” 配置文件，這份特征文件每幾分鐘更新一次，并同步至整個網絡，使其能夠應對互聯網流量的變化。

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

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

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

詳細報告鏈接：

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

　　六年來最嚴重中斷，

　　“真相”被嘲瘋了？

　　在大范圍宕機期間，Cloudflare 的股價下跌了約 3%。

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

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

　　按用戶生成輸入的防護標準，強化對 Cloudflare 內部生成配置文件的接收校驗；

　　為相關功能增設更多全局緊急關閉開關；

　　避免核心轉儲或其他錯誤報告占用過多系統(tǒng)資源；

　　全面審查所有核心代理模塊的各類錯誤場景故障模式。

　　對于此次的宕機事故，Cloudflare 承認，這是其自 2019 年以來最嚴重的一次宕機。“我們以往也發(fā)生過宕機事件，比如導致控制臺無法訪問，或是部分新功能暫時不可用，但在過去六年多里，從未出現過導致大部分核心流量無法通過我們網絡傳輸的情況。”

　　據了解，該公司上一次重大宕機發(fā)生在 6 月，當時其超過六項服務下線約兩個半小時。那次宕機由 Workers KV 數據存儲平臺的故障引發(fā)。

　　有網友評價，“這純屬 Cloudflare 自己搞砸了。一個小故障，就成了第一塊多米諾骨牌。”也有人認為，“這次宕機本身是件小事，但它暴露了 Cloudflare 自身服務之間過度的耦合問題，導致控制面板也無法訪問它。如果控制面板可用，將能讓許多服務更快地部分恢復功能?！?/p>

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

　　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 前線整理，不代表平臺觀點，未經許可禁止轉載。