Cloudflare 故障：撕開加密行業偽去中心化的外衣

18 個月內 4 次重大故障，中心化困局為何難解？

來源：rekt news

編譯：Saoirse，Foresight News

2025 年 11 月 18 日，美國東部時間上午 6 點 20 分。我們中的許多人都遭遇了網路中斷。

並非漸進式中斷，也沒有任何預警信號。前一秒你還在滑手機、進行交易、與人工智慧聊天，下一秒，目光所及之處，幾乎全是 500 錯誤頁面。

推特在發推途中突然陷入癱瘓，ChatGPT 在對話到一半時停止回應，Claude 則直接卡住。

就連 Downdetector——那個當所有平台都出故障時，你會去查詢故障情況的網站——也無法加載，無法告訴你「所有服務都已癱瘓」。

全球 20% 的網路就這樣憑空消失，只因本應保護網際網路免受攻擊的 Cloudflare，意外「攻擊」了它自己。

一次常規的配置變更（資料庫權限更新）觸發了其機器人防護系統中的一個隱藏漏洞，轉瞬之間，這位「守門人」竟將所有人都拒之門外。

10 月份，當亞馬遜雲服務（AWS）導致 Coinbase 下線時，加密貨幣領域的推特用戶還在大肆嘲諷「中心化」的弊端。

可到了 11 月 Cloudflare 故障爆發時呢？至少在最初的幾個小時裡，整個加密圈鴉雀無聲。

畢竟，當推特所依賴的基礎設施都已癱瘓時，你根本沒法在推特上討論「基礎設施脆弱性」這個話題。

多項關鍵服務陷入停滯（交通站點系統癱瘓），部分企業的網路介面出現故障，Arbiscan、DeFiLlama 等區塊鏈瀏覽器也接連彈出 500 錯誤——但區塊鏈本身並未出現任何共識中斷的跡象。

當你所標榜的「去中心化」革命，竟會因為一家公司配置檔案體積過大而無法運轉時，真正掌控全局的究竟是誰？

故障時間線：從「配置變更」到「全網癱瘓」

UTC 時間 11:05：資料庫存取控制變更部署完成。

23 分鐘後，即 UTC 時間 11:28，變更覆蓋至用戶環境，用戶的 HTTP 流量中首次出現錯誤記錄。

換句話說：故障已經發生，只是當時沒人知道問題出在哪。

截至 UTC 時間 11:48，Cloudflare 官方狀態頁面終於承認「內部服務出現故障」——這種企業話術的真實含義是：「一切都亂套了，而且所有人都看得出來。」

連鎖反應來得猝不及防：此次變更破壞了 Cloudflare 的機器人管理層，當系統加載一個體積翻倍的功能檔案時，其代理服務直接「當機」。

下游系統隨之崩潰：Workers KV（鍵值儲存服務）與 Access（存取控制服務）無法連接到代理；全網錯誤率飆升，隨著監控工具負載驟增，CPU 使用率也突破峰值。

流量仍在不斷湧入 Cloudflare 的邊緣節點——但代理服務已無法做出任何回應。

Cloudflare 起初以為自己正遭受攻擊，而且是一場超大規模的分散式拒絕服務（DDoS）攻擊。

更詭異的是，就連完全託管在 Cloudflare 基礎設施之外的官方狀態頁面，也同步陷入癱瘓，工程師們因此懷疑：這是一場針對其核心系統與監控體系的協同攻擊。

但事實並非如此。他們沒有遭到外部攻擊，問題出在自己身上。

服務恢復後不久，Cloudflare 首席技術官（CTO）Dane Knecht 便發布了公開道歉聲明，稱此次事件「完全不可接受」，並將故障原因歸咎於一次常規配置變更——正是這次變更觸發了機器人防護層的崩潰。

「我們辜負了客戶，也辜負了更廣泛的網際網路用戶，」Knecht 在聲明中寫道，「支撐我們機器人防護功能的某項服務中存在一個潛在漏洞，在一次常規配置變更後突然崩潰，並引發了我們網路及其他服務的大面積故障。這並非一次外部攻擊。」

故障高峰期，Downdetector 平台收到的故障報告多達 11183 份。

這場「數位黑暗」持續了超過 5 個半小時，直至 UTC 時間 17:06，服務才完全恢復；不過早在 14:30，全球部署正確的機器人管理配置檔案後，最嚴重的影響已得到緩解。

故障衝擊：從 Web2 到加密領域，無一倖免

