昨日的中斷顯示了現代網路對少數核心基礎設施提供商的依賴程度。
事實上,這種依賴如此嚴重,以至於一個單一的配置錯誤就使互聯網的大部分區域完全無法訪問數小時。
我們許多人在加密貨幣領域工作是因為我們了解金融中央化的危險,但昨天的事件清楚地提醒我們,互聯網核心的中央化同樣是一個亟待解決的問題。
像 Amazon、Google 和 Microsoft 這樣的巨頭運營著大量的雲端基礎設施。
但同樣重要的是像 Cloudflare、Fastly、Akamai、DigitalOcean 這樣的公司,以及 CDN(在全球範圍內更快地傳遞網站的伺服器)或 DNS(互聯網的「地址簿」)提供商,如 UltraDNS 和 Dyn。
大多數人幾乎不知道它們的名字,但正如我們昨天所見,它們的中斷可能同樣具有破壞性。
首先,這裡列出了一些你可能從未聽說過但對保持互聯網正常運行至關重要的公司。
| 類別 | 公司 | 他們控制什麼 | 如果他們中斷會有什麼影響 |
|---|---|---|---|
| 核心基礎設施 (DNS/CDN/DDoS) | Cloudflare | CDN、DNS、DDoS 保護、Zero Trust、Workers | 全球網路流量的大部分失敗;數千個網站變得無法訪問。 |
| 核心基礎設施 (CDN) | Akamai | 企業 CDN,用於銀行、登錄、商業 | 主要企業服務、銀行和登錄系統崩潰。 |
| 核心基礎設施 (CDN) | Fastly | CDN、邊緣計算 | 全球中斷潛力(如 2021 年所見:Reddit、Shopify、gov.uk、NYT)。 |
| 雲端提供商 | AWS | 計算、託管、存儲、API | SaaS 應用、串流平台、金融科技和物聯網網絡失敗。 |
| 雲端提供商 | Google Cloud | YouTube、Gmail、企業後端 | Google 服務和依賴應用程序的大規模中斷。 |
| 雲端提供商 | Microsoft Azure | 企業和政府雲端 | Office365、Teams、Outlook 和 Xbox Live 中斷。 |
| DNS 基礎設施 | Verisign | .com 和 .net TLD、根 DNS | 網路大部分區域的災難性全球路由故障。 |
| DNS 提供商 | GoDaddy / Cloudflare / Squarespace | 數百萬域名的 DNS 管理 | 整個公司從互聯網上消失。 |
| 憑證授權機構 | Let's Encrypt | 大部分網路的 TLS 憑證 | HTTPS 全球崩潰;用戶到處看到安全錯誤。 |
| 憑證授權機構 | DigiCert / GlobalSign | 企業 SSL | 大型企業網站失去 HTTPS 信任。 |
| 安全 / CDN | Imperva | DDoS、WAF、CDN | 受保護的網站變得無法訪問或易受攻擊。 |
| 負載均衡器 | F5 Networks | 企業負載均衡 | 銀行、醫院和政府服務可能在全國範圍內失敗。 |
| 一級骨幹網 | Lumen (Level 3) | 全球互聯網骨幹 | 路由問題導致全球延遲峰值和區域性中斷。 |
| 一級骨幹網 | Cogent / Zayo / Telia | 傳輸和對等 | 區域或國家級互聯網中斷。 |
| 應用分發 | Apple App Store | iOS 應用更新和安裝 | iOS 應用生態系統實際上凍結。 |
| 應用分發 | Google Play Store | Android 應用分發 | Android 應用無法在全球範圍內安裝或更新。 |
| 支付 | Stripe | 網路支付基礎設施 | 數千個應用失去接受付款的能力。 |
| 身份 / 登錄 | Auth0 / Okta | 認證和 SSO | 數千個應用的登錄中斷。 |
| 通訊 | Twilio | 2FA SMS、OTP、訊息 | 全球大部分 2FA 和 OTP 代碼失敗。 |
昨天的罪魁禍首是 Cloudflare,一家路由近 20% 所有網路流量的公司。
它現在表示,中斷始於一個小型數據庫配置更改,意外導致機器人檢測文件包含重複項目。
該文件突然超出了嚴格的大小限制。當 Cloudflare 的伺服器嘗試加載它時,它們失敗了,許多使用 Cloudflare 的網站開始返回 HTTP 5xx 錯誤(用戶在伺服器崩潰時看到的錯誤代碼)。
以下是簡單的連鎖反應:
Chain of events
問題始於 19:05(UTC +8),當時權限更新使系統在構建用於評分機器人的文件時提取額外的重複信息。
該文件通常包含約六十個項目。重複項目使其超過了 200 的硬上限。當網絡中的機器加載過大的文件時,機器人組件無法啟動,伺服器返回錯誤。
根據 Cloudflare 的說法,當前和較舊的伺服器路徑都受到了影響。一個返回 5xx 錯誤。另一個分配了零的機器人分數,這可能會錯誤地標記那些基於機器人分數(Cloudflare 的機器人與人類檢測)進行阻止的客戶的流量。
診斷很棘手,因為壞文件每五分鐘從正在逐塊更新的數據庫集群重建一次。
如果系統從更新的部分提取,文件就是壞的。如果不是,它就是好的。隨著版本切換,網絡會恢復,然後再次失敗。
根據 Cloudflare 的說法,這種開關模式最初看起來像是可能的 DDoS 攻擊,特別是因為第三方狀態頁面也在同一時間左右失敗。一旦團隊將錯誤與機器人檢測配置聯繫起來,焦點就轉移了。
到 21:05(UTC +8),Cloudflare 為 Workers KV(登錄檢查)和 Cloudflare Access(認證系統)應用了繞過,繞過失敗行為以減少影響。
主要修復是當團隊停止生成和分發新的機器人文件,推送已知良好的文件,並重新啟動核心伺服器。
Cloudflare 表示,核心流量在 22:30(UTC +8)開始流動,所有下游服務在 01:06(UTC +8)恢復。
Cloudflare 的系統強制執行嚴格的限制以保持性能可預測。這有助於避免資源使用失控,但也意味著格式錯誤的內部文件可能觸發硬停止而不是優雅的回退。
因為機器人檢測位於許多服務的主要路徑上,一個模塊的故障級聯到 CDN、安全功能、Turnstile(CAPTCHA 替代品)、Workers KV、Access 和儀表板登錄。Cloudflare 還注意到額外的延遲,因為調試工具在添加錯誤上下文時消耗 CPU。
在數據庫方面,一個狹窄的權限調整產生了廣泛的影響。
這一變化使系統"看到"比以前更多的表。構建機器人檢測文件的作業過濾不夠嚴格,因此它抓取了重複的列名並將文件擴展到超過 200 項的上限。
然後,加載錯誤觸發了伺服器故障,並在受影響的路徑上返回 5xx 響應。
影響因產品而異。核心 CDN 和安全服務拋出伺服器錯誤。
Workers KV 看到 5xx 率升高,因為對其網關的請求通過失敗的路徑。Cloudflare Access 在 21:05(UTC +8)繞過之前出現認證失敗,當 Turnstile 無法加載時,儀表板登錄中斷。
Cloudflare 電子郵件安全暫時失去了 IP 信譽來源,在一段時間內降低了垃圾郵件檢測準確性,不過公司表示沒有關鍵客戶影響。在恢復良好文件後,登錄嘗試的積壓短暫地使內部 API 承受壓力,然後恢復正常。
數據庫更改在 19:05(UTC +8)落地。第一個面向客戶的錯誤出現在 19:20-19:28(UTC +8)左右。
團隊在 19:35(UTC +8)開啟了一個事件,在 21:05(UTC +8)應用了 Workers KV 和 Access 繞過,在 22:24(UTC +8)左右停止創建和傳播新文件,推送已知良好的文件並在 22:30(UTC +8)看到全球恢復,並在 01:06(UTC +8)標記完全恢復。
根據 Cloudflare 的說法,自動測試在 19:31(UTC


