網易首頁 > 網易號 > 正文申請入駐

Cloudflare 11-18 斷網故障復盤報告

2025-11-19 10:22:52　來源: 老馮云數

北京舉報

分享至

就在昨天，有 “賽博佛祖” 之稱的 Cloudflare 遭遇自 2019 年以來的最嚴重故障 —— 正常的核心網絡流量無法傳輸，長達六個小時。 ChatGPT、X（前 Twitter）、Spotify、Uber 等知名服務悉數中招。故障的根因是修改了 ClickHouse 的權限，導致生成的反爬特征太大，撐爆了路由網絡流量的軟件的限制。

Cloudflare 團隊今天早上在其博客發布了故障復盤文章[1]，老馮將其翻譯為中文，并附上點評。

Cloudflare 2025年11月18日服務中斷

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

2025年11月18日11:20 UTC（本文所有時間均為 UTC），Cloudflare 的網絡開始出現核心網絡流量傳輸的嚴重故障。對于嘗試訪問我們客戶網站的 Internet 用戶而言，這種故障表現為一個錯誤頁面，提示 Cloudflare 網絡內部發生了故障。

此次問題并非由任何形式的網絡攻擊或惡意活動直接或間接導致。相反，起因是我們一個數據庫系統的權限更改，導致該數據庫將多個條目輸出到了我們的 Bot 管理系統所使用的一個“特征文件”中。該特征文件的大小因此翻了一倍。這個超出預期大小的特征文件隨后被分發到構成我們網絡的所有服務器上。

運行在這些服務器上的軟件（用于在我們的網絡中路由流量）會讀取這個特征文件，以使我們的 Bot 管理系統能夠應對不斷變化的威脅。該軟件對特征文件的大小設有一個上限，而這個上限低于特征文件翻倍后的大小，導致軟件發生了故障。

最初，我們誤以為所觀察到的癥狀是一場超大規模 DDoS 攻擊所致。后來，我們正確地識別出了問題的核心原因，并阻止了那個超出預期大小的特征文件繼續傳播，將其替換為之前的一個版本。到 14:30 時，我們的大部分核心流量已經基本恢復正常。此后幾小時里，隨著流量回升，我們團隊持續努力減輕網絡各部分面臨的過載問題。截至 17:06，Cloudflare 的所有系統均已恢復正常。

我們對本次事件給客戶和整個 Internet 帶來的影響深表歉意。鑒于 Cloudflare 在互聯網生態系統中的重要性，我們的任何系統發生中斷都是不可接受的。而我們的網絡有一段時間無法路由流量，這讓我們團隊的每一名成員都深感痛心。我們知道，今天我們讓大家失望了。

本文將深入詳述事件的經過，以及哪些系統和流程出現了故障。這也是我們開始著手采取行動以確保類似中斷不再發生的起點（但絕非結束）。

故障概況

下圖顯示了 Cloudflare 網絡返回的 HTTP 5xx 錯誤狀態碼數量。正常情況下，這個值應當非常低，事實在故障開始前也是如此。

在 11:20 之前，5xx 錯誤數量保持在我們預期的基線水平。之后的激增及隨后的波動表明，由于加載了錯誤的特征文件，我們的系統發生了故障。有一點值得注意：我們的系統隨后一度自行恢復正常過一段時間——對于內部錯誤而言，這種現象非常不尋常。

原因在于，這個文件每隔五分鐘由一個在 ClickHouse 數據庫集群上運行的查詢生成，而該集群當時正在逐步更新以改進權限管理。只有當查詢在已更新的集群節點上運行時，才會生成錯誤數據。因此，每隔五分鐘，就有可能生成一套正確的或錯誤的配置文件，并迅速傳播到整個網絡。

這種波動使我們難以及時判斷發生了什么，因為整個系統會先恢復正常，然后在下一次分發配置文件時（有時文件正確、有時文件錯誤）再次發生故障。起初，這讓我們認為故障可能是由攻擊造成的。最終，當每個 ClickHouse 節點都開始生成錯誤的配置文件后，系統波動停止并穩定地處于故障狀態。