Web2 平台首當其衝

X 平台收到了 9706 份故障報告。

用戶沒有看到熟悉的時間線，取而代之的是「哎呀，出了點問題」的錯誤提示。

ChatGPT 在對話中途突然「沉默」，不再回應任何指令。

Spotify 串流媒體服務中斷，Canva 設計平台將設計師拒之門外，Uber 與 Door Dash（外送平台）也相繼出現功能異常。

就連遊戲玩家也未能倖免，《英雄聯盟》玩家在遊戲中途遭遇強制斷線。

甚至有消息稱，麥當勞的自助點餐機也彈出了錯誤介面——午餐高峰期與基礎設施故障撞個正著。

加密貨幣領域同樣未能「獨善其身」。

加密平台大面積停擺

Coinbase 前端徹底崩潰，用戶面對的只有無法加載的登入頁面。

Kraken 的網頁端與行動應用雙雙「陣亡」——這正是 Cloudflare 全球故障的直接後果。

BitMEX 在其狀態頁面發布公告：「正在調查故障原因，平台效能下降，但用戶資金安全無虞。」——同樣的劇本，只是換了一家交易所。

Etherscan 無法加載，Arbiscan 直接當機。

DeFiLlama 的數據分析面板間歇性出現內部伺服器錯誤。

甚至 Ledger 也發布公告稱，受 Cloudflare 故障影響，部分服務的可用性下降。

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

但以下系統並未受到影響：

據報導，幣安、OKX、Bybit、Crypto.com、KuCoin 等主要交易所未出現前端故障，鏈上交易正常進行——與此同時，區塊鏈本身保持完全正常運轉，沒有任何共識中斷的跡象。

區塊鏈協議始終獨立運行——問題並非出在鏈上，而是出在人們用於存取區塊鏈的 Web2 基礎設施上。

如果區塊鏈仍在運轉，卻沒人能存取它，那加密貨幣真的還「在線」嗎？

深度解析：一個資料庫查詢，為何搞癱 20% 的網路？

Cloudflare 並不託管網站，也不像 AWS 那樣提供雲伺服器服務。

它的角色是「中間人」——介於用戶與網際網路之間，為 2400 萬個網站提供服務，通過遍布 120 個國家、330 座城市的節點，處理著全球 20% 的網路流量。

Cloudflare 的宣傳話術是這樣的：它將自己定位為「網際網路的防護盾與加速器」，提供全天候 DDoS 防護、機器人防護、流量路由、全球 Web 應用防火牆（WAF）、TLS 終止、基於 Workers 的邊緣運算以及 DNS 服務——所有功能均運行在統一的「安全-效能」網路上。

而實際情況是：它在 DDoS 防護領域佔據 82% 的市場份額，邊緣節點總頻寬達 449 太比特/秒（Tbps），與全球眾多主流網際網路服務提供商（ISP）及雲服務商相連。

問題的核心在於：當中介機構失效時，其背後的所有服務會同時變得「觸不可及」。

Cloudflare 首席技術官 Dane Knecht 在 X 平台上直言不諱地表示：

「我就直說了：今天早些時候，由於 Cloudflare 網路出現問題，大量依賴我們的流量受到影響，我們辜負了客戶，也辜負了更廣泛的網際網路用戶。」

CEO Matthew Prince 的表述則更為直接：

「今天是 Cloudflare 自 2019 年以來最嚴重的一次故障……過去 6 年多裡，我們從未發生過能導致大部分核心流量無法通過我們網路傳輸的故障。」

故障的技術根源

一切始於一次常規的資料庫權限更新。UTC 時間 11:05，Cloudflare 對其 ClickHouse 資料庫叢集進行了一次變更，目的是提升安全性與可靠性——讓原本擁有「隱式存取權限」的用戶，能夠「顯式」看到表元資料。

問題出在哪？生成 Cloudflare 機器人防護服務配置檔案的資料庫查詢，沒有對「資料庫名稱」進行過濾。

負責管理威脅流量的查詢語句開始返回重複條目——一份來自預設資料庫，另一份來自底層的 r0 儲存資料庫。這導致功能檔案的體積翻倍，從原本約 60 個特徵，增至 200 多個特徵。

Cloudflare 曾為記憶體預分配設置了 200 個特徵的硬編碼上限，並認為「這遠高於我們目前約 60 個特徵的實際使用量」。這是典型的工程思維：設置一個自認為「足夠寬鬆」的安全邊際，直到意外發生。

