Cloudflareでグローバルネットワーク障害が発生

 (cloudflarestatus.com)
1 ポイント 投稿者 GN⁺ 2025-11-19 | 1件のコメント | WhatsAppで共有
  • Cloudflareのグローバルネットワークで内部サービスの性能低下が発生し、複数のサービスが断続的に影響を受けた
  • Access, Bot Management, CDN/Cache, Dashboard, Firewall, Network, WARP, Workers などの主要サービスが一時的に障害を受けた
  • エンジニアリングチームが問題を特定して修正作業を進め、WARPとAccessサービスが先に復旧した
  • その後、世界的にエラー率と遅延が徐々に通常水準へ回復し、ダッシュボードサービスも復元された
  • 現在はすべてのサービスが正常に稼働しており、事象は完全に解決済み

事象の概要

  • Cloudflareは内部サービスの 性能低下（Internal Service Degradation） に見舞われ、一部サービスが断続的に停止した
    • 影響を受けたサービスには Access, Bot Management, CDN/Cache, Dashboard, Firewall, Network, WARP, Workers などが含まれる
    • 会社は直ちに復旧作業に着手し、問題解決の進捗を継続的に更新した

問題の特定と初動対応

  • Cloudflareは 調査中（Investigating） の段階で内部サービスの低下を確認した
    • 一部の顧客が断続的なエラーと遅延を経験した
    • エンジニアリングチームが原因分析と復旧作業を並行して進めた
  • その後 問題の原因を特定（Identified） し、修正作業を開始した
    • 修正中に ロンドン地域のWARP接続が一時的に無効化 され、当該地域の利用者はインターネット接続の失敗を経験した

サービス復旧の進行

  • 修正作業後、AccessとWARPサービスが先に復旧し、エラー率は事故前の水準へ戻った
    • ロンドン地域のWARP接続は再有効化された
  • その後 Application Servicesの顧客向けサービス復元作業 が続いた
    • ダッシュボードサービス復旧のための変更が配布された
    • なお一部の顧客はログインやダッシュボード利用の問題を経験していたが、追加修正によって解消された

ネットワーク全体の安定化

  • 世界的に エラー率と遅延（latency） が徐々に低下し、通常水準へ回復した
    • Bot Managementのスコア計算（bot scores） が一時的に影響を受けたが、復旧過程で正常化した
    • エンジニアリングチームは残るエラーを取り除き、ネットワーク全体の復旧を加速させた
  • その後、すべてのサービスが正常に動作し、エラー率と遅延は完全に正常化 した

事象の終了と今後の対応

  • Cloudflareは すべてのサービスが正常稼働中 であることを確認し、事象を終了した
    • 現在 追加の構成変更はなく、プラットフォームを綿密に監視している
    • 障害原因に関する 事後調査（post-incident investigation） が進行中で、結果は後日公開予定
  • 今回の障害は グローバルネットワーク全体に影響した事象 として記録された

関連記事

