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

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

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

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

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

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

官方承認(rèn)，這是自 2019 年以來最嚴(yán)重的一次宕機(jī)。

一、事故概述

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

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

二、影響范圍

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

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

（一）核心 CDN 與安全服務(wù)

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

（二）Turnstile 服務(wù)

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

（三）Workers KV

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

（四）管理后臺（Dashboard）

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

（五）郵件安全（Email Security）

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

（六）Access 服務(wù)

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

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

三、應(yīng)急措施

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

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

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

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

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

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

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

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

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

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

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

時(shí)間（UTC）

地位

描述

11:05

普通的。

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

11:28

沖擊開始。

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

11:32-13:05

該團(tuán)隊(duì)調(diào)查了 Workers KV 服務(wù)流量異常增加和故障情況。

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

13:05

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

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

13:37

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

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

14:24

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

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

14:24

新文件測試完成。

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

14:30

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

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

17:06

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

所有下游服務(wù)已重啟，所有操作已完全恢復(fù)。

官方事故報(bào)告

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


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

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

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

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

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

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

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

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