2025-11-18 Cloudflare 全球服務中斷事故調查報告

事件背景概述

2025 年 11 月 18 日 UTC 11:20 左右，Cloudflare 的全球網路出現嚴重故障，大量請求回傳 HTTP 500 錯誤，導致包括 X（Twitter）、ChatGPT、Spotify 等眾多網站無法存取。Cloudflare 事後確認這次中斷並非網路攻擊所致，而是源自 Bot Management 系統的一次例行更新失誤。問題由一項資料庫權限配置變更引發：該變更使資料庫在產生 Bot Management 用的「特徵檔案」時，意外重複輸出欄位，導致特徵檔案的條目數暴增一倍，檔案大小也超出預期 blog.cloudflare.com。這個特徵檔案原本每隔幾分鐘自動更新並推送至 Cloudflare 全網所有節點，以便快速應對新型機器人流量威脅 blog.cloudflare.com。然而，該檔案突然增大的內容超過了Bot Management模組軟體設定的上限（該模組預期最多 200 個特徵欄位，實際平時約 60 個） blog.cloudflare.com。結果，所有載入這份超大檔案的伺服器程序發生錯誤 panic 而崩潰，Cloudflare 核心代理無法正常路由流量，造成全球服務中斷 blog.cloudflare.com。

測試流程是否被跳過或不足

調查顯示，此次更新在發布前缺乏充分的測試驗證。上述資料庫權限變更（於當日 11:05 部署）在Bot Management功能上引入了一個潛在邏輯漏洞，但這在發布前未被傳統測試流程捕捉到 blog.cloudflare.com。Cloudflare 的 Bot Management 特徵檔案是由資料庫查詢自動生成，並頻繁（每幾分鐘）快速推送到全球各地機器 blog.cloudflare.com。由於更新頻率極高，Cloudflare並沒有針對每次特徵檔案更新進行完整的人工或長時間驗證流程，可能跳過了標準的階段性測試與發布審核。換言之，這類內部配置更新被視為例行且可信賴，未納入與應用程式代碼部署同等嚴格的測試管控。因此，在資料庫查詢邏輯存在隱患的情況下，新特徵檔案直接進入生產環境，未經預先的完整模擬測試就推送到所有節點。此次事件暴露出Cloudflare在該內部配置變更流程上的測試不足：原本隱性的錯誤假設（查詢結果僅包含預設資料庫的欄位）沒有透過測試發現並糾正，終於在這次變更中引爆 blog.cloudflare.com。

當次變更未被攔截的原因

該錯誤變更之所以未被及時攔截，主要因為缺乏自動化的安全檢查與守護機制：新生成的特徵檔案並沒有經過內容驗證或大小檢查就自動散佈到全網伺服器。Cloudflare 事後指出，他們此前對內部產生的配置檔案採取了信任態度，未像對待用戶輸入那樣進行嚴格校驗 blog.cloudflare.com。此次特徵檔案大小暴增超過軟體限制卻未被任何預發布檢驗攔截，導致有缺陷的配置直接部署，進而觸發系統崩潰 blog.cloudflare.com。實際上，Cloudflare 直到故障發生後才由監控系統發出警報：根據時間線記錄，第一個自動化測試警示在 11:31 出現，隨後工程團隊於 11:32 開始人工排查 blog.cloudflare.com。也就是說，配置變更已經推送且開始產生錯誤數分鐘後，內部監測才偵測到異常，並無更早的機制自動阻止這項有問題的更新。綜上所述，缺少預先的攔截手段（例如更新前在單一節點試運行驗證或檔案完整性檢查）使得這次有瑕疵的更新未被攔截便波及全球節點。

CI/CD、部署驗證機制與灰度發布的失效

此次事件凸顯了 Cloudflare 在持續交付和部署驗證上的多重機制缺口：

• CI/CD 測試流程：造成事故的直接誘因是一項在 ClickHouse 資料庫上的權限設定更新。該更新可能經由內部流程審核後部署，但相關的CI/CD測試未能涵蓋對 Bot Management 特徵檔案生成邏輯的影響，導致這一潛在缺陷潛伏未被發現 blog.cloudflare.com。換言之，在持續整合階段並沒有模擬這種資料庫查詢行為變化對下游系統的影響，測試覆蓋不足。例行的更新因缺少全面的回歸測試，帶入了未知的副作用。

• 部署後驗證：Cloudflare雖有基本的部署監控，但本次明顯缺乏部署前/立即部署後的自動驗證關卡。系統在 11:28 開始將錯誤配置分發至客戶流量路徑 blog.cloudflare.com，當時並未立刻停住更新。雖然11:31自動測試偵測到了問題 blog.cloudflare.com，但此時錯誤已經在全球範圍擴散。理想情況下，部署驗證機制應該在新配置發布瞬間進行健康檢查，發現異常立刻回滾。但此次這道防線未能發揮作用，新檔案上線後無人自動阻擋，導致問題持續擴大。

