2025年11月18日，網路的很大一部分癱瘓了。
如果你打開ChatGPT、X（Twitter）、英雄聯盟、Shopify、Coinbase或無數其他小型網站，你會看到一個帶有Cloudflare標誌的5xx錯誤頁面——或者這些網站根本無法加載。起初，這看起來像是另一個「網路崩潰」的重大事件，但後來發現，問題其實更加隱蔽，在某些方面也更加令人擔憂：這是Cloudflare自身基礎設施深處的漏洞。
以下是對昨天（2025年11月18日）Cloudflare服務中斷事件的詳細分析，包括事件發生的原因、受影響的用戶以及基礎設施團隊應該從中吸取的教訓。
昨天究竟發生了什麼事？
2025年11月18日星期二，UTC時間上午晚些時候，Cloudflare開始回傳大量HTTP 5xx伺服器錯誤，這些錯誤針對的是流經其網路的流量。對於最終用戶而言，這意味著在嘗試訪問許多熱門網站和應用程式時會看到「內部伺服器錯誤」或「網關錯誤」頁面。
根據 Cloudflare 事後發布的部落格文章，這次故障：
於 UTC 時間 11:28 開始影響客戶的 HTTP 流量
核心 CDN 和安全服務出現大量 5xx 錯誤
於 UTC 時間 13:05 至 14:30 左右採取了主要的緩解措施
於 UTC 時間 17:06 前將 5xx 錯誤量恢復至基線水準。 Cloudflare 部落格
Cloudflare 將其描述為自 2019 年以來最嚴重的故障，因為它不僅影響了某個功能或控制面板，還破壞了透過其網路路由大部分客戶流量的核心代理層。 Cloudflare 部落格
第三方監控也證實了這一點。思科ThousandEyes監控到Cloudflare在全球發生故障，導致X、OpenAI（ChatGPT）和Anthropic等服務出現逾時和5xx錯誤，但網路路徑本身看起來正常。這強烈顯示故障出在後端服務，而非ISP層級或路由問題。 ThousandEyes
哪些服務受到影響？
由於Cloudflare服務涵蓋了網路的很大一部分（約20%的網站依賴Cloudflare來提升效能和保障安全），因此這次故障的影響範圍非常廣泛。 AP News+1
受影響的服務包括：
ChatGPT / OpenAI
X（原Twitter）
Canva、Shopify、Dropbox、Coinbase
《英雄聯盟》和其他遊戲平台
包括新澤西州交通局和法國國家鐵路公司（SNCF）數位系統在內的多個公共交通和政府網站。 AP News+1
Downdetector等故障追蹤網站在高峰期記錄到數千份並發故障報告。路透社通報稱，光是 X 網站就一度有約 5,000 名用戶受到影響，隨著修復措施的推出，受影響用戶數量有所下降。
從使用者的角度來看，這表現為：
網站完全無法加載
登入流程卡頓或失敗（尤其是在涉及 Cloudflare Access 或 Turnstile 的情況下）
API 回應斷斷續續或出現 5xx 錯誤
控制面板和管理面板逾時
換句話說：儘管根本原因集中在單一服務提供者的內部系統中，但網路的大部分內容都「感覺癱瘓了」。
Cloudflare 的工作原理（簡述）
要了解這次故障為何如此嚴重，了解要求在 Cloudflare 網路中的大致路徑很有幫助。
Cloudflare 充當反向代理 CDN 和安全層：
您的瀏覽器或應用程式連接到 Cloudflare，而不是直接連接到來源網站。
Cloudflare 在其邊緣終止 TLS 和 HTTP 請求。
請求流入 Cloudflare 的核心代理系統，即 FL（“Frontline”）及其新一代 FL2。
該核心代理：
應用 WAF（Web 應用防火牆）規則
運行機器人管理模型
處理 DDoS 防護、快取和源站出站流量
將流量路由到其他內部產品，例如 Workers、R2、Access 等。 Cloudflare 部落格
在正常運作情況下，此架構具有很高的彈性：如果一個資料中心出現問題，流量會透過其他資料中心路由；配置變更會謹慎地推出；各個功能的故障應以可控的方式進行。
昨天的故障之所以如此嚴重，正是因為故障發生在通用代理路徑內部，並且與一個頻繁自動推送至全球的設定檔緊密相關。
根本原因：一個機器人管理功能文件故障
Cloudflare 的官方解釋指出，罪魁禍首是關鍵因素：
其機器人管理系統使用的一個功能性設定檔。 Cloudflare 部落格
以下是事件經過的簡要說明：
機器人管理使用“特徵文件”
Cloudflare 的機器人偵測模型依賴一組「特徵」——這些特徵是關於每個請求的訊號，用於判斷請求是來自真人還是機器人。
這些特徵被打包到一個設定檔中，該檔案每隔幾分鐘重新產生一次，並在全球範圍內部署，以便 Cloudflare 能夠快速適應新的攻擊模式。 Cloudflare 部落格
ClickHouse 查詢行為的變更
特徵檔案由針對 ClickHouse 資料庫的查詢產生。
Cloudflare 在 UTC 時間 11:05 左右進行了變更，以提高分散式查詢的安全性和權限控制—允許
讓 Wing 使用者不僅能看到預設模式中的元數據，還能看到底層 r0 表中的元資料。 （Cloudflare 博客）
建立功能清單的查詢沒有按資料庫名稱篩選；突然間，它開始從預設模式和 r0 表中取得重複列，導致功能行數翻倍。
功能檔案大小激增
Bot Management 模組對可接受的功能數量有硬性限制（設定為 200，遠高於通常使用的約 60 個）。
當新產生的檔案超過此限制時，由於 Rust 程式碼中對錯誤值使用了 Result::unwrap() 而導致未處理的錯誤，模組達到上限並崩潰。 （Cloudflare 博客）
核心代理服務開始回傳 5xx 錯誤
由於 Bot Management 整合到核心代理路徑中，因此任何依賴該模組的流量都會出現 HTTP 5xx 回應。
在新版 FL2 引擎上，客戶會看到明確的 5xx 錯誤。
在舊版 FL 引擎上，機器人評分會悄無聲息地降至零，這可能導致機器人攔截規則出現誤報。 （Cloudflare 博客）
更糟的是：該檔案的狀態在「正常」和「異常」之間不斷切換。
ClickHouse 叢集正在逐步更新，功能檔案每五分鐘重新產生一次。
有時查詢會在已更新的節點上執行（產生異常檔案），有時則會在未更新的節點上執行（產生正常檔案）。
這意味著，在一段時間內，由於不同版本的檔案不斷傳播，Cloudflare 的網路在正常運作和故障之間搖擺不定。 （Cloudflare 博客）
這種搖擺不定使得內部情況極度混亂。起初，Cloudflare 團隊懷疑遭受了大規模 DDoS 攻擊，因為錯誤模式看起來不像簡單的軟體崩潰。甚至託管在 Cloudflare 基礎設施之外的狀態頁面也短暫地顯示了錯誤——這一巧合進一步加深了他們對外部攻擊的懷疑。 Cloudflare 部落格 +1
只有當他們意識到共同因素是機器人功能檔案時，事情的真相才得以揭曉。
事件時間軸
根據 Cloudflare 的事後分析和第三方報告，我們可以大致梳理出 2025 年 11 月 18 日的活動時間軸：Cloudflare 部落格 +2 ThousandEyes +2
11:05 UTC – ClickHouse 中部署了資料庫存取控制變更。
11:20–11:30 UTC – 開始產生並傳播錯誤的機器人管理功能文件版本。
11:28 UTC – 首次影響客戶：客戶流量中出現大量 HTTP 5xx 錯誤。
11:30–11:32 UTC – 外部監控工具和自動化測試開始偵測到間歇性故障。
11:35 UTC – Cloudflare 發起內部事件通報；調查開始。
UTC 時間約 11:48 – Cloudflare 發布狀態更新，確認發生安全事件。重新發送
UTC 時間 11:30–13:05 – 團隊專注於 Workers KV 行為異常，並調查多種可能原因（包括攻擊場景）。
UTC 時間 13:05 – 關鍵緩解措施：Workers KV 和 Cloudflare Access 的流量被轉移，繞過核心代理；影響有所降低。 Cloudflare 部落格
UTC 時間 14:30 – 根本原因已確定；已停止產生和傳播錯誤功能檔。手動插入已知正常的配置文件，並重新啟動核心代理。大部分核心流量恢復正常。 Cloudflare 部落格
UTC 時間 14:40–15:30 – 由於 Turnstile 和積壓的身份驗證嘗試導致二次負載高峰，控制面板和登入問題仍然存在。 Cloudflare 部落格
UTC 時間 17:06 – 錯誤率恢復到基準水平；Cloudflare 宣告系統完全恢復正常。 Cloudflare 部落格
從使用者的角度來看，此次服務中斷在世界協調時 (UTC) 上午晚些時候到下午早些時候最為嚴重，但具體的影響時間因地區和各服務所依賴的 Cloudflare 產品而異。
此次服務中斷為何如此重要
中心化風險
Cloudflare 與主流雲端平台（AWS、Azure、GCP）和其他大型 CDN 供應商一起，屬於少數幾家中心化網路基礎設施供應商。當其中一家出現故障時，其影響範圍廣且往往不易察覺。
此次服務中斷：
並非由 BGP 路由故障或 ISP 電纜被切斷所引起。
並非由惡意攻擊引起（儘管最初有所懷疑）。
而是由內部組件中的單一配置和限制漏洞導致。
這一點至關重要，因為它表明，即使沒有外部幹擾，複雜且緊密耦合的系統也可能發生災難性故障。當許多組織都依賴同一服務提供者時，該提供者實際上就成為了互聯網中至關重要的系統性組成部分。
「軟性」依賴也造成了影響。
一些受影響的服務並非僅僅將 Cloudflare 用作簡單的 CDN。它們還：
使用 Cloudflare Access 進行驗證和零信任存取。
使用 Workers KV 作為內部控制平面的一部分。
依賴 Turnstile 實現防機器人登入。
當這些產品發生故障時，不僅網站內容會當機，登入、管理功能和內部 API 也會失效。這使得恢復過程更加複雜：您的狀態頁面、
事件處理工具或管理員使用者介面也可能依賴剛發生故障的相同服務提供者。
Cloudflare 表示會做出哪些改變
Cloudflare 的部落格概述了該公司正在採取的幾項補救措施，以降低類似事件再次發生的風險：Cloudflare 部落格
加強對自動產生設定檔的審核
對內部產生的配置採取與使用者提供的配置相同的謹慎態度和驗證措施，包括在部署前進行嚴格的架構和大小檢查。
更多全域終止開關
更容易快速地停用網路中存在問題的內部模組（例如 Bot Management），使其在故障時保持開放狀態，而不是導致整個代理路徑崩潰。
保護系統資源免受錯誤風暴的影響
確保在錯誤激增時，核心轉儲、調試元資料和可觀測性工具不會佔用過多 CPU 和記憶體。
審查核心代理模組的故障模式
系統地審核每個內部模組在意外輸入或配置下的行為，並確保優雅降級而不是全域故障。
優化部署和隔離
雖然沒有詳細說明，但此事件表明 Cloudflare 可能會進一步細化新配置和資料庫行為的傳播方式，以降低單一錯誤變更影響整個叢集的風險。
他們還將此次事件定性為對其彈性預期的徹底失敗，稱之為“不可接受的”，並明確承認此次事件給客戶和普通互聯網用戶帶來的困擾。 Cloudflare 部落格
對基礎設施和 SRE 團隊的啟示
即使您經營的並非像 Cloudflare 這樣龐大的服務，這次故障也蘊含著一些非常實用的設計與維運經驗：
將內部配置視為不可信的輸入
我們很容易想當然地認為「我們自己」產生的配置總是正確的。昨天的事件顯示了這種想法的危險性：
在套用設定檔之前，請務必驗證其大小、結構和限制。
考慮先對一小部分流量或節點進行金絲雀式配置部署，並在出現異常時自動回滾。
對功能數量、記憶體預先分配和 CPU 使用率設定嚴格的上限和熔斷機制。
設計優雅的部分故障處理機制
Bot 管理模組中的一個 bug 不應該導致整個代理程式路徑崩潰：
在某些安全層中，當完全中斷是另一種選擇時，預設使用故障開放（fail-open）而不是故障關閉（fail-closed）。
為非核心功能建立清晰且經過測試的終止開關。
確保關鍵子系統（驗證、狀態頁面、事件處理工具）能夠在降級模式下運作或透過備用路由運作。
觀察正確的訊號
每五分鐘在「良好配置」和「不良配置」之間來回切換，使得訊號看起來像是攻擊流量或異常的外部行為：
確保你的可觀測性管道中包含按版本或按配置的關聯資訊。
建立儀表板，使配置變更在錯誤圖表之上清晰可見。
包含來自外部視角的強綜合測試，以便快速區分內部故障和網路/路徑問題。
不要把所有雞蛋放在一個籃子裡
對於使用 Cloudflare 的組織：
對於真正關鍵的業務資產，請考慮採用多 CDN 設定。
避免將狀態頁面完全依賴與主堆疊相同的提供者（Cloudflare 就是這麼做的，但昨天他們的狀態頁面託管服務恰好出現問題，使情況更加複雜）。 Cloudflare 部落格 +1
在將身份驗證、API 控制平面和前端交付緊密耦合到同一供應商且沒有備用方案之前，請三思。
更宏觀的視角
僅在過去幾個月裡，我們就看到了 Microsoft Azure、Amazon Web Services 以及現在的 Cloudflare 的重大服務中斷，所有這些都導致大量消費者和企業服務暫時離線。美聯社 +2 華盛頓郵報 +2
趨勢很明顯：
網路越來越依賴少數幾家大型基礎設施供應商。
服務中斷通常是本身造成的，源自於複雜的內部變更，而不是外部攻擊。
即使是擁有世界一流 SRE 實踐的供應商，也可能因配置、資料庫行為和硬編碼限制之間意想不到的互動而陷入困境。
昨天的 Cloudflare 事件鮮明地提醒我們，「雲」並非魔法。歸根結底，它仍然是由人編寫的軟體，與其他任何應用程式一樣，都會出現各種類型的錯誤——只不過依賴它的用戶數量要多得多。
對於用戶而言，這次事件最有可能被記住的是「那天早上 X 和 ChatGPT 都無法加載」。
而對於工程師來說，它很可能會被當作一個教科書式的案例來研究，展現了核心分散式系統中細微的配置錯誤如何引發全球互聯網事件。
10566 
IT Pro 
