一次数据库更新如何瘫痪全球 20% 网络

11 月 18 日的故障警示：當 Cloudflare 發生中斷時，誰在為基礎設施買單？

美國東部時間上午 6 點 20 分，全球大約 20% 的網際網路流量突然陷入停擺。一個常規的資料庫權限調整，觸發了一連串連鎖反應，導致支撐現代網路運作的核心服務大規模中斷。

這不是駭客攻擊，也不是外部威脅。問題的根源，只是一份配置文件在體積翻倍後，超過了系統預設的上限。

從一行資料庫查詢開始的災難

事件發生的時間表清晰而殘酷：

UTC 11:05 — Cloudflare 對 ClickHouse 資料庫叢集進行權限更新，目的是增強安全性與可靠性。

UTC 11:28 — 變更覆蓋至使用者環境，首次出現錯誤記錄。

UTC 11:48 — 官方狀態頁面承認故障。

UTC 17:06 — 服務完全恢復，持續時間超過 5 小時。

技術層面的真相

故障的核心問題在於一個看似簡單的疏漏：負責生成 Cloudflare 機器人防護服務設定檔的資料庫查詢，缺少「資料庫名稱」的篩選條件。

這導致系統傳回重複條目——一份來自預設資料庫，另一份來自底層的 r0 儲存資料庫。功能檔案的體積因此增加一倍，從原本約 60 個特徵擴展至 200 多個。

Cloudflare 曾為記憶體預先分配設定了 200 個特徵的硬編碼上限，工程師認為「這遠高於我們目前的實際使用量」。直到意外發生，這個看似寬鬆的安全邊際瞬間崩潰。

體積超標的檔案觸發上限，Rust 程式碼直接拋出錯誤：“thread fl2_worker_thread panicked: called Result::unwrap() on an Err value”

機器人防護系統是 Cloudflare 網路控制層的核心。它一旦故障，用來指導負載平衡器「哪些伺服器正常運作」的健康檢查系統也隨之失效。

最具諷刺意味的是，這份設定檔每 5 分鐘會重新生成一次。只要查詢在更新後的叢集節點執行，就會產生錯誤資料。結果是 Cloudflare 的網路在「正常」與「故障」之間反覆切換——時而能載入正確文件，時而載入錯誤文件。

這種「反覆中斷」讓工程師誤以為正遭受大規模分散式阻斷服務（DDoS）攻擊。因為內部錯誤通常不會導致這種週期性的恢復-崩潰循環。

最終，所有 ClickHouse 節點完成更新後，每次產生的檔案都是錯誤的。沒有準確的系統訊號，防護系統默認進入「保守模式」，將大部分伺服器判定為「不健康」。網際網路流量不斷湧入 Cloudflare 的邊緣節點，卻無法被正確路由。

全球網路的寂靜時刻

Web2 平台全線癱瘓

• X 平台收到 9,706 份故障報告
• ChatGPT 在對話中途停止回應
• Spotify 串流中斷
• Uber 與外送平台功能異常
• 遊戲玩家遭遇強制斷線
• 甚至連麥當勞的自助點餐機也彈出錯誤界面

加密領域無一倖免

主要交易所的網頁介面崩潰，使用者面對無法載入的登入頁面和交易介面。

區塊鏈瀏覽器（如 Etherscan、Arbiscan）直接宕機。

數據分析平台（DeFiLlama）出現間歇性伺服器錯誤。

硬體錢包提供商發佈公告，服務可用性下降。

唯一的「例外」：區塊鏈協議本身

據報道，主要交易所未出現前端故障，鏈上交易正常進行。區塊鏈本身保持完全正常運轉，沒有任何共識中斷的跡象。

這暴露了一個尖銳的矛盾：如果區塊鏈仍在生成區塊，卻沒人能訪問它，那麼加密貨幣真的還「線上」嗎？

Cloudflare 在全球網際網路流量中的角色

Cloudflare 並不託管網站，也不提供雲端伺服器服務。它的角色是「中間人」——介於使用者與網路之間。

核心數據：

• 為 2,400 萬個網站提供服務
• 遍佈 120 個國家、330 座城市的邊緣節點
• 處理全球約 20% 的網際網路流量
• 在 DDoS 防護領域佔據 82% 的市場份額
• 邊緣節點總頻寬達 449 太比特/秒（Tbps）

當這樣一個「中介」失效時，背後的所有依賴服務會同時變得「無法觸碰」。

Cloudflare CEO Matthew Prince 在官方聲明中直言：「這是 Cloudflare 自 2019 年以來最嚴重的一次故障……在過去 6 年多里，我們從未發生過能導致大部分核心網際網路流量無法透過我們網路傳輸的故障。」

18 個月內 4 次重大故障：產業為何仍未改變？

2024 年 7 月 — CrowdStrike 安全更新漏洞導致全球 IT 系統癱瘓（航班停飛、醫院延誤、金融服務凍結）

