Cloudflare outage on November 18, 2025
https://blog.cloudflare.com/18-november-2025-outage/
Matthew Prince
摘要整理：Google NotebookLM 中文化：Microsoft Copilot
Cloudflare 服務中斷事件簡介
Cloudflare 在 2025 年 11 月 18 日發生重大服務中斷，並隨後發布了詳細的事後檢討報告（post-mortem）。文件說明此次故障並非源自網路攻擊（cyber attack），而是由於內部設定錯誤（internal configuration error） 所致。具體原因是資料庫權限的變更，導致 Bot Management（機器人管理）功能檔案大小翻倍。由於負責 流量路由（traffic routing） 的軟體對該檔案有大小限制，最終引發系統 panic，並造成 Cloudflare 核心服務廣泛出現 HTTP 5xx 錯誤。
此次事件影響範圍包括：- 客戶網站 - Workers KV（Cloudflare 的分散式 key-value 儲存服務）- Cloudflare Access（零信任存取控制服務）
報告中詳細列出了事件的時間軸與修復步驟，最後以向客戶致歉作結，並承諾未來將加強 系統強化措施（system hardening measures），以避免類似事件再度發生。
▱▱▱▱▰▱▱▱▱
單一設定錯誤在 Cloudflare 核心服務中的連鎖效應是什麼？
這個源自資料庫權限變更的單一設定錯誤，引發了嚴重的連鎖性故障，影響 Cloudflare 的核心服務，根本性地衝擊了流量路由與客戶存取。
最初的設定錯誤導致功能檔案損毀，使 Bot Management（機器人管理）系統失效，造成以下主要的連鎖效應：
核心 Proxy 與流量故障
問題的核心在於 Cloudflare 核心 Proxy 系統（FL 與 FL2）上運行的 Bot Management 模組失敗：
1. 核心服務的 HTTP 5xx 錯誤：
核心 Proxy 系統（FL2）在嘗試載入超過 200 功能限制的過大功能檔案時，遇到未處理錯誤並發生 panic。這導致網際網路使用者在存取 Cloudflare 客戶網站時收到 HTTP 5xx 狀態碼。5xx 錯誤的激增顯示系統正在失效。
2. 廣泛的網路故障：
此次失敗導致 Cloudflare 網路在傳送核心流量時出現重大故障。在一段時間內，網路無法進行流量路由。
3. 延遲與除錯超載：
自動增補未捕捉錯誤的除錯與可觀測性過程消耗了大量 CPU，導致在影響期間 CDN 回應延遲顯著增加。
4. 波動性故障（初始階段）：
因為損壞的功能檔案每五分鐘才會在 更新過的ClickHouse 叢集部分查詢時生成，系統會時而恢復、時而再度失敗，隨機分發好或壞的設定檔案。這種波動最初使得原因不明確。
對下游服務的影響
核心 Proxy 的失敗直接影響依賴其運作的其他服務，特別是使用 FL Proxy 系統的服務：
1. Workers KV 降級：
Workers KV 因「前端」閘道請求因核心 Proxy 失敗而無法處理，返回顯著升高的 HTTP 5xx 錯誤。團隊最初觀察到的症狀是 Workers KV 回應率下降，進而影響其他 Cloudflare 服務。
(1) 緩解措施：在 13:05 UTC 實施繞過機制，使 Workers KV 回退至核心 Proxy 的先前版本或完全繞過核心 Proxy，降低了影響。
2. Cloudflare Access 認證失敗：
Cloudflare Access 在大多數使用者中出現廣泛的認證失敗。此故障自事件開始即發生，並持續到 13:05 UTC 回滾為止。
(1) 所有失敗的認證嘗試都返回錯誤頁面，使用者無法存取目標應用程式。
(2) 在此期間嘗試的設定更新要麼完全失敗，要麼傳播極為緩慢。
(3) 在 Workers KV 繞過機制實施後，Access 的錯誤率有所下降。
3. Dashboard 影響：
Cloudflare Dashboard 受影響，因為它內部使用 Workers KV，並需要 Cloudflare Turnstile 進行登入。
(1) 大多數使用者無法登入，因為登入頁面上的 Turnstile 無法使用。
(2) Dashboard 出現兩次可用性下降，第一次是由於 Workers KV 的影響。
4. Turnstile 故障：
Turnstile 產品無法載入。
對 Bot Management（舊版 Proxy）的影響
部署在新 FL2 Proxy 的客戶看到 HTTP 5xx 錯誤，而使用舊版 Proxy 引擎（FL）的客戶則出現不同的故障模式：
FL 上的誤判：
舊 FL Proxy 的客戶雖未見錯誤，但 Bot 分數未正確生成，導致所有流量的 Bot 分數為零。這使得部署了阻擋 Bot 規則的客戶出現大量誤判。
其他系統
電子郵件安全：雖然郵件處理與投遞未受影響，但觀察到暫時失去存取 IP 信譽來源，降低了垃圾郵件偵測準確度，並阻止部分新註冊網域年齡偵測觸發。一些自動搬移（Auto Move）動作也發生故障，但受影響的郵件已被檢視並修復。
狀態頁巧合：雖與內部設定錯誤無關，但 Cloudflare 的狀態頁（完全託管於 Cloudflare 基礎設施之外）也發生故障。這一巧合使部分團隊成員最初懷疑遭遇超大規模 DDoS 攻擊，同時針對內部系統與狀態頁。
總結
核心設定錯誤損毀了一個檔案，當該檔案載入 Proxy 的專用 Bot Management 模組時，觸發了災難性的故障模式（因觸及記憶體預配置限制而 panic），最終中斷了核心客戶流量，並對依賴核心 Proxy 健康度的服務（如 Workers KV 與 Access）造成重大連鎖影響。
▱▱▱▱▰▱▱▱▱
資料庫權限變更如何直接導致 Bot Management 系統失敗？
資料庫權限的變更，透過一連串涉及關鍵設定檔生成的事件，直接導致了 Bot Management 系統的失敗。
以下是逐步的因果鏈：
1. 權限變更：在 11:05 UTC 部署了一項變更，目的是提升分散式查詢的安全性與可靠性，讓使用者能夠明確存取 `r0` 資料庫中的底層資料表。此前，這些使用者在查詢資料表中繼資料時，只能看到 `default` 資料庫中的資料表。
2. 非預期的查詢行為：此變更意味著在查詢系統資料表時，使用者現在可以存取所有他們有權限的資料表的正確中繼資料，包括 `r0` schema 中的資料表。Bot Management 功能檔案生成邏輯使用了一個特定查詢：
SELECT name, type FROM system.columns WHERE table = 'http_requests_features' order by name;
不幸的是，這個查詢並未過濾資料庫名稱。
3. 產生重複項目：在權限變更後，該查詢開始返回欄位的「重複項目」，因為它包含了儲存在 `r0` 資料庫中的底層資料表的中繼資料。回應因此包含了 `r0` schema 的所有中繼資料，實際上使回應中的列數增加一倍以上。
4. 功能檔案損毀與過大：這些重複資料成為 Bot Management 功能設定檔的輸入「features」。資料庫權限的變更導致資料庫輸出多筆（重複的「feature」列）到該檔案。結果，功能檔案大小翻倍，並包含超過 200 個 features。
5. 因限制而失敗：這個超出預期大小的功能檔案被傳播到 Cloudflare 網路上的所有機器。處理 Bot Management 的軟體元件（特別是核心 Proxy 系統上的 FL2 Rust 程式碼）為了效能最佳化，設有預先分配的記憶體限制。該系統限制為 200 個機器學習 features。當軟體嘗試載入超過此限制的錯誤檔案時，系統觸及限制並發生 panic。
6. 中斷症狀：這次 panic 導致未處理錯誤，進而使核心 Proxy 系統針對依賴 bots 模組的流量返回 5xx 錯誤碼。
比喻說明：
想像一位廚師（功能檔案生成邏輯）有一張食譜卡（查詢），列出食材（features），假設它們只存在於一個標記的儲藏室（`default` 資料庫）。當第二個儲藏室（`r0` 資料庫）的鑰匙被明確給予（權限變更），廚師閱讀食譜卡時同時看到兩個儲藏室的指示，列出了兩倍的食材。當廚師嘗試用烤箱（預分配記憶體）烹調這道菜（核心 Proxy 模組），而烤箱僅設計用於較少的食材時，烤箱因輸入過大而 panic 並失敗。
▱▱▱▱▰▱▱▱▱
Cloudflare 為防止未來系統性中斷所實施的具體修復步驟
Cloudflare 正在實施多項具體的修復措施與後續行動，以強化系統抵禦未來的故障，特別是源自設定錯誤的問題，如本次中斷事件。
規劃中的修復步驟與未來系統強化措施包括：
1. 強化設定檔匯入流程：
Cloudflare 將專注於強化內部生成的設定檔匯入流程，並以對待使用者輸入同等的謹慎態度來處理。此舉旨在防止損毀或過大的檔案被載入核心系統。
2. 啟用全域 Kill Switch（緊急停用開關）：
正在推動更多全域 Kill Switch 功能，使團隊能快速停用整個網路中的問題功能，以迅速緩解中斷。
3. 消除錯誤回報過載：
Cloudflare 正在努力消除核心傾印（core dump）或其他錯誤回報壓垮系統資源的可能性。在事件期間，除錯與可觀測性系統自動增補未捕捉錯誤，消耗了大量 CPU，顯著增加延遲。
4. 檢視故障模式：
團隊正在檢視所有核心 Proxy 模組的錯誤狀況故障模式，目的是主動識別並解決可能導致未處理 panic 或系統失敗的情境，例如 Bot Management 系統觸及預分配記憶體限制的情況。
Cloudflare 強調，這份清單只是計畫的起點，目的是確保未來不會再發生如此規模的中斷。公司指出，任何中斷在 Cloudflare 作為網際網路生態系統重要基礎設施的角色下都是不可接受的。過去每一次中斷都促使新、更具韌性的系統誕生。
理解強化設定檔匯入的必要性：
可以將設定檔生成過程想像成工廠的生產線：過去，如果工廠的內部機械（資料庫查詢）開始產出雙倍大小的零件（功能檔案），品質控管（匯入邏輯）就假設輸入是有效的。新的修復步驟相當於在生產線上安裝強大的過濾器與掃描器，立即拒絕任何過大或損毀的零件，以免破壞最終產品（核心 Proxy 模組）。
留言
張貼留言