2025年11月28日-Cloudflare史詩級事故:一次配置失誤，引爆全球宕機

2025年11月28日-Cloudflare史詩級事故:一次配置失誤，引爆全球宕機 前言

繼今年10月19號亞馬遜云AWS的 us-east-1的大故障，導致美國一半的線上服務不可用，波及到全球用戶。

2025 年 10 月 29 日，，持續近 9 小時。受影響的不僅包括微軟自家核心服務（Office 365、Xbox Live、Copilot 等），還波及航空、醫療、零售等多個行業。

“不甘寂寞”的Cloudflare人稱賽博活佛CF也出事故了！

2025年11月18日，Cloudflare 發生了一次堪稱“史詩級”的全球宕機。作為全球最大的 CDN 與安全服務提供商之一，它的服務覆蓋了數百萬網站和應用。這次事故直接導致全球范圍的訪問異常，用戶看到的不是網頁，而是熟悉的 Cloudflare 錯誤頁。

官方承認，這是自 2019 年以來最嚴重的一次宕機。

一、事故概述

2025 年 11 月 18 日 11:20 UTC，Cloudflare 全球網絡爆發大規模故障，核心流量交付功能出現嚴重異常，用戶訪問其客戶網站時普遍收到 HTTP 5xx 系列錯誤（主要為 500 內部服務器錯誤）。此次故障并非由網絡攻擊或任何惡意行為導致，系內部數據庫配置變更引發的連鎖反應，是 Cloudflare 自 2019 年以來最嚴重的一次服務中斷事件。

故障發生后，技術團隊啟動緊急響應，14:30 核心流量基本恢復正常，17:06 所有受影響服務完全恢復穩定運行。期間多個核心產品及服務受到不同程度影響，對廣大客戶及全球互聯網訪問體驗造成了負面影響，Cloudflare 官方已就此公開致歉。

二、影響范圍

云服務、內容分發網絡（CDN）和安全服務中斷，導致包括 ChatGPT、X（原 Twitter）、Spotify、游戲服務、零售商及公共交通系統在內的多個大型網站和應用出現訪問失敗或 5xx 系列錯誤。

幾乎所有依賴 Cloudflare 服務的平臺都受到了波及。

（一）核心 CDN 與安全服務

直接返回 HTTP 5xx 錯誤碼，用戶無法正常訪問依賴 Cloudflare CDN 加速及安全防護的網站，頁面顯示 Cloudflare 網絡內部故障提示。

（二）Turnstile 服務

完全無法加載，導致依賴該服務進行驗證的場景出現功能中斷。

（三）Workers KV

核心代理故障引發其前端網關請求失敗，HTTP 5xx 錯誤率顯著升高，功能可用性大幅下降。

（四）管理后臺（Dashboard）

雖主體功能未完全中斷，但由于登錄頁面集成的 Turnstile 服務不可用，多數用戶無法正常登錄；后續恢復階段因登錄請求積壓及重試機制，出現 latency 升高問題。

（五）郵件安全（Email Security）

郵件處理與交付未受影響，但暫時丟失部分 IP 信譽數據源，導致垃圾郵件檢測準確性下降，部分新域名年齡檢測功能失效；部分自動轉移（Auto Move）操作失敗，相關郵件已完成復核與修復。

（六）Access 服務

11:20 起多數用戶出現認證失敗，無法訪問目標應用，已建立的有效會話不受影響；故障期間的認證失敗均記錄在案，配置更新操作要么直接失敗，要么傳播速度極慢，后續已完全恢復。

此外，故障期間 Cloudflare CDN 響應延遲顯著增加，原因是調試與可觀測性系統消耗大量 CPU 資源，用于收集未捕獲錯誤的額外調試信息。

三、應急措施

1. 1. 故障初期啟動多維度排查，快速排除 DDoS 攻擊等外部因素，鎖定內部服務異常。

2. 2. 針對 Workers KV 和 Access 服務啟用旁路機制，繞開故障核心代理，快速降低關鍵服務影響范圍。

3. 3. 定位特征文件異常后，立即停止異常文件的生成與傳播，避免故障進一步擴散。