1件のコメント

 
GN⁺ 2025-11-19
Hacker Newsの意見

  • Cloudflare APIトークンを持っている人向けに、CFプロキシを無効化できるコマンドが共有されていた
    curlコマンドでzone IDとDNSレコードを取得し、PATCHリクエストで"proxied": falseに設定すればよい
    ただしSSL証明書の喪失、セキュリティ/性能低下、そしてバックエンドIPの露出リスクがあるので注意が必要

    • 古いGlobal API Keyしかない場合は、X-Auth-EmailとX-Auth-Keyヘッダーを使えばよい
      また、Cloudflareトラフィックのみを許可するよう設定していた人は、そのルールを一時的に無効にする必要がある
    • 次回はこの方法を使おうと思ったが、APIトークンを事前に作成していなかったため待つしかなかった
      幸い、今は再びオンライン状態に復旧している
    • Terraform providerで対処したが、ダッシュボードにアクセスできない人にはこの方法が有用
    • 良いTipsだ。ちなみにcurlではGETリクエストはデフォルトなので-X GETは不要
      -dオプションを使うと自動的にPOSTになり、PATCHには-X PATCHが正しい
    • Cloudflare WARPを有効にすると一部のサイトが再び動作する。1.1.1.1にも似た効果がありそう
      ただしトンネリング後でも一部サイトは依然として部分的にダウンしている

  • CloudflareのCTOによると、ボット遮断システムの潜在バグが設定変更後に暴走し、ネットワーク全体に障害を引き起こしたとのこと
    攻撃ではなく内部問題だったと出典で説明している

    • 大企業がいまだに構成変更を段階的にデプロイしないことに驚く
      コードでも設定でもデータなのに、世界中へ一度に配布して大規模障害になるパターンが繰り返されている
    • こうした重要情報がコメント上部に上がっていてほしかった。サイバー攻撃を推測するコメント群の中では見つけにくかった
    • 設定変更ひとつでCF株が4%下落した。こうした障害が業界全体に与える経済的影響が気になる

  • 同僚が突然駆け寄ってきて、自分がCloudflare設定を変えた直後にサイトが落ちたので、自分が壊したのかと驚いたと言っていた
    この投稿を見て安心したらしい

    • 「それどころかもっと深刻だ、お前がCloudflare全体を落としたんだ」と冗談を言った
    • とはいえ本当に違うのだろうか？ 以前にFastlyの大規模障害もあったので疑いは残る
    • 誰かのミスではなかったと分かったときに感じる奇妙な安堵感にぴったりの単語があるのか気になる
    • もしかするとその同僚はCloudflare社員かもしれない
    • 私もクライアントからサイトが使えないというメッセージを何十件も受け取り、昨日設定を変えたばかりだったので冷や汗をかいた
      「Cloudflare down」というメッセージを見て心底ほっとした

  • オランダで確認したところ、ほぼすべてのサービスがダウンしていた
    Cloudflareダッシュボードにもアクセスできず、Betterstackダッシュボードも同様だった
    皮肉なことにステータスページは生きていたため、顧客に告知できない状況だった

    • 私も同じ体験をした。HNだけが無事だった理由はCloudflareを使っていないからだ
      「必要ないならCloudflareの背後に置くな」というブログ記事を書いた
    • AWSやCloudflareへの過度な依存が危険だと毎年思い知らされるが、代替は簡単ではない
      それでもこうした大規模障害が起きると、顧客は意外と理解を示してくれる
    • Cloudflareダッシュボードが完全に死んでいたわけではなく、しつこく試せばプロキシを切れた
      数分かかったが、hcker.newsをCFから切り離した
    • こういう状況を見ると、ローカルVPSにステータスページを載せるサービスを作ればビジネスチャンスがありそうだ
    • 私のサイドプロジェクトTotal Real Returnsでは
      下部に外部ステータスページと連動したリアルタイム稼働率ウィジェットを設置している
      ステータスSVGと
      外部ステータスページを参照するとよい

  • CloudflareやAWSが止まったとき、私のself-hostedサービスが平然と動いているのを見る快感がある
    彼らの99.999%可用性より、今この瞬間は自分のほうが安定している

    • 私のしょぼい個人サイトもAWS、Azure、Cloudflareの障害時に全部生きていた
      そろそろアップタイムトラッカーを付けようかと思う
    • 私のself-hostedサイトはCloudflareプロキシのせいで逆に落ちた。むなしい
    • 伝統的な企業ではOracleやSAPのようなシステムは平気なのに、新しいクラウドベースのサービスだけ止まる状況が起きている
      新興SaaS企業が学ぶべき教訓だ
    • DNSをどう処理しているのかという質問が多い。私もRaspberry Piでホスティングしているが、DNSをCloudflareへ移した直後だったので
      自分の小さなサイトが落ちたのが面白くもあり妙に満足感もあった

  • 最近、大規模インフラ障害が急増しているように思える。AWSもCloudflareもSLAを大きく下回っている

    • 大企業が大規模レイオフの後にAIで置き換えると言い始めた時期と重なっている
    • こうした障害を通じて、SLAの**「9の数」に意味がないこと**を痛感した
      実際の稼働率ではなく、企業が恣意的に定義した数値にすぎない
    • ある人はこれを「vibe code theory」と呼んでいる。勘で書かれたコードが増えるほどバグや障害も増えるという冗談混じりの理論だ
    • 年末のデプロイ禁止期間とQ4目標のプレッシャーが重なり、急いでデプロイする文化が原因だという分析もある
    • あるいは国家レベルのサイバー攻撃ではないかという陰謀論めいた見方もある

  • CloudflareやAWSが止まるとウェブの半分が止まるという中央集権化の問題は深刻だ

    • ユーザーもあまり気にしていない。「インターネットが止まった」という認識のおかげで、個々のサービスは責任回避ができてしまう
      これが構造が変わらない理由だ
    • DDoS防御には規模の経済が働く。顧客が多いほど帯域幅が増え、防御力も強くなる
      小規模CDNは競争が難しく、結果として自然独占構造が形成される
      Cloudflareが無料プランを提供したのは、こうしたネットワーク効果を狙った戦略だった
    • 単一障害点よりも心配なのは、こうした中央集権化がウェブ標準と自律ホスティングの未来を歪める可能性があることだ
      また、政府検閲の集中ターゲットになる可能性も高い
    • Let's Encryptにも潜在的リスクがある。
      ウェブの2/3が依存し、証明書寿命がますます短くなっており、もしハッキングや障害が発生すればウェブ全体が麻痺しかねない
      今は善良な組織でも、かつてのGoogleもそうだったことを忘れてはならない
    • AWSブーム以降、開発者が専用サーバーではなくクラウドにのみ依存するようになったのが問題だ
      ソフトウェアレベルのバックアップは多いが、インフラレベルのマルチホスティングの常識が失われてしまった

  • 皮肉なことにDownDetectorもCloudflare Turnstileを使っていたため一緒に落ちた

    • AWS障害報告も急増していたが、おそらく誤検知の可能性が高い
    • 私もその現象を見た

  • Cloudflareの「Your browser: Working / Host: Working / Cloudflare: Error」という視覚的な謝罪メッセージが印象的だった

    • こんな画面は初めて見た。ただ私の場合は「Host」がCloudflare Pagesだったので意味がやや曖昧だった
    • 「Cloudflare」をクリックすると、今でも顧客サーバーの問題だと案内するのは少しおかしい
    • 正直なメッセージでよかったが、ユーザーの反応は「Wi-Fiを直してくれ」ばかりだった
    • それでも状況を明確に把握して対応できた。必要ならプロキシを無効化してサービスへの影響を最小化できる
    • 私も1時間ログを掘ってから、自分のサーバーの問題ではないと気づいた

  • Cloudflare Challenge（「I’m not a robot」）を使うサイトもHTTP 500エラーを返して停止した
    「challenges.cloudflare.comのブロックを解除しろ」というメッセージが表示された

    • 最近はエラー処理の水準が低すぎる。企業が責任回避のためにユーザーのせいにしたり、
      無限ローディング画面だけを見せたりする。実際にはバックエンドが明確なエラーを返しているのに、フロントがそれを隠す
      最近では、パスワードが長すぎるというエラーを「メールアドレスはすでに使用中」と表示していた例も見た
    • この障害で**chat.bing.comのAI検索（GPT5）**も止まった
      皮肉にもAIに対して人間であることを証明しなければならない状況になった
    • 一部サイト（pinkbikeなど）は「you have been blocked」というメッセージを表示していた
    • ロボットだけでなく本物の人間もブロックされたわけだ /s
    • フロントエンドは、ユーザーがDNSや拡張機能でドメインをブロックしたと誤認しているようだ
      Cloudflare Captchaがダウンするはずがないという**/s的な否定**が笑える