2025年12月5日、世界中のWebサイトで「500 Internal Server Error（500内部サーバーエラー）」が一斉発生し、「またCloudflareか…」とSNSや技術フォーラムがざわつきました。
とくに、投資アプリやAIサービス、SaaSを仕事で使っている人にとっては、たった20〜30分でも業務インパクトがかなり大きかったはずです。(Cyber Security News)

この記事では、
・何が起きたのか（発生日時・影響範囲）
・エラーコード500の意味
・公式が説明した「本当の原因」
・一般ユーザーと企業側、それぞれの「今すぐの対処」
・同日に報じられたCoinMinerやMuddyWaterの攻撃ニュースとの関係

を整理しつつ、みんなで議論できるような“フォーラム風”に噛み砕いてまとめていきます。
「自分のところではこうだったよ」という話も、ぜひコメント欄に投げるつもりで読んでみてください。

Cloudflare 500 Internal Server Error 障害の概要

2025年12月5日（UTC 08:47〜09:12ごろ）、Cloudflareのネットワーク障害により、世界のHTTPトラフィックの約28％で「500 Internal Server Error（内部サーバーエラー）」が発生したと公式に説明されています。 (The Cloudflare Blog)

サイバーセキュリティ系メディアのCyber Security Newsは、この障害について
・Cloudflareのダッシュボード（Dashboard：管理画面）やAPI（アプリケーションプログラミングインターフェース）が広範囲にエラーを返した
・管理ツールや自動化連携（オートメーション）が使えなくなり、多くの企業ユーザーが操作不能になった
と報じています。(Cyber Security News)

面白い（というか怖い）のは、エッジ側のCDN（コンテンツデリバリーネットワーク）やWAF（Web Application Firewall：Webアプリケーションファイアウォール）などの基本的な配信・防御そのものは動いていた一方で、「コントロールプレーン」が壊れた点です。設定変更やAPI連携が出来ないので、トラフィックは一応流れているのに、何かあっても守備位置を動かせない、そんな状態でした。(Cyber Security News)

Cloudflareはステータスページで「500エラーが広範囲に発生している」「ダッシュボードとAPIも失敗している」と告知し、障害発生から約25分後に「修正を適用し、監視中」とアナウンスしています。(Cyber Security News)

発生日時・影響範囲と、今回見えた“ヤバさ”のレベル

今回の障害は約25分で復旧したものの、影響を受けたのはCloudflare全HTTPトラフィックの約28％で、LinkedInやZoom、Canva、各種ECやAIサービスなど多数の大手サービスが巻き込まれました。 (The Cloudflare Blog)

Cloudflareの公式ポストモーテムによると、
・障害開始：2025年12月5日 08:47 UTC
・影響がピークに達したのはほぼ直後
・09:12 UTC に設定変更をロールバックし、全トラフィックが正常化
というタイムラインが公開されています。(The Cloudflare Blog)

報道各社やCyber Security Newsのまとめでは、今回の障害で問題が出たサービスとして、例えば次のような名前が挙がっています。(Cyber Security News)

・インドの証券アプリ：Zerodha、Groww、Angel One など
・デザインツール：Canva
・AIサービス：Claude、Perplexity
・障害監視サイト：Downdetector
・ビジネス向けSaaS：LinkedIn、Zoom、Shopify など

「Cloudflareがちょっとコケると、仕事道具が一気に使えなくなる」ことを、実感をもって味わった人も多かったはずです。
しかも、2025年11月18日にもCloudflareは大規模障害を起こしており、そのときも世界中で500系エラーが大量発生していました。(The Cloudflare Blog)

エラーコード「500 Internal Server Error」とは何か

「500 Internal Server Error（内部サーバーエラー）」は、“クライアント側ではなくサーバー側のどこかで想定外のエラーが起きた”ことを知らせる非常に汎用的なHTTPステータスコードです。

404 Not Found（ページが見つからない）や403 Forbidden（アクセス禁止）と違い、500番台のエラーは「サーバー側の内部トラブル」を示すコード群です。とくに500はざっくりしていて、
・アプリケーションのバグ
・設定ファイルの不整合
・バックエンドサービスのダウン
・プロキシやCDNなど中継役の故障