體積超標的檔案觸發了這一上限，Rust 程式碼直接崩潰，報錯資訊為：「thread fl2_worker_thread panicked: called Result::unwrap () on an Err value」（fl2_worker_thread 執行緒崩潰：在錯誤值上呼叫了 Result::unwrap () 方法）。

機器人防護系統是 Cloudflare 控制層的核心組件。它一旦崩潰，用於告知負載平衡器「哪些伺服器正常運行」的健康檢查系統也隨之「失靈」。

更糟的是：這份配置檔案每 5 分鐘會重新生成一次。

只有當查詢語句在「已更新的叢集節點」上運行時，才會生成錯誤資料。因此，每 5 分鐘，Cloudflare 的網路就會在「正常」與「故障」之間反覆切換——時而能加載正確檔案，時而加載錯誤檔案。

這種「反覆橫跳」讓工程師們誤以為正遭受 DDoS 攻擊——內部錯誤通常不會導致系統「恢復又崩潰」的循環。

最終，所有 ClickHouse 節點都完成了更新，每次生成的檔案都是錯誤的。「反覆橫跳」停止了，取而代之的是「徹底、穩定的故障」。

沒有準確的系統信號，系統便預設進入「保守模式」，將大部分伺服器判定為「不健康」。流量不斷湧入，卻無法被正確路由。

Cloudflare 的邊緣節點能接收到用戶的請求——卻無法對請求做任何處理。

「這並非一次外部攻擊，」Knecht 特別反覆強調，「沒有惡意行為，也不是 DDoS 攻擊。只是一次資料庫查詢遺漏了過濾條件，恰好與權限更新撞在了一起，最終引發了故障。」

Cloudflare 曾承諾「99.99% 的可用性」——但這一次，承諾並未兌現。

事實確實如此。

歷史重演：18 個月內 4 次重大故障，中心化困局為何難解？

2025 年 10 月 20 日——AWS 故障持續 15 小時。美國東部 1 區的 DynamoDB 資料庫 DNS 解析失敗，導致 Coinbase 凍結、Robinhood 卡頓、Infura 服務中斷（進而影響 MetaMask），Base、Polygon、Optimism、Arbitrum、Linea、Scroll 等區塊鏈網路全部下線。儘管用戶資金在鏈上安全無虞，但很多人看到的帳戶餘額卻是「零」。

2025 年 10 月 29 日——微軟 Azure 故障。Azure Front Door（前端門戶）出現配置同步問題，導致 Microsoft 365 辦公套件下線、Xbox Live 服務癱瘓、企業服務中斷。

2024 年 7 月——CrowdStrike（安全公司）的 Windows 更新包存在漏洞。此次故障導致航班停飛、醫院醫療流程延誤、金融服務凍結，完全恢復耗時數日。

2022 年 6 月——Cloudflare 上一次重大故障。多家加密交易所被迫暫停服務——同樣的模式，只是換了一年。

2019 年 7 月——Cloudflare 更早的一次故障。Coinbase 下線，CoinMarketCap 無法訪問——這是第一個被所有人忽視的「警告信號」。

短短 18 個月內，就發生了 4 次重大基礎設施故障。

四次故障，傳遞的是同一個教訓：中心化基礎設施，必然導致「中心化故障」。

四次故障，本可以讓加密行業加速向去中心化轉型——但它至今仍依賴三家公司提供的基礎設施。

要經歷多少次警告，行業才會從「假設故障可能發生」，轉變為「按故障必然發生的標準來構建系統」？

去中心化的「謊言」：協議去中心化，不代表存取去中心化

他們曾向你描繪這樣一幅藍圖：

「去中心化金融、抗審查貨幣、無需信任的系統、無單點故障、『不是你的私鑰，就不是你的幣』、程式碼即法律。」

11 月 18 日的現實卻給了一記重擊：Cloudflare 一個上午的故障，就讓加密行業的部分服務停擺了數小時。

技術層面的真相：

沒有任何區塊鏈協議被報導出現故障。比特幣網路正常運行，以太坊網路也正常運行——鏈本身沒有任何問題。

實際使用中的現實：

交易所介面崩潰、區塊鏈瀏覽器癱瘓、錢包介面失效、數據分析平台當機、交易介面彈出 500 錯誤。

用戶無法存取自己本應「擁有」的「去中心化」區塊鏈。協議本身運轉正常——前提是你能「觸及」它。

