Cloudflare 2025年12月5日の障害

• 2025年12月5日08:47 UTCにCloudflareネットワークの一部で重大な障害が発生し、約25分後の09:12に完全復旧した
• 全体の**HTTPトラフィックの約28%**が影響を受け、特定の条件を満たす顧客のみが障害を体験
• 原因はReact Server Components脆弱性（CVE-2025-55182）対応のために行ったWAF（本文パースロジック）変更で、サイバー攻撃とは無関係
• FL1プロキシのコードエラーによりHTTP 500エラーが発生し、新しいRustベースのFL2プロキシでは同様のエラーは発生しなかった
• Cloudflareは11月18日の障害後も同様の問題が再発した点を認め、デプロイの安全性と回復力強化プロジェクトを最優先課題として進めている

---

障害概要

• 2025年12月5日08:47 UTCにCloudflareネットワークの一部で障害が発生
  • 09:12に全サービスが復旧し、影響は25分間
  • 全体のHTTPトラフィックの約28%が影響を受けた
• 障害はサイバー攻撃や悪意のある行為とは無関係で、内部設定変更中に発生
• React Server Componentsの新しい脆弱性対応のためのWAF本文のパースロジック修正が原因

障害原因と技術的背景

• Cloudflare WAFは悪意あるペイロードの検知のため、HTTPリクエスト本文をメモリ上でバッファリングする
  • 既存のバッファサイズを128KBから1MBへ拡張中だった
• 内部テストツールが新しいバッファサイズをサポートしていなかったため、テストツールを無効化する2回目の変更を実施
  • この変更はグローバル設定システムを通じて即座に全サーバへ展開
• FL1プロキシでこの変更がエラー状態を引き起こし、HTTP 500応答が発生
  • エラーメッセージ: attempt to index field 'execute' (a nil value)
• 問題は即座に特定され、09:12に変更がロールバックされた

影響範囲

• FL1プロキシを使用し、Cloudflare Managed Rulesetを適用している顧客のみ影響
  • 対象サイトのすべてのリクエストがHTTP 500エラーを返却
  • /cdn-cgi/traceなど一部のテストエンドポイントは例外
• 中国のネットワークおよび他の構成の顧客には影響なし

ランタイムエラーの詳細

• Cloudflareのrulesetsシステムは、リクエストごとにルールを評価する
  • ルールはフィルターとアクションで構成され、executeアクションは他のルールセットを呼び出す
• 内部ロギングシステムがexecuteを使ってテストルールを評価
• killswitchシステムは誤作動ルールを無効化するよう設計されているが、
  • executeアクションを含むルールへのkillswitch適用は今回が初めて
• executeオブジェクトが存在しない状態でアクセスしようとしたためLuaエラーが発生
• このエラーは数年間存在していたが検知されなかった単純なコードバグ
  • Rustで実装されたFL2プロキシでは同じエラーは発生しない

11月18日障害後の改善進捗

• 11月18日にも同様のグローバルデプロイによる大規模障害が発生
• 当時、顧客数百社と直接連携し、単一更新の全社展開防止計画を共有
• その改善作業がまだ完了しておらず、今回の障害に影響
• Cloudflareはこれを会社全体の最優先課題として設定

進行中の回復力強化プロジェクト

• Enhanced Rollouts & Versioning
  • 脅威対応データおよび設定変更にも段階的デプロイ・健全性検証・即時ロールバック機能を適用
• Streamlined Break Glass Capabilities
  • 内部サービスとコントロールプレーン間の相互作用時にも緊急時操作の実行可能性を確保
• Fail-Openエラー処理
  • 設定ファイルのエラー時にリクエストをブロックせず、デフォルトの正常状態へ切り替えるかトラフィックを通過
  • 一部のサービスではfail-open/fail-closedの選択肢を提供予定
• 来週までにすべての回復力プロジェクトの詳細を公開予定
• それまで**ネットワーク変更を全面停止（ロックダウン）**した状態を維持

タイムライン（UTC）

• 08:47 – 構成変更のデプロイを開始し、ネットワークへ展開
• 08:48 – 全体への影響発生
• 08:50 – 自動アラートでインシデント宣言
• 09:11 – 変更のロールバックを開始
• 09:12 – 復旧完了、全トラフィックが正常化