錯誤一直持續到 14:30，我們才找到根本原因并著手解決問題。我們通過停止生成和傳播錯誤的特征文件，并手動將一份已知良好的文件插入特征文件分發隊列來解決問題，隨后強制重啟了我們的核心代理。上圖中后面拖長的尾部曲線，代表我們的團隊在逐步重啟那些進入異常狀態的服務；到 17:06 時，5xx 錯誤數量已恢復正常。

以下服務受到了影響：

?核心CDN與安全服務：返回 HTTP 5xx 狀態碼。（本文開頭的截圖展示了終端用戶看到的典型錯誤頁面。）?Turnstile：無法加載。?Workers KV：出現了顯著升高的 HTTP 5xx 錯誤率，因為對 Workers KV “前端”網關的請求由于核心代理故障而失敗。?Dashboard：儀表盤基本保持可用，但由于登錄頁面上的 Turnstile 無法使用，大多數用戶無法登錄。?Email安全：雖然郵件處理和傳遞未受影響，但我們觀察到一度無法訪問某個 IP 信譽數據源，導致垃圾郵件檢測準確性降低，并使一些基于域名注冊時長的檢測未能觸發（未發現嚴重的客戶影響）。我們還觀察到部分自動移動操作（Auto Move）失敗；所有受影響的郵件均已過審查并得到處理。?Access：從故障開始到 13:05 回滾期間，大多數用戶的身份驗證嘗試都失敗了（已有的 Access 會話不受影響）。所有這些失敗的身份驗證嘗試都會出現錯誤頁面，這意味著故障期間這些用戶無法訪問其目標應用。而在此期間成功的登錄嘗試都已被正確記錄。嘗試在故障期間進行的任何 Access 配置更新要么完全失敗，要么傳播非常緩慢；目前所有配置更新均已恢復正常。

除了返回 HTTP 5xx 錯誤，我們還觀察到在故障影響期間 CDN 響應的延遲顯著增加。這是因為我們的調試和可觀測性系統消耗了大量 CPU 資源——它們會在未捕獲的錯誤中自動附加額外的調試信息。

Cloudflare 請求處理流程及本次故障原因

每個發往 Cloudflare 的請求都會沿著我們網絡中一條明確的路徑進行處理。請求可能來自加載網頁的瀏覽器、調用 API 的移動應用，或者來自其他服務的自動化流量。這些請求首先終止于我們的 HTTP 和 TLS 層，然后流入我們的核心代理系統（我們稱之為 FL，即 “Frontline”），最后經由 Pingora 執行緩存查找，或在需要時從源站獲取數據。

我們曾在這里更詳細地介紹過核心代理的工作原理[3]。

當請求通過核心代理時，我們會運行網絡中提供的各種安全和性能產品。核心代理根據每個客戶的特定配置和設置處理流量，從執行 WAF 規則、防御 DDoS 攻擊，到將流量路由到開發者平臺和 R2 等。這一過程通過一系列特定領域的模塊實現，這些模塊對經過代理的流量應用相應的配置和策略規則。

這些模塊中的一個 —— Bot 管理模塊，正是此次故障的源頭。

Cloudflare 的 Bot管理系統[4] 包含多個子系統，其中包括一個機器學習模型，我們用它為經過我們網絡的每個請求生成“機器人分數”。客戶可以使用這個分數來控制哪些機器人被允許訪問他們的網站，哪些則不被允許。

該模型使用一個“特征”配置文件作為輸入。在這里，“特征”是指機器學習模型用來判斷請求是否由自動程序發出的單個屬性。特征配置文件是由各個獨立的特征組合而成的集合。

這個特征文件每隔幾分鐘就會刷新并發布到我們整個網絡上，使我們能夠對 Internet 上不斷變化的流量模式作出響應。它讓我們能夠應對新型的機器人以及新的機器人攻擊。因此，需要頻繁且快速地發布該文件，因為惡意行為者往往很快改變策略。

