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

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

北京舉報

分享至

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

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

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ù)膰?yán)重故障。對于嘗試訪問我們客戶網(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ù)器上。

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

最初，我們誤以為所觀察到的癥狀是一場超大規(guī)模 DDoS 攻擊所致。后來，我們正確地識別出了問題的核心原因，并阻止了那個超出預(yù)期大小的特征文件繼續(xù)傳播，將其替換為之前的一個版本。到 14:30 時，我們的大部分核心流量已經(jīng)基本恢復(fù)正常。此后幾小時里，隨著流量回升，我們團(tuán)隊持續(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ò)有一段時間無法路由流量，這讓我們團(tuán)隊的每一名成員都深感痛心。我們知道，今天我們讓大家失望了。

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

故障概況

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

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

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

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

錯誤一直持續(xù)到 14:30，我們才找到根本原因并著手解決問題。我們通過停止生成和傳播錯誤的特征文件，并手動將一份已知良好的文件插入特征文件分發(fā)隊列來解決問題，隨后強(qiáng)制重啟了我們的核心代理。上圖中后面拖長的尾部曲線，代表我們的團(tuán)隊在逐步重啟那些進(jìn)入異常狀態(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 信譽(yù)數(shù)據(jù)源，導(dǎo)致垃圾郵件檢測準(zhǔn)確性降低，并使一些基于域名注冊時長的檢測未能觸發(fā)（未發(fā)現(xiàn)嚴(yán)重的客戶影響）。我們還觀察到部分自動移動操作（Auto Move）失敗；所有受影響的郵件均已過審查并得到處理。?Access：從故障開始到 13:05 回滾期間，大多數(shù)用戶的身份驗證嘗試都失敗了（已有的 Access 會話不受影響）。所有這些失敗的身份驗證嘗試都會出現(xiàn)錯誤頁面，這意味著故障期間這些用戶無法訪問其目標(biāo)應(yīng)用。而在此期間成功的登錄嘗試都已被正確記錄。嘗試在故障期間進(jìn)行的任何 Access 配置更新要么完全失敗，要么傳播非常緩慢；目前所有配置更新均已恢復(fù)正常。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在內(nèi)部事故聊天頻道中，我們擔(dān)心這可能是最近一系列高流量 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í)際存儲數(shù)據(jù)的地方。

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

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

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

上述改動使得所有用戶都可以獲取到其有權(quán)限訪問的表的準(zhǔ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ù)庫名稱進(jìn)行過濾。隨著我們逐步在該 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)限定了運(yùn)行時可使用的機(jī)器學(xué)習(xí)特征數(shù)量。目前該上限設(shè)置為 200，遠(yuǎn)高于我們當(dāng)前大約 60 個特征的使用量。再次強(qiáng)調(diào)，這個限制存在是出于性能考慮，我們會預(yù)先為這些特征分配內(nèi)存空間。

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

由此產(chǎn)生了如下所示的 panic 日志，進(jìn)而導(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 實(shí)施了補(bǔ)丁以使其繞過核心代理，從而降低了這些系統(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，當(dāng) Workers KV 繞過核心代理系統(tǒng)后，這些功能恢復(fù)了正常。第二個時間段的儀表盤可用性問題發(fā)生在恢復(fù)特征配置數(shù)據(jù)之后。大量積壓的登錄嘗試開始讓儀表盤不堪重負(fù)。這些積壓的請求結(jié)合用戶重試操作，導(dǎo)致了高延遲，儀表盤可用性下降。通過提升控制平面的并發(fā)處理能力，我們在大約 15:30 恢復(fù)了儀表盤的可用性。

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

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

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

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

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

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

時間

狀態(tài)

描述

11:05

正常

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

11:28

故障開始

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

11:32–13:05

調(diào)查進(jìn)行中

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