結論

• Cloudflareは2回連続した障害の重大性を認め、顧客およびインターネット全体に謝罪
• 今後、デプロイの安全性、許容エラー、レジリエンス強化を通じて同様の事故防止を進める

[GN⁺]

Hacker Newsの意見

• 今回のCloudflare障害は単なるLuaのバグではなく、根本的なアーキテクチャの問題を露呈した出来事だとする意見。 本来の分散型Web構造は、このようなグローバル障害にはるかに強かった。一方、Cloudflareのような同質的な中央集権システムでは、たった一度のミスで世界中のサービスが同時に止まりうる。Rustで書いても人はミスをする。結局重要なのは堅牢な設計だという指摘。

  • 結局、CloudflareやAWSのような巨大事業者に依存するほど、Webの安定性は下がるという話になる
  • 「スズメバチ1,000匹 vs 犬1匹」という比喩のように、グローバル障害でもローカル障害でも、違うのは苦しみ方だけだという見方もある。Cloudflareが止まれば何百人ものエンジニアが即座に対応するが、自分のサーバーが止まった場合、担当者は山奥の別荘にいるかもしれない
  • 独占が悪いかどうかという議論は脇に置くとして、Cloudflareの長期的な稼働率を見ると、個々のサイトが自前でインフラを運用するよりむしろ良いという意見もある。すべてのサービスが同時に1時間止まる方が、それぞれが別々に1時間ずつ止まるより、利用者の立場ではましだという理屈。ただしCloudflareの安定性が平均以下に落ちるなら、その価値は消える
  • 毎秒8,000万リクエストを処理する規模なら、そもそもひとつの製品がここまで巨大化する構造自体が問題だと思う
  • Cloudflareは今なお、世界のどこでも最速でグローバルインフラを復旧できる企業のひとつだという評価もある。今回も28%のネットワーク障害を25分で解消し、他のクラウドよりダウンタイムが客観的に少ない

• 昨夜、複数のサイトでCloudflareの500エラーを見たが、ステータスページには何の言及もなく、予定メンテナンスの告知しかなかったという指摘。

  • 多くのステータスページがそうであるように、実際の問題を認識して更新するまでには時間がかかる。完全自動化されるまではCloudflareも例外ではない。さらに気になるのは、最近AWS、Azure、Cloudflareが立て続けに落ちている点だという声もある。LLM利用の増加、人手不足、パンデミックの余波、政治的不安などが複合的に作用しているのではないかという直感も語られている
  • こうしたステータスページの問題は、公の批判を通じてしか改善されないのではないかという意見もある。「Cloudflareは障害検知すらまともにできていない」というフィードバックがもっと増えるべきだとする声

• Cloudflareの品質エンジニアリングが開発速度に追いついていないように見えるという意見。昔の防衛産業では品質チームの方が常に熟練していたと聞くが、ソフトウェア業界は逆のようだという話。

  • 防衛産業でもメモリリークを把握しながら、「使用時間内なら問題ない」として無視したことがあったという逸話を思い出すという声
  • こういうことが月に2回起きているのに、「褒められる話ではない」という指摘もある。繰り返しには言い訳の余地がない

• インターネットのパケットスイッチング構造は、もともとこのようなグローバル障害に耐えるよう設計されていたという指摘。 冷戦時代のDARPAネットワークには、核攻撃下でも指揮系統を維持する目的があった。 今こそインターネットの**ローカルファースト(local-first)**パラダイムに戻るべきだという意見。

  • 参考: The Real Internet Architecture
  • 参考: Local-first software

• 最近のCloudflareはインターネットをより遅く不便にしているように感じるという声。「あなたが人間であることを証明してください」のような手順が増え、ページ読み込みも遅くなっている。 これはサイト保護というより、AIクローリング課金ポリシーのためではないかという見方がある（Pay-per-crawl紹介）

  • こうした人間確認の手順が旧式ブラウザと互換性がなく、そもそもアクセスできないサイトまで出てきている
  • ただし、AIが無断でコンテンツをクロールしていくのも問題だという反論もある。Cloudflareはサイト管理者にコンテンツ保護オプションを提供しているだけで、望まなければ無効化もできる
  • 「もうこっそり監視すらできなくなったのか」という皮肉も出ている

