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

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