背景

2026 年 2 月 20 日，Cloudflare 發生了一場持續超過 6 小時的服務中斷，主因是其「自帶 IP」（BYOIP）系統在執行自動化更新時，因軟體錯誤導致全球約 25% 的客戶前綴（prefixes）被錯誤撤回。這起事故不僅影響了企業客戶，連 Cloudflare 旗下的 1.1.1.1 公共 DNS 服務也受到波及，暴露出自動化管理系統在處理大規模網路路由時的潛在風險。

社群觀點

在 Hacker News 的討論中，社群對於 Cloudflare 的透明度給予了兩極的評價。部分用戶讚賞 Cloudflare 詳盡的事故檢討報告（RCA），認為比起微軟 Azure 等廠商傾向於隱瞞故障或維持狀態頁面「常綠」的做法，Cloudflare 願意公開技術細節並承認錯誤，對於建立長期信任至關重要。然而，另一派觀點則認為這種「透明度紅利」已經逐漸耗盡。有評論指出，企業客戶最終在乎的是服務層級協議（SLA）與穩定性，而非事後的道歉與技術分析。特別是 Cloudflare 在過去半年內頻繁發生網路中斷，這讓不少人質疑其工程文化是否過度追求快速上線新功能，而忽略了基礎設施的穩健性。

針對技術細節，社群展開了激烈的辯論。有工程師質疑 Cloudflare 的測試流程存在嚴重漏洞，認為在預發布環境（Staging）中顯然缺乏足夠的模擬數據，否則這種「空值導致全選刪除」的邏輯錯誤在單元測試或整合測試階段就該被攔截。更有資深開發者直指，這次事故的諷刺之處在於它源自一項名為「Code Orange」的縮小故障範圍計畫，結果卻造成了更大規模的災難。此外，部分留言者對部落格文章中提供的程式碼片段表示懷疑，認為其邏輯解釋與實際程式碼不符，甚至懷疑部分內容是由人工智慧生成，或是為了趕在第一時間發布而未經嚴謹審核。

關於 Cloudflare 近期穩定性下滑的原因，社群也提出了一些結構性的觀察。有人提到前任技術長 John Graham-Cumming 離職後，公司的技術方向可能產生了偏移，導致工程團隊在資源分配上過於分散。隨著 Cloudflare 不斷推出如 Workers、R2 等新服務，其底層網路的複雜度呈幾何倍數增長，這使得任何微小的自動化腳本錯誤都可能演變成全球性的連鎖反應。更有受影響的客戶在留言中反駁官方說法，指出在事故期間即便手動恢復前綴，系統仍會反覆撤回路由，認為官方報告在描述自我修復的難度上有所隱瞞。

延伸閱讀

• Hacker News 歷史討論紀錄：搜尋 Cloudflare 歷年來的事故報告與工程文化討論。
• Cloudflare Terraform Provider 更新爭議：社群提到的另一個關於該公司工具鏈穩定性的討論熱點。