Cloudflare 11-18 斷網(wǎng)故障復(fù)盤報告

2025-11-19 10:22:52　來源: 老馮云數(shù)

北京舉報

分享至

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

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

Cloudflare 2025年11月18日服務(wù)中斷

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

2025年11月18日11:20 UTC（本文所有時間均為 UTC），Cloudflare 的網(wǎng)絡(luò)開始出現(xiàn)核心網(wǎng)絡(luò)流量傳輸?shù)膰乐毓收稀?對于嘗試訪問我們客戶網(wǎng)站的 Internet 用戶而言，這種故障表現(xiàn)為一個錯誤頁面，提示 Cloudflare 網(wǎng)絡(luò)內(nèi)部發(fā)生了故障。

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

運行在這些服務(wù)器上的軟件（用于在我們的網(wǎng)絡(luò)中路由流量）會讀取這個特征文件，以使我們的 Bot 管理系統(tǒng)能夠應(yīng)對不斷變化的威脅。該軟件對特征文件的大小設(shè)有一個上限，而這個上限低于特征文件翻倍后的大小，導(dǎo)致軟件發(fā)生了故障。

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

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

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

故障概況

下圖顯示了 Cloudflare 網(wǎng)絡(luò)返回的 HTTP 5xx 錯誤狀態(tài)碼數(shù)量。正常情況下，這個值應(yīng)當非常低，事實在故障開始前也是如此。

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

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

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

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

以下服務(wù)受到了影響：

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

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

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

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

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

當請求通過核心代理時，我們會運行網(wǎng)絡(luò)中提供的各種安全和性能產(chǎn)品。核心代理根據(jù)每個客戶的特定配置和設(shè)置處理流量，從執(zhí)行 WAF 規(guī)則、防御 DDoS 攻擊，到將流量路由到開發(fā)者平臺和 R2 等。這一過程通過一系列特定領(lǐng)域的模塊實現(xiàn)，這些模塊對經(jīng)過代理的流量應(yīng)用相應(yīng)的配置和策略規(guī)則。

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

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

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

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

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

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

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

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

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

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

查詢行為的變化

正如前文提到的，底層查詢行為的更改導(dǎo)致特征文件中包含了大量重復(fù)行。此處涉及的數(shù)據(jù)庫系統(tǒng)使用的是 ClickHouse 軟件。

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

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

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

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

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

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

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

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

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

然而，由于給用戶授予了額外的權(quán)限，查詢結(jié)果現(xiàn)在包含了 r0 模式下的所有相關(guān)元數(shù)據(jù)，有效地使響應(yīng)行數(shù)增加了一倍多，最終導(dǎo)致輸出文件中的特征數(shù)量大大超出正常范圍。

內(nèi)存預(yù)分配

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

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

由此產(chǎn)生了如下所示的 panic 日志，進而導(dǎo)致了 5xx 錯誤：

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

故障期間的其他影響

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

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

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

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

補救措施和后續(xù)步驟

現(xiàn)在，我們的系統(tǒng)已經(jīng)恢復(fù)正常運行，我們已經(jīng)開始著手研究如何在未來加強系統(tǒng)抵御類似故障的能力。具體來說，我們將：

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

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

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

我謹代表 Cloudflare 全體團隊，對我們今天給互聯(lián)網(wǎng)帶來的影響表示誠摯的歉意。

時間

狀態(tài)

描述

11:05

正常

數(shù)據(jù)庫訪問控制更改已部署。

11:28

故障開始

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

11:32–13:05

調(diào)查進行中

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