在生成該文件的底層 ClickHouse 查詢行為發生變化（詳見下文）后，文件中出現了大量重復的“特征”行。這使得原本固定大小的特征配置文件變得比預期更大，導致 Bot 模塊觸發了錯誤。

結果是，核心代理在處理任何依賴 Bot 模塊的流量時都會返回 HTTP 5xx 錯誤。這也影響到了依賴核心代理的 Workers KV 和 Access。

需要指出的是，我們當時正在將客戶流量遷移到新版代理服務（內部稱為 FL2[5]）。舊版和新版代理引擎都受到了這一問題的影響，盡管表現出的影響有所不同。

使用新 FL2 代理引擎的客戶遇到了 HTTP 5xx 錯誤。而使用舊版代理（FL）的客戶雖然沒有看到錯誤，但機器人分數未能正確生成，所有流量的機器人分數都變成了零。那些基于機器人分數設置了封禁規則的客戶會遇到大量誤判；未在規則中使用機器人分數的客戶則沒有受到影響。

還有一個現象最初使我們誤以為遇到了攻擊：Cloudflare 的狀態頁也發生了故障。狀態頁完全托管在 Cloudflare 基礎設施之外，與 Cloudflare 系統沒有任何依賴關系。雖然事后證明這只是一個巧合，但它使得部分診斷團隊成員一度認為攻擊者可能同時針對了我們的系統和狀態頁。在那段時間訪問狀態頁的用戶會看到如下的錯誤信息：

在內部事故聊天頻道中，我們擔心這可能是最近一系列高流量 Aisuru DDoS 攻擊[6] 的延續：

查詢行為的變化

正如前文提到的，底層查詢行為的更改導致特征文件中包含了大量重復行。此處涉及的數據庫系統使用的是 ClickHouse 軟件。

這里有必要說明一下 ClickHouse 分布式查詢是如何工作的：一個 ClickHouse 集群由許多分片組成。為了從所有分片查詢數據，我們在名為 default 的數據庫中使用所謂的分布式表（由 Distributed 表引擎提供支持）。 Distributed 引擎會查詢名為 r0 的數據庫中的底層表；這些底層表是每個分片上實際存儲數據的地方。

對分布式表的查詢是通過一個共享的系統賬戶執行的。作為提高分布式查詢安全性和可靠性工作的其中一環，我們正在努力使這些查詢改為在初始用戶賬戶下運行。

在今天之前，當從 ClickHouse 的系統表（如 system.tables 或 system.columns）查詢表的元數據時，用戶只能看到 default 數據庫中的表。

由于用戶已經隱含擁有對 r0 數據庫中底層表的訪問權限，我們在 11:05 進行了改動，將這種訪問權限顯式化，以便用戶也能看到這些表的元數據。通過確保所有分布式子查詢都在初始用戶上下文中運行，我們可以更細粒度地評估查詢限制和訪問授權，從而避免某個用戶的異常子查詢影響到其他用戶。

上述改動使得所有用戶都可以獲取到其有權限訪問的表的準確元數據。不幸的是，此前有些代碼假定這類查詢返回的列列表只會包含 “default” 數據庫下的內容。例如下面的查詢并沒有按數據庫名過濾：

SELECT name, type
FROM system.columns
WHERE table = 'http_requests_features'
ORDER BY name;

注意，上述查詢并未按數據庫名稱進行過濾。隨著我們逐步在該 ClickHouse 集群上推出顯式授權，上述查詢在 11:05 的改動后開始返回列的“重復”，因為結果中包含了存儲在 r0 數據庫中底層表的列。

不巧的是，Bot 管理特征文件的生成邏輯執行的正是上述類型的查詢來構建文件中的每一個“特征”。

上述查詢會返回一個類似下表所示的列清單（示例經過簡化）：

然而，由于給用戶授予了額外的權限，查詢結果現在包含了 r0 模式下的所有相關元數據，有效地使響應行數增加了一倍多，最終導致輸出文件中的特征數量大大超出正常范圍。

