2025 Cloudflare 全球大當機

2025 Cloudflare 全球大當機:一個設定檔害 ChatGPT、X 全掛,中小企業能學到什麼?

2025 年 11 月 18 日晚間,全球大量網站突然同時出現 Cloudflare 錯誤頁面
包括 ChatGPT、X(前 Twitter)、Canva、Riot(英雄聯盟)、IKEA、甚至英國金管會、MI5 等單位的網站,都一度無法正常連線

在台灣,數個政府網站也受到影響
例如 10000.gov.tw 的 NT$10,000 現金發放專區一度無法正常載入
數位部後來說明,是因 Cloudflare 服務異常造成連線不穩

對一般使用者來說,只看到一片「Error 500 / 502」
但對企業 IT 來說,這次是很典型的「單一雲端供應商出事,整片網路一起跌倒」案例


一、這次 Cloudflare 到底發生了什麼事?

Cloudflare 的官方事故報告是這樣說的:

  • 11:05 UTC
    他們在內部 ClickHouse 資料庫做了一個「權限管理」相關調整

  • 11:20 UTC 左右
    產生給 Bot Management 使用的「特徵設定檔」內容異常
    行數暴增超過系統原本預設的上限

  • 核心代理程式(FL/FL2)在載入這份設定檔時觸發程式錯誤
    大量節點開始回 5xx 錯誤

  • 一開始他們懷疑是超大規模 DDoS
    但後來發現是「內部程式+設定檔」的組合問題

簡單講
是 Bot Management 的設定檔在產生時,因為資料庫查詢邏輯改動,導致內容翻倍成「超出程式能承受的大小」
結果核心代理程式直接 panic 掛掉,HTTP 5xx 滿天飛

Cloudflare 在 14:30 UTC 左右停止散佈壞掉的設定檔,改回舊版,並重啟核心代理
大部分流量在那之後陸續恢復,直到 17:06 UTC 才完全正常


二、影響有多大?為什麼一家公司當機,全世界都跟著卡住?

幾個數字給你參考:

  • Cloudflare 目前保護、加速的網站大約占全球網站的 20% 左右

  • 這次一度影響到 X、ChatGPT、Uber、Canva、Bet365、League of Legends、YouTube 等大量服務

  • 一些金融機構、政府單位、甚至 Home Depot 的法說會直播都被中斷

  • 台灣部分政府網站、服務申請平台,也因為走 Cloudflare 的 CDN / 安全服務而受到波及

所以才會看到新聞用「全球網路短暫斷線」這種字眼
嚴格說是 Cloudflare 相關流量斷線
但因為它的覆蓋率太高,一般使用者感覺就像「網路很大一塊都壞掉了」


三、官方後續怎麼說?會怎麼補強?

在官方事故文章裡,Cloudflare 把這次形容成 「自 2019 年以來最嚴重的一次事故」
他們承認這次是設計與流程上的錯誤,而不是外部攻擊

預計的補強方向包含:

  • 把「系統自己生成的設定檔」也當成不可信輸入來驗證

  • 增加更多「一鍵停用某功能」的全球 kill switch

  • 確保錯誤回報 / core dump 不會把系統資源吃光

  • 重新檢討核心代理上所有模組遇到錯誤時的「安全失效模式」

對我們來說重點不是他寫了多少技術細節
而是這家公司已經算是全世界最熟悉大規模網路運營的之一
還是會在「內部程式邏輯 + 變更流程」上踩到雷


四、中小企業可以學到的 3 個重點

這次 Cloudflare 掛掉,其實是一次很好的教材
不只是「啊 又是大公司出事」
對你在台灣幫客戶做機房、網站、資安,都有幾個很實際的提醒:

1. 過度依賴單一雲端/CDN 供應商的風險

很多公司現在架網站
DNS 在 Cloudflare
CDN 在 Cloudflare
WAF / Bot 防護也在 Cloudflare

平常很方便、效能也很好
但一旦它自己出問題,就是 「一家公司當機=你整個對外服務一起躺平」

可以開始思考:

  • DNS 是否有備援方案(例如多家 DNS 供應商)

  • 關鍵服務是否有「繞過 CDN 直接連原站」的應急方案

  • 是否留有「不用 Cloudflare 的備援網址」至少能發公告

2. 監控與應變流程,不要只看一家 Status Page

這次 Cloudflare 自己的狀態頁,一度也因為巧合出現錯誤訊息,增加排查難度

對企業來說
你可以建立這樣的習慣:

  • 自己做外部監控(例如從不同國家節點去測試官網、API)

  • 同時關注:Cloudflare / AWS / Azure / 本地 IDC 等多個狀態頁

  • 內部有一個「服務異常快速通報流程」:誰判斷、誰對外說明、誰負責對客戶/主管報告

3. 把這種事件寫進 BCP,而不是只當一次新聞

Cloudflare 這種等級的公司都會出錯
那我們能做的不是期待「某一家永遠不會掛」
而是:

  • 在 BCP / DR 計畫裡明確寫出:「CDN 出事時,我們可以接受多久的服務降級?有沒有備援路徑?」

  • 跟老闆溝通成本:

    • 要多花多少錢做多 CDN、多 DNS

    • 反過來,如果沒有備援,一次幾小時的停擺會帶來多少損失