など、原因はかなり広い範囲を含みます。

今回のようにCloudflare側で障害が起きると、本来は正常なWebアプリであっても、Cloudflareのリバースプロキシ（Reverse Proxy：仲介サーバー）がエラーを返してしまうため、エンドユーザーから見ると「このサイト壊れてる？」と誤解しやすいのが厄介なポイントです。(AI TECH MEDIA スラッシュ)

原因：React2Shell脆弱性への対処とWAF設定変更の“悪い組み合わせ”

Cloudflareの説明によれば、今回の障害はReact Server Components（Reactサーバーコンポーネント）の致命的な脆弱性「React2Shell（CVE-2025-55182）」への緊急対策中に行ったWAF（Web Application Firewall）関連の設定変更が、想定外のバグを踏み抜いたことが直接の原因です。 (The Cloudflare Blog)

経緯をざっくり時系列で整理すると、こんな流れです。

(1) React Server Componentsにリモートコード実行（Remote Code Execution：RCE）が可能な重大な脆弱性「React2Shell」が公表される
(2) Cloudflareは、この攻撃から顧客を守るため、WAFのボディ解析ロジックやバッファサイズ（リクエストボディを解析するためのメモリ領域）を変更し、防御を強化しようとする
(3) 途中で、内部テスト用のWAFルール評価ツールが新しい設定に対応していないことが分かり、「テスト用ルールを無効化する」ためのキルスイッチ設定をグローバルに展開
(4) そのキルスイッチが、古いプロキシ（FL1）側のLuaコードのバグを引き起こし、「executeアクション付きのルールをスキップしたときに想定していなかったnil参照」が発生
(5) その結果、該当条件に当てはまるトラフィックでHTTP 500エラーが大量発生

Cloudflareはポストモーテムで、「変更はサイバー攻撃とは一切関係なく、React2Shellという業界全体に影響する脆弱性を防御するための作業中に起きた」と明言しています。(The Cloudflare Blog)

つまり皮肉なことに、「セキュリティを高めるための変更」が、可用性（Availability：サービスの止まりにくさ）を犠牲にする形で爆発してしまった、という構図です。11月18日の障害でもBot Management（ボット管理）の設定ファイルが原因だったことを考えると、「高速な脅威対応」と「安全なロールアウト設計」の両立がまだうまくいっていない印象は否めません。(The Cloudflare Blog)

公式発表の要点と現時点の対応状況

Cloudflareは今回の障害について「攻撃ではなく自社側の構成変更が原因であり、すでに修正をロールバックして復旧済み」と説明しつつ、「11月に続く連続障害は不適切であり、再発防止策を最優先で進める」と謝罪しています。 (The Cloudflare Blog)

公式ブログおよび各社報道をまとめると、ポイントは次のとおりです。

・障害は25分程度で解消し、その後は正常稼働
・影響を受けたのはCloudflareトラフィック全体の約28％
・マルウェア感染やDDoS攻撃など外部からのサイバー攻撃ではない
・React Server Componentsの重大脆弱性への対策中に、WAF関連の構成変更が不具合を引き起こした
・11月18日の大規模障害に続くインシデントであり、「インターネットを再び失望させてしまった（we have let the Internet down again）」とCTO自らコメント (The Cloudflare Blog)

また、再発防止策として、Cloudflareは次のような方向性を挙げています。(The Cloudflare Blog)

・設定ファイルのロールアウトも、ソフトウェア本体と同様に「段階的デプロイ＋ヘルスチェック」を徹底する
・グローバルキルスイッチの仕組みを見直し、誤った構成で全世界に波及しないようにする
・「フェイル・オープン（Fail-open）」なエラーハンドリングの採用を進める（壊れた設定なら一旦スルーしてでもトラフィックを通す）

このあたりは、Cloudflareを使う側としてもアーキテクチャ設計の参考になりますね。

どんなユーザーが影響を受けたのか？一般ユーザーと企業ユーザー