• Cloudflareのグローバル設定システムは、段階的ロールアウトなしに数秒でネットワーク全体へ広がる構造なので危険だという指摘。 設定変更がエラーを起こした際、即座に相関を把握できる仕組みが必要だとされる。

  • 問題はアラートがあまりに遅かったことだという声。通知は2分で来たが、秒単位で検知されるべきだった。 デプロイ担当者はリアルタイム指標を見ながら即座にロールバックボタンを押すべきだった。 コードの行番号までログに明確に出ていたのに、デプロイ担当チームとコード理解チームが分断されていたようだという指摘
  • 警告サインを見てロールバックを試みたが、その過程自体がかえって問題を引き起こしたようだという見方
  • 内部ツールはしばしば誤検知が多く、それ自体が壊れていることも多い
  • 「エンジン警告灯がずっと点くので、電球を抜いた」というジョークのようだという反応

• Cloudflareの稼働率が99.9%を下回ったという指摘。自宅のPCより悪いレベルだという声もある。

  • AWSも同じだという意見。クラウドの存在意義が「より高い可用性」にあるのなら、高価で不安定ならセルフホスティングする理由は十分にある
  • ただし自前運用では、ハードウェア故障やバックアップ失敗時に復旧まで数日かかることもありうる
  • 地域停電が多い場所では、ノートPCとバッテリーでしのぐのも難しい。ときには自給自足型インフラを夢見ることもあるという声
  • 現在のCloudflareの正確なアップタイム統計をどこで確認できるのか知りたいという質問
  • それでも、個人PCとCloudflareを単純比較するのは無意味な比喩だという指摘もある

• Cloudflareほどの規模なら、必ずテスト環境があるべきだという意見。 すべての変更は隔離されたモデル環境でシミュレーションしたうえで、段階的にデプロイすべきだとされる。 強い型システムより重要なのは、手続き上の安全装置だという主張。

  • ある会社では、開発 → 社内統合 → 本番という3段階デプロイ体制を使っているという例もある。 ミスの多いチームは速度を落とし、信頼性の高いチームは速く進める。 結局、技術的な速度は選択の問題であり、SLAが脅かされるなら速度を下げてテストを強化すべきだという話
  • 無料ユーザーをテストベッドとして使い、有料顧客には安定版を提供するのも一案だという意見
  • 「強い型システムがあなたを救ってくれるわけではない」という言葉は、手続き上の失敗の前では言語仕様も無力だという意味だと説明されている

• Cloudflareのソフトウェア品質が揺らいでいるように見えるという声。 エンタープライズ専用機能のアクセス検証が最後の段階でしか行われないバグもあったという。

  • 自分もCloudflare APIでロールバック不可能な設定を経験したという投稿がある。 サポートチームを通さないと変更できず、修正まで数日かかったという。 関連事例リンク
  • こういうバグはAIが書いたコードである可能性もあると見る声
  • 「最後の段階でしかチェックしない」とはどういう意味なのか、もっと具体的に聞きたいという反応

• Cloudflareの運用文化が気になるという意見。 セキュリティ問題への対応中にエラーが起きたのに、ロールバックせず再びグローバルデプロイを行ったのは危険な判断だという。 「怪しければロールバックせよ」という基本原則に反しているという指摘。

  • ただし今回は、React ServerのRCE脆弱性対応のような緊急事態だったという事情もある。 デプロイを遅らせれば顧客が実際にハッキングされる可能性があったため、速度そのものがセキュリティになるケースだったという見方
  • ロールバックが常に正解とは限らない。手順に慣れていなければ、それ自体がリスクになる
  • 実際には2回のデプロイは別々のコンポーネントだったという指摘もある。 最初の修正が2つ目の潜在バグを露呈させた形で、**ロールバックよりロールフォワード(roll forward)**の方が現実的な場合もある
  • Cloudflareは急成長の過程で技術的負債を積み上げてきた可能性が高い。 最近の頻発する障害は、その負債が表面化している兆候かもしれない