以下這些言論，或許會讓很多人感到刺耳……

SovereignAI 首席營運官（COO）David Schwed 毫不留情地指出：

「如今 Cloudflare 故障，幾週前 AWS 故障，這充分說明：我們不能簡單地將基礎設施的『抗故障能力』外包給單一供應商。如果你的機構需要 24 小時不間斷運行，就必須按照『故障必然發生』的標準來構建基礎設施。如果你的業務持續性計畫只有『等待供應商恢復服務』這一條，那就是純粹的疏忽。」

「純粹的疏忽」——不是意外，不是疏漏，而是疏忽。

Jameson Lopp 的評價一針見血：

「我們擁有一項出色的去中心化技術，卻因為將大部分服務集中在少數幾家供應商手中，讓它變得極度脆弱。」

Ben Schiller 在 AWS 上次故障時說過的話，如今同樣適用：

「如果你的區塊鏈會因為 AWS 故障而下線，那它根本不夠去中心化。」

把「AWS」換成「Cloudflare」，問題本質完全相同——行業從未吸取教訓。

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

自建基礎設施意味著：購買昂貴的硬體、保障穩定供電、維護專屬頻寬、雇用安全專家、實現地理冗餘、搭建災備系統、24 小時監控——每一項都要投入大量資源。

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

DDoS 防護由別人負責，可用性由別人保障，擴容由別人操心。

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

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

10 月的 AWS 故障，引發了推特上關於「去中心化」的無休止討論。

11 月的 Cloudflare 故障呢？鴉雀無聲。

不是出於「哲學層面的沉默」，也不是「深思後的安靜」。

而是因為：人們想吐槽，卻發現自己常用的吐槽平台（推特），也因基礎設施故障而癱瘓。

當「單點故障」恰好是你用來嘲諷「單點故障」的平台時，你根本無從吐槽。

當存取層依賴三家公司的基礎設施，其中兩家還在同一個月內發生故障時，「協議層面的去中心化」毫無意義。

如果用戶無法觸及區塊鏈，那我們所謂的「去中心化」，究竟是在「去中心化」什麼？

壟斷困局：三家公司掌控 60% 雲市場，加密行業何去何從？

AWS 掌控著全球約 30% 的雲基礎設施市場，微軟 Azure 佔 20%，Google Cloud 佔 13%。

三家公司，掌控著支撐現代網際網路的 60% 以上雲基礎設施。

加密行業本應是「中心化」的解決方案，如今卻依賴著全球最中心化的基礎設施。

加密行業的「中心化依賴清單」

• Coinbase —— 依賴 AWS；
• 幣安、BitMEX、火幣、Crypto.com —— 均依賴 AWS；
• Kraken 雖基於 AWS 構建基礎設施，卻仍因 Cloudflare 的 CDN（內容分發網路）故障受到衝擊。

許多標榜「去中心化」的交易所，實則運行在中心化的基礎設施之上。

10 月與 11 月的故障，還有一個關鍵區別：

AWS 故障時，X 平台（原推特）仍能正常運行，加密圈的推特用戶得以大肆嘲諷「基礎設施脆弱性」。

而 Cloudflare 故障時，X 平台也隨之下線。

當你用來「嘲笑單點故障」的平台，本身就是「單點故障」的一部分時，你根本笑不出來。

這種諷刺感，讓本應展開的行業討論從一開始就陷入停滯。

30 天內三次重大故障，監管機構已對此高度關注。

監管層需正視的核心問題

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

第 19 條組織的 Corinne Cath-Speth 在 AWS 上次故障時就直言不諱：「當一家供應商陷入癱瘓，關鍵服務也會隨之下線——媒體無法訪問，Signal 等安全通訊應用停止運轉，支撐數位社會的基礎設施分崩離析。我們迫切需要實現雲運算的多元化。」

換句話說：各國政府正逐漸意識到，少數幾家公司就足以讓網際網路陷入停滯。

其實，去中心化的替代方案早已存在，只是無人願意採用。

比如用於儲存的 Arweave、用於分散式檔案傳輸的 IPFS、用於運算的 Akash、用於去中心化託管的 Filecoin。

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

效能落後於中心化方案，延遲問題用戶能直接感知。

普及率極低，與「點擊『部署到 AWS』」的便捷體驗相比，去中心化方案的用戶操作流程顯得繁瑣複雜。