一般ユーザーにとっては「サイトが落ちている」「アプリにログインできない」という体感で終わりますが、企業側、とくに金融・SaaS・AIサービスの運営者にとっては、短時間でも売上や信頼に直結するインシデントでした。 (Cyber Security News)

一般ユーザーの視点では、
・投資アプリにログインできない
・オンライン会議が開始できない
・ECサイトの決済画面が500エラーで止まる
・AIチャットが突然エラーを返す

といった「なんか今日変じゃない？」レベルの体験が中心だったと思います。

一方で、企業側は、
・取引時間中の証券アプリで注文が捌けない
・社内外の打ち合わせが全部Zoom頼みで予定が崩れる
・SaaSが止まりサポート窓口に問い合わせが殺到する
・「自社のシステムが悪いのか、Cloudflareなのか」を数分で切り分けるプレッシャー

を同時に抱えることになります。11月・12月と立て続けに大規模障害が起きたことで、「単一のCDN・セキュリティ基盤に依存しすぎていないか？」という議論が、経営層や顧客とのミーティングで急に増えた企業も多いはずです。(The Cloudflare Blog)

あなたの現場ではどうでしたか？
「うちはマルチCDNだったので影響ほぼゼロだった」「完全にCloudflare一択で焦った」など、仮想コメント欄で語るつもりで、一度振り返ってみてください。

500エラーを見たときの「とりあえずこれだけはやる」チェックリスト

障害の原因がCloudflare側だとしても、現場で最初にやるべき“切り分け”の手順は、ある程度パターン化しておくと安心です。

まず、一般ユーザー（閲覧者）の立場でできることを整理します。

(1) 1つのサイトだけでなく、別の有名サイト（検索エンジンやニュースサイトなど）にもアクセスしてみて、同じようにエラーが出るか確認する。
(2) そのサイト名＋「障害」や「Cloudflare」というキーワードでX（旧Twitter）や検索エンジンを軽くチェックし、同じ症状を報告している人がいないかを見る。(Hindustan Times)
(3) ダウン検知サービス（Downdetectorなど）で該当サービス名や「Cloudflare」を検索し、急な報告増加がないかざっと眺める。(Cyber Security News)
(4) ここまでで「世界的におかしい」という雰囲気なら、ルーター再起動やブラウザ再インストールに時間をかけすぎない。

次に、サイト運営者・インフラ担当の立場での初動です。

(1) 自社オリジンサーバーに直接アクセスできる経路を確保し、Cloudflareをバイパスした状態でアプリが正常応答するか確認する。
(2) Cloudflare Status（ステータスページ）や公式Xアカウントをチェックし、「widespread 500 errors（広範囲な500エラー）」などのメッセージが出ていないか確認する。(Cyber Security News)
(3) 監視ツールのグラフで、500エラーがCloudflare経由のリクエストだけに偏っていないかをざっくり見る（オリジンへの健康チェックはどうか）。
(4) 「自社側のリリース直後にだけエラーが増えていないか」をチェックし、もし直後であれば、自社変更のロールバックも検討する。
(5) Cloudflare側障害だと判断したら、社内チャットやステータスページに「現在Cloudflare側の障害と判明しており、調査・待機中」という一報を出し、無駄な“犯人探し”を減らす。

こうしたフローをチーム内で共有しておくと、「とりあえずRouter抜き差しして様子見ますね…」みたいな、あまり意味のない行動を減らせます。

サービス運営者向け：Cloudflare障害前提でアーキテクチャを見直す

今回と11月の連続障害で改めて突きつけられたのは、「セキュリティと高速配信を一社に丸ごと任せる」という設計のリスクです。 (The Cloudflare Blog)

とはいえ、「じゃあCloudflareを全部やめよう」は現実的ではありません。多くのサービスにとって、CloudflareレベルのCDN＋WAF＋ゼロトラストを一から自分で構築するのはかなり無茶です。
そこで、現実解として考えられるのは次のような方向性です。

まず、DNSやCDNを完全に単一プロバイダに固定しない設計です。
権威DNSを複数ベンダーで構成し、CDNもプライマリ／セカンダリやリージョンごとに分けておけば、少なくとも「一社の障害＝サービス完全停止」という状態は避けやすくなります。