4. 4. 全球部署經驗證的歷史正常特征文件，強制重啟核心代理服務，修復核心流量處理鏈路。

5. 5. 恢復階段擴容控制平面并發能力，處理登錄請求積壓問題，修復剩余異常服務實例。

四、補救和后續步驟

現在我們的系統已恢復正常運行，我們已經開始著手研究如何加強系統，以防止未來再次發生類似故障。具體來說，我們正在：

• ? 加強對 Cloudflare 生成的配置文件的攝取，就像我們加強對用戶生成輸入的攝取一樣。

• ? 為功能啟用更多全局終止開關

• ? 消除核心轉儲或其他錯誤報告占用系統資源的可能性

• ? 審查所有核心代理模塊的錯誤情況故障模式

時間（UTC）

地位

描述

11:05

普通的。

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

11:28

沖擊開始。

部署到達客戶環境后，在客戶 HTTP 流量中首次發現錯誤。

11:32-13:05

該團隊調查了 Workers KV 服務流量異常增加和故障情況。

最初的癥狀似乎是 Workers KV 響應速率下降，導致對其他 Cloudflare 服務產生下游影響。 為了使 Workers KV 服務恢復到正常運行水平，我們嘗試了流量控制和賬戶限制等緩解措施。 第一次自動化測試于 11:31 檢測到問題，人工調查于 11:32 開始。事件報告于 11:35 創建。

13:05

已實施 Workers KV 和 Cloudflare Access 繞過措施——影響已降低。

調查期間，我們對 Workers KV 和 Cloudflare Access 使用了內部系統繞過機制，使其回退到我們核心代理的舊版本。雖然該問題在之前的代理版本中也存在，但影響較小，具體情況如下所述。

13:37

工作重點是將 Bot 管理配置文件回滾到最后一個已知良好的版本。

我們確信是機器人管理配置文件引發了此次事件。團隊分多個工作流程開展工作，尋找修復服務的方法，其中最快的方案是恢復該文件的先前版本。

14:24

已停止創建和傳播新的機器人管理配置文件。

我們發現 Bot Management 模塊是導致 500 錯誤的根源，而這又是由錯誤的配置文件引起的。我們已停止自動部署新的 Bot Management 配置文件。

14:24

新文件測試完成。

我們觀察到使用舊版本的配置文件可以成功恢復，然后集中精力加快全球修復速度。

14:30

主要影響已解決。下游受影響的服務開始出現錯誤減少的情況。

正確的機器人管理配置文件已在全球范圍內部署，大多數服務開始正常運行。

17:06

所有服務已恢復正常。影響已結束。

所有下游服務已重啟，所有操作已完全恢復。

官方事故報告

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


 Cloudflare System Status： https://www.cloudflarestatus.com/

1. 1. 出了啥事？ 在那天，Cloudflare的網絡掛了，導致很多網站都訪問不了，顯示5xx錯誤。

2. 2. 為啥掛了？ 這次不是被黑客攻擊了，而是他們自己的一個技術問題。起因是他們改了一個數據庫的權限，結果導致一個給“機器人管理”系統用的配置文件大小翻了一倍。

3. 3. 技術細節： 他們系統里有個軟件要讀取這個配置文件，但是這個軟件對文件大小有限制。結果這個超大的文件被推送到全網的服務器上，直接把軟件干趴下了，然后就各種報錯。

4. 4. 咋解決的？ 工程師們一開始還以為是DDoS攻擊，后來才找到真正原因。他們停止了那個錯誤文件的分發，換上了舊的正常版本，然后重啟了核心服務，網絡才慢慢恢復正常。

這次 Cloudflare 的全球宕機，再次提醒我們：在分布式系統里，最危險的往往不是黑客，而是自己的一行配置。一個權限改動，就能讓全球互聯網瞬間失速。

對運維和架構團隊來說，最大的反思是——配置要當代碼管，熔斷要隨時可用，監控要能分辨“自己人”。只有這樣，才能避免下一次“史詩級事故”重演。

互聯網的脆弱性在這一天被放大，但也讓我們更清楚：穩定不是理所當然，而是每一次謹慎改動、每一道防線共同守護的結果。