內存預分配

我們的核心代理服務中的每個模塊都設置了一些上限，以防止內存無限增長，并通過預分配內存來優化性能。在本例中，Bot 管理系統限定了運行時可使用的機器學習特征數量。目前該上限設置為 200，遠高于我們當前大約 60 個特征的使用量。再次強調，這個限制存在是出于性能考慮，我們會預先為這些特征分配內存空間。

當包含超過 200 個特征的錯誤文件被傳播到我們的服務器時，這一限制被觸發——系統因此發生了 panic。下面的 FL2（Rust）代碼片段顯示了執行該檢查并導致未處理錯誤的部分：

由此產生了如下所示的 panic 日志，進而導致了 5xx 錯誤：

thread fl2_worker_thread panicked: called Result::unwrap() on an Err value

故障期間的其他影響

在此次事故中，其他依賴我們核心代理的系統也受到了影響，包括 Workers KV 和 Cloudflare Access。在 13:04，我們對 Workers KV 實施了補丁以使其繞過核心代理，從而降低了這些系統所受的影響。此后，所有依賴 Workers KV 的下游系統（例如 Access 本身）的錯誤率都降低了。

Cloudflare 儀表盤（Dashboard）也受到了影響，因為儀表盤內部使用了 Workers KV，且我們的登錄流程中部署了 Cloudflare Turnstile。

這次中斷也影響了 Turnstile：對于沒有活躍儀表盤會話的用戶，他們在事故期間無法登錄。儀表盤的可用性在兩個時間段內下降：11:30 至 13:10，以及 14:40 至 15:30（如下圖所示）。

第一個時間段（11:30 至 13:10）的可用性下降是由于 Workers KV 受到了影響——一些控制平面和儀表盤功能依賴于 Workers KV。在 13:10，當 Workers KV 繞過核心代理系統后，這些功能恢復了正常。第二個時間段的儀表盤可用性問題發生在恢復特征配置數據之后。大量積壓的登錄嘗試開始讓儀表盤不堪重負。這些積壓的請求結合用戶重試操作，導致了高延遲，儀表盤可用性下降。通過提升控制平面的并發處理能力，我們在大約 15:30 恢復了儀表盤的可用性。

補救措施和后續步驟

現在，我們的系統已經恢復正常運行，我們已經開始著手研究如何在未來加強系統抵御類似故障的能力。具體來說，我們將：

?像對待用戶生成的輸入那樣，強化對 Cloudflare 內部生成的配置文件的攝取和校驗；?為功能啟用更多全局性的緊急開關；?消除核心轉儲或其他錯誤報告占用過多系統資源的可能性；?審查所有核心代理模塊在錯誤情況下的失效模式。

今天的事故是 Cloudflare 自 2019 年以來最嚴重的一次中斷。我們過去也出現過讓儀表盤無法使用的停機，還有一些導致較新功能暫時不可用的故障。但在過去超過 6 年的時間里，我們沒有再出現過讓大部分核心流量停止的中斷。

像今天這樣的中斷是不可接受的。我們在架構設計上讓系統具備高度的容錯能力，以確保流量始終可以繼續傳輸。每次過去發生故障后，我們都會據此構建新的、更可靠的系統。

我謹代表 Cloudflare 全體團隊，對我們今天給互聯網帶來的影響表示誠摯的歉意。

時間

狀態

描述

11:05

正常

數據庫訪問控制更改已部署。

11:28

故障開始

新配置部署到客戶環境，在客戶的 HTTP 流量中首次觀察到錯誤。

11:32–13:05

調查進行中

團隊調查了 Workers KV 服務流量和錯誤率升高的問題。初始癥狀表現為 Workers KV 響應速度下降，導致 Cloudflare 其他服務受到下游影響。團隊嘗試通過流量調整和賬戶限制等措施使 Workers KV 恢復正常。11:31 自動測試首次檢測到問題，11:32 開始人工調查，并在 11:35 發起了事故會議。