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

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

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

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

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

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

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

一、事故概述

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

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

二、影響范圍

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

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

（一）核心 CDN 與安全服務

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

（二）Turnstile 服務

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

（三）Workers KV

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

（四）管理后臺（Dashboard）

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

（五）郵件安全（Email Security）

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

（六）Access 服務

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

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

三、應急措施

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

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

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

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

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

四、補救和后續(xù)步驟

現(xiàn)在我們的系統(tǒng)已恢復正常運行，我們已經(jīng)開始著手研究如何加強系統(tǒng)，以防止未來再次發(fā)生類似故障。具體來說，我們正在：

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

• ? 為功能啟用更多全局終止開關(guān)

• ? 消除核心轉(zhuǎn)儲或其他錯誤報告占用系統(tǒng)資源的可能性

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

時間（UTC）

地位

描述

11:05

普通的。

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

11:28

沖擊開始。

部署到達客戶環(huán)境后，在客戶 HTTP 流量中首次發(fā)現(xiàn)錯誤。

11:32-13:05

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

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

13:05

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

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

13:37

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

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

14:24

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

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

14:24

新文件測試完成。

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

14:30

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

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

17:06

所有服務已恢復正常。影響已結(jié)束。

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

官方事故報告

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


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

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

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

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

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

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

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

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