• 檔案大小限制機制：Bot Management 模組軟體內部雖然對特徵數量設定了上限（200 項）來預先配置記憶體 blog.cloudflare.com，但這屬於硬性限制而非柔性檢查。當特徵檔案超過該上限時，程式以 unwrap() error 的方式panic終止 blog.cloudflare.com，並未實作更溫和的錯誤處理或縮減措施。例如，並沒有機制在發布前檢測檔案大小並阻止超限部署，也沒有在超限時跳過加載或自動回退舊檔案的容錯設計。本質上，存在上限並不等同於有效的防呆：這次更新就是因為檔案超限直接引發崩潰，顯示出檔案大小限制機制的失效 blog.cloudflare.com。正如後來的分析所指出，如果當時有預先嘗試載入新檔案的測試或限制檢查，其實完全有足夠的時間在數分鐘內發現並阻止此錯誤更新 cyberpress.org。

• 灰度發布（漸進式部署）：Cloudflare針對這類特徵檔案更新沒有採用灰度或分階段發布。根據官方說明，這個特徵配置檔案為了快速應對不斷演變的惡意流量，需要頻繁且迅速地更新到全網，因此它每幾分鐘就整網同步一次 blog.cloudflare.com。這意味著 Cloudflare當時的設計決策是優先全域即時性，而未對此類更新使用逐步擴大範圍的發布策略（例如先在部分資料中心驗證後再推廣）。缺少灰度發布導致單點故障影響被立刻放大至全球：一份有問題的配置同時擊穿所有節點。如果有逐步發布機制，或許在少部分節點出現異常時就能及時止損。但很遺憾，該更新被一次性推向全網而沒有任何「先小規模驗證」的緩衝 blog.cloudflare.com。

綜上，從CI/CD測試到部署驗證，再到程式內建限制與發布策略，多道關卡在此次事件中都未能有效發揮作用，暴露出整個更新流程在變更驗證與故障緩和方面的不足 cyberpress.org。

官方反思與後續改進措施

Cloudflare 官方在事後的事故報告中對測試不足導致此次重大事故進行了深刻反思，並承諾了多項改進措施。Cloudflare CEO Matthew Prince 表示，像這樣導致核心流量中斷的事故是**「不可接受」**的，過去的每一次中斷都促使他們建構更健全的系統，此次也不例外 blog.cloudflare.com。針對這次事件暴露出的測試與流程問題，Cloudflare 列出了具體的改進方向：

• 強化內部配置檔案的驗證機制：未來將以對待使用者輸入同等嚴格的方式來驗證 Cloudflare 自行產生的配置檔案 blog.cloudflare.com。也就是說，像 Bot Management 特徵檔案這類內部更新，將新增內容校驗與安全檢查，防止未經充分測試的配置被推送。例如，加入自動檢驗檔案大小、結構合理性等，杜絕類似超限內容再次繞過驗證。

• 部署全域緊急開關（Kill Switch）：Cloudflare 將建立更多全球性的功能關閉開關 blog.cloudflare.com。一旦某項功能或配置在發布後被發現有問題，可以迅速一鍵停用或回退該功能在全網的影響，將損害控制在最小範圍。在本次事件中，團隊最終在14:24停止了新的特徵檔案發布並手動回復舊檔案 blog.cloudflare.com；未來有了快捷的全域停止開關，類似操作將能更快自動地進行。

• 改善錯誤處理與資源保護：報告提到將防止核心轉儲（core dump）或大量錯誤報告耗盡系統資源，以及全面檢討代理各模組的失敗模式 blog.cloudflare.com。這意味Cloudflare會審視核心軟體在異常情況下是否能優雅降級，例如未來若再遇到配置超限，程式應避免崩潰而是記錄錯誤並跳過，加強系統韌性。

Cloudflare 官方的這些聲明表明，他們已認識到此次事故中測試與發布流程的漏洞，並鄭重承諾將從中吸取教訓 cyberpress.org blog.cloudflare.com。透過引入更嚴格的內部檔案驗證、加強變更管控與緊急關閉機制，Cloudflare 希望確保未來即使出現未知軟體缺陷，也不會在未經察覺下被大規模推廣，從而避免類似全球性服務崩潰事件再度發生。Cloudflare 團隊對此次事故對客戶和整體網路生態造成的影響表示歉意，並重申將持續強化其基礎設施的可靠度，以履行對用戶的承諾 blog.cloudflare.com。

參考資料：

• Cloudflare 官方博客：「2025 年 11 月 18 日 Cloudflare 服務中斷」（事故分析與改進措施）blog.cloudflare.com

• CyberPress 資安新聞：「Cloudflare Shares Technical Breakdown of Major Internet Disruption」（事故技術細節與教訓）cyberpress.org

• Network World 專題報導：「How a bot management file push crippled Cloudflare’s global network」（事故起因與影響解讀）networkworld.com