2025年11月18日晚上約19:30(香港時間），Cloudflare 發生了持續3小時的全球性大規模中斷。這不是普通的區域故障，而是幾乎同時波及全球三十多個主要數據中心，導致數百萬網站、App、後台系統瞬間「失明」。OpenAI，X (前身Twitter）， Downdetector，Spotify，部分國家級電商平台，甚至連許多銀行的網銀登入頁面都直接 出現500 Internal Server Error。
那一刻，網路上最常見的一句話變成了：「Cloudflare is down，又來了。」
這已經是2024～2025年間Cloudflare第三次「全球級」事故。雖然官方指出故障是由一個「配置檔案」引起的，該檔案原本用於管理「威脅流量」，但其條目數量超出了預期大小，觸發了處理部分Cloudflare服務流量的軟體系統崩潰，進而「波及到整個網路和服務的廣泛降級」。但對數位從業者來說，這句話翻譯成白話就是：
「我們把雞蛋放在一個全世界最大的籃子裡，然後那個籃子掉地上了。」
這件事暴露了三個殘酷的事實
- 現代網際網路的單點故障風險比我們想像的更高
Cloudflare 目前承載全球約20%的網頁流量，相當於每5個HTTPS請求就有一個是經過它的節點。當它倒下時，倒下的不是只是單一網站，而是整個「基礎設施層」。這就像電網、像自來水總管，平時感覺不到它的存在，一旦停供，整座城市瞬間癱瘓。 - 「零信任」和「分散式」只是口號，現實仍然是中心化
許多公司宣稱自己用了多雲、多CDN、多地區部署，但實際上還是「Cloudflare + 備用CDN」這種偽多活架構。一旦Cloudflare掛了，備用CDN的觸發邏輯本身也需要通過Cloudflare的DNS才能夠生效，結果就是連切換都切不了。昨晚就有無數工程師在Slack裡哀號：「failover沒觸發，因為health check的域名解析也掛了！」 - 商業決策永遠會擊敗技術理想
為什麼大家還是擠破頭用Cloudflare？因為它真的好用、真的便宜、真的快。把安全、防禦、加速、DNS、R2、Workers全部丟給一家，成本可以壓到不可思議的地步。於是「技術債」被轉譯成了「利潤」，風險被寫進了財報的「第三方服務中斷風險」那一行小字裡，沒有人真正當回事，直到昨晚。
我們該怎麼辦？
- 承認現實：完全不依賴第三方幾乎不可能
除非你願意花AWS 10倍的錢自己拉光纖、自己建DDoS清洗中心，否則某種程度的依賴是無法避免。問題不在於「要不要依賴」，而在於「依賴到什麼程度」以及「能否在對方倒下時活下來」。 - 把「關鍵服務」與「加速服務」徹底切割
最危險的做法是把域名解析（DNS）、身分認證（SSO）、核心API全都交給同一家。合理的做法是：
- DNS：至少主備兩家不同供應商（例如Cloudflare + Route 53 + DNSpod）
- CDN：流量走Cloudflare，但健康檢查與failover邏輯走自建或另一家CDN
- 身分認證：Okta、Auth0之類的SaaS可以繼續用，但務必啟用備用MFA方式與離線驗證流程
- 靜態資源：重要頁面（登入、結帳）做雙寫到S3 + R2 + Backblaze B2
- 建立「真·多活」而不是「偽多活」
昨晚很多公司發現自己設了「Backup Origin」，但Backup Origin的IP是寫死在Cloudflare的Page Rule裡，結果Cloudflare掛了，Page Rule自然也沒人執行。真正的多活要把切換邏輯寫在客戶端或最靠近用戶的層級（例如用Global Load Balancer + Anycast）。 - 把「第三方大斷站」列入災難復原演練
大多數公司的DR演練只模擬「自家機房火災」或「AWS地區熔斷」，卻很少模擬「Cloudflare全球性掛掉」。下次演練時，直接把Cloudflare的IP全部加入防火牆黑名單，看看你的服務能撐多久。 - 留一條「最爛的備胎」
即使速度慢、成本高、體驗差，也要有一條完全不依賴任何大廠SaaS的備用路徑。例如：把最關鍵的登入頁面靜態化，放在GitHub Pages + CloudFront；把簡易結帳流程保留一份純HTML表單直連銀行API。就像戰機的機械備份瞄準具，平時永遠不用，但關鍵時刻郤能救命。
結論
昨晚那一場90分鐘的全球宕機，其實是一場免費的、殘酷的壓力測試。它提醒我們：
在雲端時代，「便利」與「脆弱」永遠是一枚硬幣的兩面。
我們不可能回到自己拉光纖的年代，但至少可以拒絕把命門完全交出去。
真正的數位主權，不是不用Cloudflare，而是：
即使Cloudflare明天徹底消失，你的公司依然能在12小時內恢復80%的關鍵服務。
這才是2025年之後，我們應該追求的「基礎設施成年禮」。