成本往往高於從「三巨頭」（AWS、Azure、Google Cloud）租賃基礎設施。

現實是：

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

大多數專案只把「去中心化」掛在嘴邊，卻很少真正落地。選擇中心化方案，始終是更簡單、更廉價的選項——直到 18 個月內 4 次故障發生，人們才意識到「簡單廉價」背後隱藏著巨大代價。

OORT 首席執行官 Max Li 博士在近期 CoinDesk 的專欄文章中，直指行業的虛偽性：

「對於一個以『去中心化』為榮、不斷宣揚其優勢的行業而言，卻將自身基礎設施嚴重依賴於脆弱的中心化雲平台，這本身就是一種虛偽。」

他提出的解決方案是：採用混合雲策略，讓交易所將關鍵系統分散部署到去中心化網路中。

中心化雲平台在效能與規模上的優勢，始終有其不可取代性——但當涉及數十億美元資金、每一秒交易都至關重要時，其抗故障能力遠不及分散式方案。

只有當「便利」的代價慘重到足以改變行業行為模式時，「理念」才會戰勝「便利」。

顯然，11 月 18 日的故障還不夠慘重，10 月 20 日的 AWS 故障也不夠，2024 年 7 月的 CrowdStrike 故障同樣不夠。

要到何種地步，「去中心化基礎設施」才會從「話題談資」轉變為「硬性要求」？

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

真正「失敗」的，是行業集體自欺欺人的謊言：以為能在「可癱瘓的基礎設施」上搭建「不可阻擋的應用」；以為當三家公司掌控著「存取通道」時，「抗審查」還有實際意義；以為當 Cloudflare 的一份配置檔案就能決定數百萬人能否交易時，「去中心化」還算得上真正的去中心化。

如果區塊鏈仍在生成區塊，卻沒人能提交交易，那它真的算「在線」嗎？

行業沒有任何應急預案。

出故障了，只能等 Cloudflare 修復，等 AWS 恢復服務，等 Azure 部署補丁。

這就是當前行業的「災難恢復策略」。

不妨設想一下：若數位身份與區塊鏈深度綁定，會發生什麼？

美國財政部正推動將身份憑證嵌入智慧合約，要求每一次 DeFi 互動都必須通過 KYC 審核。

當下一次基礎設施故障發生時，用戶失去的將不只是交易權限——還會失去在金融系統中「證明自己身份」的能力。

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

監管機構想要搭建的「安全護欄」，前提是「基礎設施始終在線」。但 11 月 18 日的故障證明，這個前提根本不成立。

當「過度監控」的問題變得顯而易見時，科技從業者會轉向「隱私保護」。

或許現在，是時候將「基礎設施抗故障能力」也納入這一範疇了。

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

下一次故障已在醞釀之中——可能來自 AWS，可能來自 Azure，可能來自 Google Cloud，也可能是 Cloudflare 的二次故障。

可能是下個月，也可能是下週。基礎設施未變，依賴關係未變，行業激勵機制也未變。

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

當 Cloudflare 下一次常規配置變更，觸發下一個關鍵服務中的隱藏漏洞時，我們將再次目睹熟悉的「劇情」：滿眼的 500 錯誤頁面、交易全面暫停、區塊鏈運轉正常卻無人能存取、想發推文討論「去中心化」卻發現推特已癱瘓、企業承諾「下次會做得更好」卻從未兌現。

一切都不會改變，因為「便利」總能戰勝「風險防範」——直到「便利」的代價大到再也無法忽視的那一天。

這一次，「守門人」癱瘓了 3 個半小時。

下一次，故障可能持續更久；下一次，故障可能發生在「每一秒交易都關乎生死」的市場崩盤時刻；下一次，身份驗證系統可能也會被捲入故障之中。

當你賴以生存的基礎設施，在你最輸不起的時刻陷入癱瘓，這究竟是誰的錯？

數據來源：《衛報》、喬尼・波波夫、《個人電腦雜誌》、《IT 專業人士》、美國消費者新聞與商業頻道（CNBC）、Cloudflare、TechCrunch、美聯社新聞、CoinDesk、《湯姆硬體》、戴恩・克內希特、《湯姆指南》、蘇里亞、綿羊電競、TheBlock、Kraken（kraken）、BitMEX、Ledger（萊傑）、區塊鏈新聞、Statista（數據統計平台）、《嘶吼電腦》、詹姆森・洛普、本・席勒、第 19 條組織、CoinTelegraph（加密電報）