2025 年 6 月 12 日，Cloudflare 遭受了一次重大服務中斷，影響了我們一系列關鍵服務，包括 Workers KV、WARP、Access、Gateway、Images、Stream、Workers AI、Turnstile and Challenges、AutoRAG、Zaraz 以及 Cloudflare 儀表板的部分內容。
此次服務中斷持續了 2 小時 28 分鐘，全球所有使用受影響服務的 Cloudflare 客戶均受到影響。這次服務中斷的原因是我們的 Workers KV 服務所使用的底層儲存基礎架構發生故障。該服務是許多 Cloudflare 產品的關鍵相依項，受影響服務之間的設定、驗證和資產交都依賴於與此。該基礎架構的一部分由第三方雲端提供者提供支援，而該提供者今天發生了中斷，直接影響了我們 KV 服務的可用性。
我們對本次服務中斷深表歉意：這是我們一方的失誤，雖然這次中斷的直接原因（或觸發因素）是第三方廠商的故障，但我們對所選的相依項及圍繞其設計的架構方式負有最終責任。
這不是由攻擊或其他安全事件引起的結果。此事件並未導致任何資料遺失。Cloudflare Magic Transit 和 Magic WAN、DNS、快取、代理、WAF 及相關服務並未直接受到此事件的影響。
通常，Cloudflare 會在我們自己的平台基礎上設計和建置服務，因此，許多 Cloudflare 的產品都依賴於 Workers KV 服務。
下表詳細列出了受影響的服務，包括對使用者的影響、操作失敗以及觀察到的錯誤率增加：
產品/服務 | 影響 |
|---|
Workers KV
| Workers KV 的請求失敗率達到 90.22%：任何未被快取且需要從 Workers KV 的來源儲存體後端擷取值的鍵值對都會導致請求失敗，回傳回應碼 503 或 500。 其餘請求成功從 Workers KV 的快取中提供服務（狀態代碼 200 和 404），或傳回的錯誤在我們的預期範圍和錯誤預算內。 這沒有影響儲存在 Workers KV 中的資料。 |
Access
| Access 使用 Workers KV 來儲存應用程式和政策設定以及使用者身分資訊。 在事件期間，對於所有應用程式類型（包括自托管、SaaS 和基礎架構）的基於身分的登入，Access 的失敗率為 100%。在本次事件中，使用者識別資訊無法提供給 WARP 和 Gateway 等其他服務。Access 設計為在無法成功取得政策設定或使用者身分時自動關閉。 由於一個 Workers KV 相依項，啟用命令記錄的活動基礎架構應用程式 SSH 工作階段無法儲存記錄。 Access 的跨網域識別系統 (SCIM) 服務也受到影響，因為它依賴 Workers KV 和 Durable Objects（依賴於 KV）來儲存使用者資訊。在此事件中，由於 Workers KV 更新失敗，使用者身分未更新。這些失敗導致向身分識別提供者傳回 500。某些提供者可能需要手動重新同步，但由於身分識別提供者的重試邏輯，大多數客戶在 Access 的 SCIM 服務恢復後會立即看到服務恢復。 基於服務驗證的登入（例如服務權杖、Mutual TLS 和基於 IP 的原則）以及繞過政策未受影響。在此期間，Access 原則的編輯或變更沒有遺失。 |
閘道
| 此事件並未影響大多數 Gateway DNS 查詢，包括透過 IPv4、IPv6、DNS over TLS (DoT) 和 DNS over HTTPS (DoH) 進行的查詢。 然而，有兩個例外： 使用身分型規則的 DoH 查詢失敗。發生這種情況的原因是，Gateway 無法擷取所需的使用者身分資訊。 部分使用者的已驗證 DoH 服務中斷。具有有效驗證權杖的作用中工作階段的使用者不受影響，但那些需要啟動新工作階段或重新整理驗證權杖的使用者則無法完成操作。 使用 Gateway 代理、輸出和 TLS 解密的使用者無法連接、註冊、代理或記錄流量。 這是因為我們依賴 Workers KV 來擷取最新的身分和裝置狀態資訊。所有這些動作都需要呼叫 Workers KV，當 Workers KV 不可用時，Gateway 設計為自動關閉以防止流量繞過客戶設定的規則。 |
WARP
| WARP 用戶端受到影響，因為其核心依賴 Access 和 Workers KV，後兩者是裝置註冊和驗證所必需的。因此，事件發生期間沒有新的用戶端能夠連線或註冊。 透過 Gateway 代理路由的現有 WARP 用戶端使用者工作階段遭遇中斷，因為 Gateway 無法執行其所需的原則評估。 此外，由於其基礎相依項 Workers KV 發生故障，WARP 緊急斷開覆寫變得不可用。 Consumer WARP 也經歷了與 Zero Trust 版本類似的間歇性影響。 |
儀表板
| 儀表板使用者登入和大部分現有的儀表板工作階段都無法使用。這是因為服務中斷影響了 Turnstile、DO、KV 和 Access。登入失敗的具體原因是： 標準登入（使用者/密碼）：由於 Turnstile 無法使用而失敗。 使用 Google 登入 (OIDC)：因為 KV 相依性問題而失敗。 SSO 登入：因完全依賴 Access 而失敗。 Cloudflare v4 API 在此次事件中未受影響。 |
Challenges 與 Turnstile
| 在事件發生期間，由於依賴 Workers KV 和 Durable Objects，支援 Cloudflare Challenges 和 Turnstile 的 Challenge 平台上，siteverify API 請求的失敗和逾時率達到較高水準。 我們設定了緊急開關，以便在發生此類事件和中斷時停用這些呼叫。我們啟動了這些緊急開關作為一種緩解措施，以確保使用者不會被阻止繼續存取。值得注意的是，當這些緊急開關啟用時，Turnstile 的 siteverify API（驗證已發佈權杖的 API）可以多次兌換有效權杖，這可能允許攻擊者嘗試使用先前有效的權杖來繞過。 Turnstile 偵測機器人的能力沒有受到影響。嘗試解決質詢的機器人仍然會失敗，因此不會收到權杖。 |
瀏覽器隔離
| 由於依賴 Gateway 進行原則評估，基於連結隔離的現有瀏覽器隔離工作階段受到影響。 由於依賴 Cloudflare Access，無法啟動新的基於連結的瀏覽器隔離工作階段。所有由 Gateway 發起的隔離工作階段都因其對 Gateway 的依賴而失敗。 |
Images
| 在事件期間，上傳到 Cloudflare Images 的操作受到影響，事件高峰時失敗率達到 100%。 整體影像傳遞成功率降至約 97%。Image Transformations 未受到重大影響，Polish 也未受影響。 |
Stream
| 在事件期間，Stream 的錯誤率超過了 90%，因為無法提供影片播放清單。Stream Live 觀察到的錯誤率為 100%。 影片上傳未受影響。 |
Realtime
| Realtime TURN（使用中繼繞過 NAT）服務使用 KV，受到嚴重影響。在整個事件期間，錯誤率接近 100%。 儘管維持了現有連線，但 Realtime SFU 服務（選擇性轉送單元）無法建立新工作階段。這導致事件期間的正常流量減少至 20%。 |
Workers AI
| 在事件期間，所有前往 Workers AI 的推斷請求均失敗。Workers AI 依賴 Workers KV 在全球範圍內分發 AI 請求的設定和路由資訊。 |
Pages 和 Workers Assets
| 由 Cloudflare Pages 和 Workers Assets 提供的靜態資產（例如 HTML、JavaScript、CSS、影像等）都儲存在 Workers KV 中、進行快取，並在請求時擷取。在此期間，Workers Assets 的平均錯誤率約增加了總請求量的 0.06%。 在此事件期間，Pages 錯誤率峰值達到約 100%，且所有 Pages 建置均無法完成。 |
AutoRAG
| AutoRAG 依賴 Workers AI 模型在索引期間進行文件轉換及產生向量嵌入，並依賴 LLM 模型進行查詢及搜尋。由於對 Workers AI 的相依性，AutoRAG 在事件期間無法使用。 |
Durable Objects
| 由 SQLite 提供支援的 Durable Objects 與 Workers KV 共用相同的底層儲存基礎架構。事件期間的平均錯誤率峰值達到 22%，隨著服務開始恢復而降至 2%。 使用舊版鍵值儲存體的 Durable Object 命名空間未受影響。 |
D1
| D1 資料庫與 Workers KV 和 Durable Objects 共用相同的底層儲存基礎架構。 與 Durable Objects 類似，事件期間的平均錯誤率峰值達到 22%，並隨著服務開始恢復而降至 2%。 |
Queues 與 Event Notifications
| 在事件發生期間，Queues 訊息操作（包括推送和取用）不可用。 Queues 使用 KV 將每個佇列對應到包含佇列訊息的底層 Durable Objects。 Event Notifications 使用 Queues 作為其底層傳遞機制。 |
AI Gateway
| AI Gateway 建立在 Workers 之上，並依賴 Workers KV 進行用戶端和內部設定。在事件期間，AI Gateway 的請求錯誤率峰值達到 97%，直到依賴項恢復。 |
CDN
| 自動化流量管理基礎架構在影響期間仍然運作，但效率有所降低。特別是，來自 Zero Trust 用戶端的註冊請求因服務中斷而大幅增加。 請求增加在數個 Cloudflare 地點造成了額外負載，觸發了自動化流量管理的回應。針對這些情況，系統將傳入的 CDN 流量重新路由到附近地點，以減少對客戶的影響。有一部分流量未如預期重新路由，目前正在調查中。受該問題影響的 CDN 請求將會經歷延遲增加、HTTP 499 錯誤和/或 HTTP 503 錯誤。受影響的 Cloudflare 服務區域包括聖保羅、費城、亞特蘭大和羅利。 |
Workers/Workers for Platforms
| Workers 和 Workers for Platforms 依賴第三方服務進行上傳。在事件期間，Workers 的整體錯誤率峰值達到約佔請求總數的 2%。在同一時間段內，Workers for Platforms 的整體錯誤率高峰達到了總請求量的約 10%。 |
Workers Builds (CI/CD)
| 從 18:03 UTC 開始，由於 Access 故障，Workers Builds 無法接收新的原始碼管理推播事件。 在事件期間，100% 的新 Workers Builds 失敗。 |
Browser Rendering
| Browser Rendering 依賴於瀏覽器隔離來支援瀏覽器執行個體基礎架構。 在事件發生期間，對 REST API 和透過 Workers Browser Binding 的請求均 100% 受到影響。 |
Zaraz
| 事件發生期間，100% 的請求受到了影響。Zaraz 在處理終端使用者流量時依賴 Workers KV 設定。由於相同的依賴關係，在此期間儲存對 Zaraz 設定的更新嘗試未能成功，但我們的監控顯示僅有一位使用者受到影響。 |
Workers KV 是我們所稱的「無核心」服務，這意味著該服務在全球每個地點獨立執行，因此不應存在單一失敗點。然而，Workers KV 如今依賴中央資料儲存區來提供資料的真實性來源。該儲存區故障導致 Cloudflare 服務使用的 KV 命名空間的冷讀取和寫入完全中斷。
Workers KV 正在將其中央儲存區過渡到更具彈性的基礎架構，遺憾的是，我們的覆蓋範圍出現了缺口，並在此次事件中暴露出來。在我們重新設計 KV 的後端（包括將其遷移到 Cloudflare R2）時，Workers KV 移除了某個儲存提供者，以防止資料一致性問題（由原始資料同步架構引起），並改善對資料駐留要求的支援。
我們的原則之一是盡可能在我們自己的平台上建置 Cloudflare 服務，Workers KV 也不例外。我們的許多內部和外部服務都非常依賴 Workers KV。在正常情況下，這有助於我們提供最強大的服務，而不是讓服務團隊嘗試建立自己的儲存服務。在此情況下，Workers KV 故障所引發的連鎖影響加劇了問題，並顯著擴大了影響範圍。
事件時間表，包括初步影響、調查、根本原因和補救措施，詳述如下。
Workers KV 對儲存基礎架構請求的錯誤率。在事件時段內，對 KV 的請求有 91% 失敗。
Cloudflare Access 成功請求的百分比。Cloudflare Access 直接依賴 Workers KV，是衡量 Workers KV 可用性隨時間變化的有效代表。
所有時間戳記均為世界標准時間 (UTC)。
時間 | 活動 |
|---|
2025-06-12 17:52 | 事件開始
Cloudflare WARP 團隊發現新裝置註冊失敗，開始調查這些失敗並宣佈發生了事件。 |
2025-06-12 18:05 | 由於錯誤率快速增加，Cloudflare Access 團隊收到了警示。 多項服務的服務等級目標下降至至預期水準以下並觸發各團隊的警示。 |
2025-06-12 18:06 | 隨著我們確定一個共同原因（Workers KV 不可用），多個服務特定事件被合併為一個事件。事件優先級上升到 P1。 |
2025-06-12 18:21 | 由於影響的嚴重性變得明顯，事件優先級從 P1 升級為 P0。 |
2025-06-12 18:43 | Cloudflare Access 開始與 Workers KV 工程團隊合作，探索遷移到其他後端資料存放區的方案，以消除對 Workers KV 的依賴。這是為了防止儲存基礎架構繼續當機而採取的主動措施。 |
2025-06-12 19:09 | Zero Trust Gateway 開始透過適當降級參照身分識別或裝置狀態的規則，努力移除對 Workers KV 的依賴。 |
2025-06-12 19:32 | 存取和裝置狀態強制丟棄身分識別和裝置狀態請求，以在第三方服務重新上線之前減輕 Workers KV 上的負載。 |
2025-06-12 19:45 | Cloudflare 團隊繼續尋找方法，以便在替代的後端資料存放區上部署 Workers KV 發行版，並讓關鍵服務將設定資料寫入該存放區。 |
2025-06-12 20:23 | 隨著儲存基礎架構開始復原，服務也開始復原。由於服務大量湧入並重新填充快取，我們繼續看到不可忽略的錯誤率和基礎架構速率限制。 |
2025-06-12 20:25 | 隨著第三方服務恢復，Access 和裝置狀態恢復呼叫 Workers KV。 |
2025-06-12 20:28 | 影響結束
服務等級目標恢復到事件發生前的等級。Cloudflare 團隊持續監控系統，以確保服務在依賴系統復原時不會降級。 |
| 事件結束
Cloudflare 團隊看到所有受影響的服務恢復正常運作。服務等級目標警示解除。 |
我們正在採取措施，為依賴 Workers KV 和我們的儲存基礎架構的服務提高韌性。這包括由於此次事件而加速進行的現有計劃內工作。
這涵蓋了多個工作流，包括努力避免對我們不擁有的儲存基礎架構的單一依賴，提高我們恢復關鍵服務（包括 Access、Gateway 和 WARP）的能力
具體而言：
（積極進行中）：推動我們在 Workers KV 儲存基礎架構中提高備援的工作，消除對任何單一提供者的依賴。在事件發生期間，我們開始將關鍵的 KV 命名空間切換並回填到我們自己的基礎架構中，以防止事件繼續。
（積極進行中）：對本事件中受影響的各個產品進行短期影響範圍的補救，以確保每個產品都具備抵禦任何單一失敗點（包括第三方依賴）所致服務中斷的能力。
（積極進行中）：實作一些工具，以便在儲存基礎架構發生故障時，逐步重新啟用命名空間。這將使我們能夠確保包括 Access 和 WARP 在內的關鍵依賴服務能夠恢復運作，而不會因快取重新填充而對我們自己的基礎架構造成阻斷服務的風險。
這份清單並不詳盡：我們的團隊將繼續重新審視設計決策，並評估我們需要在近期（立即）和長期進行的基礎架構變更，以防止未來再次發生此類事件。
這是一次嚴重的服務中斷，我們明白，大大小小的組織和機構依賴我們來保護及/或執行他們的網站、應用程式、Zero Trust 和網路基礎架構。我們再次對造成的影響深感抱歉，並正在努力提高我們的服務韌性。