網(wǎng)易首頁 > 網(wǎng)易號 > 正文申請入駐

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

2025-11-19 17:34:27　來源: 星哥說事

廣東舉報

分享至

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

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

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

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

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

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

一、事故概述

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

故障發(fā)生后，技術(shù)團隊啟動緊急響應(yīng)，14:30 核心流量基本恢復(fù)正常，17:06 所有受影響服務(wù)完全恢復(fù)穩(wěn)定運行。期間多個核心產(chǎn)品及服務(wù)受到不同程度影響，對廣大客戶及全球互聯(lián)網(wǎng)訪問體驗造成了負面影響，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 加速及安全防護的網(wǎng)站，頁面顯示 Cloudflare 網(wǎng)絡(luò)內(nèi)部故障提示。

（二）Turnstile 服務(wù)

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

（三）Workers KV

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

（四）管理后臺（Dashboard）

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

（五）郵件安全（Email Security）

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

（六）Access 服務(wù)

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

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

三、應(yīng)急措施

1. 故障初期啟動多維度排查，快速排除 DDoS 攻擊等外部因素，鎖定內(nèi)部服務(wù)異常。
2. 針對 Workers KV 和 Access 服務(wù)啟用旁路機制，繞開故障核心代理，快速降低關(guān)鍵服務(wù)影響范圍。
3. 定位特征文件異常后，立即停止異常文件的生成與傳播，避免故障進一步擴散。
4. 全球部署經(jīng)驗證的歷史正常特征文件，強制重啟核心代理服務(wù)，修復(fù)核心流量處理鏈路。
5. 恢復(fù)階段擴容控制平面并發(fā)能力，處理登錄請求積壓問題，修復(fù)剩余異常服務(wù)實例。

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

現(xiàn)在我們的系統(tǒng)已恢復(fù)正常運行，我們已經(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 服務(wù)流量異常增加和故障情況。

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