次に、「Cloudflareが死んでも最低限のサービスは続けられる」バックドア経路を設計しておくことです。
たとえば、緊急時だけCloudflareを通さずにオリジンへルーティングするサブドメインを用意しておく、ゼロトラスト経由ログインが死んだときの代替認証手段を準備しておく、などです。(The Cloudflare Blog)

そして、アプリケーション側でも「フェイル・オープン気味な設計」を取り入れられないかを検討してみる余地があります。
たとえば、Botスコアが取得できないときは一律ブロックするのではなく、一定条件のもとで一旦通してログだけ残す、といった選択です（もちろん、攻撃リスクとのトレードオフにはなりますが）。(The Cloudflare Blog)

最後に重要なのが、「社内の期待値コントロール」です。
経営者やビジネス側に対して、「たとえCloudflareやAWSレベルでも障害は起こり、完全無停止は幻想に近い」という前提を共有し、そのうえでSLA（Service Level Agreement：サービス品質保証）をどう設計するのか話し合っておく。
ここをやっておかないと、毎回「なんで止まったんだ！」だけで終わってしまい、アーキテクチャの改善に話が進まないんですよね。

同日に報じられたCoinMiner／MuddyWater攻撃との関係

同じ12月5日付けで、Cyber Security Newsは「USBメモリ経由でCoinMinerマルウェアをばらまくキャンペーン」と「MuddyWaterによるUDPGangsterバックドア攻撃」という、まったく別系統のサイバー脅威も報じています。 (Cyber Security News)

・CoinMinerキャンペーンは、USBドライブ上に「USB Drive.lnk」というショートカットを置き、ユーザーにダブルクリックさせてXMRigマイナー（暗号資産Moneroを採掘するツール）をこっそり動かす手口です。南韓のワークステーションを主なターゲットにしているとされています。(Cyber Security News)

・MuddyWaterのUDPGangsterは、UDPベースのバックドア（Backdoor：裏口）で、トルコやイスラエル、アゼルバイジャンなど中東地域のWindows環境を狙い、フィッシングメールとマクロ付きWord文書を組み合わせて侵入する高度なスパイキャンペーンです。(Cyber Security News)

Cloudflare障害は「誤った設定変更による自爆」でしたが、同じ日にこうした攻撃キャンペーンが動いていることを考えると、SOC（Security Operations Center）やCSIRTの立場では、

・大規模障害が起きたとき「攻撃か？単なる障害か？」を早く見極める
・“単なる障害”と判明しても、その裏で本物の攻撃が走っていないかを監視し続ける

という二重のプレッシャーを背負っていることになります。
「Cloudflareが落ちててログも欠損気味だけど、MuddyWaterキャンペーンのIOCも追わないといけない」──そんな現場も実際にあったかもしれません。

みんなの現場ではどうだった？コメント欄で共有してほしいこと

今回のCloudflare 500 Internal Server Error障害は、たった25分で終わった出来事のようでいて、「インターネットが数社のインフラ企業にどれだけ依存しているか」を改めて突きつける事件でした。 (ガーディアン)

最後に、この記事を“フォーラムスレッド”だと思って、次のようなテーマで自分の環境を振り返ってみてください。

・あなたの会社やサービスでは、この障害をどう検知し、どう説明しましたか？
・マルチCDNやマルチDNS、フェイル・オープン設計など、すでに導入している工夫はありますか？
・React2Shellのような「重大脆弱性への緊急パッチ」と「安定運用」のバランスを、チーム内でどう議論していますか？
・経営層や顧客から「またクラウドが止まったのか」と言われたとき、なんと説明したでしょうか？

この記事をきっかけに、「Cloudflareが悪い」で終わらせず、
・自分たちがどこまで耐障害性を設計すべきか
・インシデント時のコミュニケーションをどう整えるか

を、コメント欄（のつもり）でみんなで議論していければと思います。
そして、次に同じような500エラーの波が来たときには、「ああ、あのときのチェックリストどおり動けばいいんだな」と、少しだけ落ち着いて対処できるようになっていたら嬉しいですね。