2025 年 10 月 20 日 — AWS 故障持續 15 小時，美國東部區域 DynamoDB 服務中斷，導致多個區塊鏈網路下線

2025 年 10 月 29 日 — 微軟 Azure 設定同步問題，Microsoft 365、Xbox Live 服務癱瘓

2025 年 11 月 18 日 — Cloudflare 故障，全球約 20% 的網際網路流量受影響

單一承包商模式的風險

AWS 掌控全球約 30% 的雲端基礎設施市場，微軟 Azure 佔 20%，Google 雲端佔 13%。三家公司掌控著支撐現代網路的 60% 以上基礎設施。

加密產業本應是「去中心化」的解決方案，如今卻被迫依賴這些全球最中心化的基礎設施供應商。

當出現故障時，行業唯一的「災難復原策略」就是：等待。等 Cloudflare 修復，等 AWS 恢復，等 Azure 部署補丁。

「去中心化」的虛偽：協議層去中心化，不等於存取層去中心化

加密產業曾向世人描繪的願景是：

去中心化金融、抗審查貨幣、無需信任的系統、無單點故障、程式碼即法律

11 月 18 日的現實卻是：一次上午的故障，讓大部分加密服務停擺了數小時。

技術層面：沒有任何區塊鏈協議被通報故障。

使用現實：交易介面崩潰、瀏覽器癱瘓、數據平台宕機、500 錯誤滿屏。

使用者無法存取本應「擁有」的「去中心化」區塊鏈。協議本身運作正常——前提是你能「接觸」它。

為何行業仍選擇「便利」而非「原則」？

自建去中心化基礎設施意味著：購買昂貴硬體、保障穩定供電、維護專屬頻寬、僱用安全專家、實現地理冗餘、建造災備系統、24 小時監控。

而使用 Cloudflare 只需：點擊一個按鈕、輸入信用卡資訊、幾分鐘內完成部署。

新創公司追求「快速上市」，投資機構要求「資本效率」——所有人都選擇了「便利」，而非「抗故障能力」。

直到「便利」不再便利的那一刻。

去中心化替代方案為何「叫好不叫座」？

去中心化存儲（如 Arweave）、分散式檔案傳輸（IPFS）、去中心化運算（Akash）、去中心化託管（Filecoin）等方案確實存在。

但它們面臨的問題包括：

• 效能落後於中心化方案，延遲問題使用者能直接感知
• 普及率極低，使用流程繁瑣
• 成本往往高於從三大雲服務商租賃基礎設施

建構真正的去中心化基礎設施難度極高，遠超想像。

大多數項目只把「去中心化」掛在嘴邊，卻很少真正落地。選擇中心化方案，始終是更簡單、更廉價的選項——直到故障發生。

監管層的新課題

30 天內三次重大故障，已引發監管機構高度關注：

• 這些公司是否屬於「具有系統重要性的機構」？
• 網路骨幹服務應納入「公用事業式監管」？
• 當「大到不能倒」與科技基礎設施結合，會引發怎樣的風險？
• Cloudflare 掌控全球 20% 的網際網路流量，是否構成壟斷問題？

美國財政部正推動將身份憑證嵌入智慧合約，要求每一次 DeFi 互動都必須通過 KYC 審核。當下一次基礎設施故障發生時，使用者失去的將不只是交易權限——還會失去在金融體系中「證明自己身份」的能力。

原本 3 小時的故障，會變成 3 小時「無法通過人機驗證」——只因驗證服務運作在已癱瘓的基礎設施上。

從「便利」到「必然」：何時才是轉折點？

11 月 18 日，加密產業並未「失敗」——區塊鏈本身運作完美。

真正「失敗」的，是行業集體自欺欺人：

• 以為能在「可癱瘓的基礎設施」上搭建「不可阻擋的應用」
• 以為當三家公司掌控「訪問通道」時，「抗審查」還有實際意義
• 以為當 Cloudflare 的一份配置文件就能決定數百萬人能否交易時，「去中心化」還有實際意義

基礎設施抗故障能力不應是「可有可無的加分項」，而應是「支撐一切的基礎要求」——沒有它，其他所有功能都無從談起。

下一次故障已在醞釀中——可能來自 AWS，可能來自 Azure，可能來自 Google 雲端，也可能是 Cloudflare 的二次故障。可能是下個月，也可能是下週。

選擇中心化方案，依舊是更廉價、更快速、更便捷的選項——直到它不再是。

當 Cloudflare 下一次常規配置變更觸發下一個關鍵服務中的隱藏漏洞時，我們將再次目睹熟悉的場景：滿眼的 500 錯誤、交易全面暫停、區塊鏈運轉正常卻無人能訪問、企業承諾「下次會做得更好」卻從未兌現。

這就是當前產業的困境：一切都不會改變，因為「便利」總是能戰勝「風險防範」——直到「便利」的代價大到再也無法忽視的那一天。