「インターネットが壊れた日」2025年Cloudflare障害の全貌
karrinn
著者
「インターネットが壊れた」
2025年11月18日、Xのタイムラインにこんな投稿が溢れました。ChatGPTが応答しない。Spotifyで音楽が聴けない。Zoomで会議に入れない。原因は、世界のWebトラフィックの約20%を処理するCloudflareの障害でした。そしてわずか2週間半後、同じことがまた起きたのです。
KEY TAKEAWAYS
この記事でわかること
- 11月18日・12月5日の障害の技術的な原因と経緯
- なぜCloudflareが落ちると「インターネットが壊れる」のか
- DownDetectorも落ちた皮肉と、再帰的監視サイトの誕生秘話
Cloudflareとは何か
ROLE 01
CDN（コンテンツ配信ネットワーク）
世界中にあるサーバーにコンテンツをキャッシュし、ユーザーに最も近いサーバーから配信。Webサイトの表示速度を向上させます。
ROLE 02
DDoS攻撃からの防御
大量のトラフィックを送りつけてサービスを停止させる攻撃を検知・遮断。多くのWebサイトがCloudflareの「盾」に守られています。
ROLE 03
DNS（ドメイン名解決）
「example.com」のようなドメイン名を、実際のサーバーIPアドレスに変換。CloudflareのDNS（1.1.1.1）は世界最速クラスです。
ROLE 04
Bot管理・WAF
悪意のあるボットやハッキング試行をブロック。「私はロボットではありません」のTurnstileもCloudflareのサービスです。
世界のWebの約20%がCloudflareを経由
Cloudflareは世界310都市以上にデータセンターを持ち、インターネットトラフィックの約20%を処理しています。つまり、Cloudflareが落ちると「インターネットの5分の1」が影響を受ける計算になります。
Source: Cloudflare Network
第1の障害：2025年11月18日
「2019年以来最悪の障害」とCEOが認めた、約4時間に及ぶ大規模停止
20:05 JST（11:05 UTC）
権限変更作業の実施
ClickHouseデータベースのアクセス制御を変更する作業を実施。この変更が後の障害の引き金となった。
20:20 JST（11:20 UTC）- 障害発生
設定ファイルの肥大化
Bot Managementの設定ファイル生成クエリが重複行を出力し、ファイルサイズが想定の2倍に。メモリ制限（200機能）を超過し、FL2プロキシがクラッシュ。
20:20 - 22:00 JST
誤診断：DDoS攻撃の疑い
システムが5分ごとに良好/不良ファイルを交互に生成。一時的な回復と再失敗の繰り返しが、攻撃の可能性を疑わせ診断を遅延させた。
23:30 JST（14:30 UTC）
主要トラフィック復旧
肥大化ファイルの生成・自動配信を停止。正常な旧バージョンのファイルを手動で差し替え、コアプロキシを強制再起動。
翌2:06 JST（17:06 UTC）
完全復旧
すべてのシステムが正常稼働に復帰。障害継続時間は約4時間。
原因となったクエリの問題
データベースの権限変更により、Bot Managementで使用される設定ファイル生成クエリが予期せず重複データを返すようになりました。通常は200エントリ程度のファイルが400エントリ超に膨れ上がり、プロキシのメモリ割り当てを超過。
- 影響を受けたサービス：CDN、Turnstile、Workers KV、Access、Dashboard
- 推定損失：2.5〜3億ドル（Forrester推定）
-- 本来の動作：http_requests_features テーブルのみ SELECT name, type FROM system.columns WHERE table = 'http_requests_features' -- 障害時：r0データベースのメタデータも返却 -- → 重複エントリが発生 -- → ファイルサイズが2倍に -- → メモリ制限超過でクラッシュ
"This was Cloudflare's worst outage since 2019."
— Matthew Prince, Cloudflare CEO
第2の障害：2025年12月5日
わずか2週間半後、脆弱性対策の設定変更が再び障害を引き起こした
背景
React Server Components脆弱性への対応
業界全体で報告されたReact Server Componentsの脆弱性（CVE-2025-55182）を緩和するため、WAFの設定変更を段階的にロールアウト中だった。
17:47 JST（08:47 UTC）- 障害発生
設定変更が全フリートに即時伝播
WAFテストツールを無効化する設定変更を、段階的ロールアウトではなくグローバル設定システムで実施。数秒で全フリートに伝播し、FL1プロキシでLuaランタイムエラーが発生。
17:50 JST（08:50 UTC）
インシデント宣言
Cloudflareが処理するHTTPトラフィックの約28%に影響。FL1プロキシかつCloudflare Managed Rulesetを使用している顧客がHTTP 500エラーに。
18:12 JST（09:12 UTC）- 完全復旧
設定変更のロールバック完了
障害継続時間は約25分。11月の障害と比較すると迅速に復旧できたものの、2週間半で2度目の大規模障害という事態に。
Luaランタイムエラー
FL1（古いバージョンのプロキシ）で、killswitchによりスキップされた「execute」アクションのルールセットを処理しようとした際にエラーが発生。このバグは新しいRustベースのFL2プロキシでは発生しません。
- 影響：HTTPトラフィックの約28%
- 条件：FL1プロキシ かつ Managed Ruleset使用
attempt to index field 'execute' (a nil value) -- killswitchでスキップされたルールセットの -- 'execute'フィールドにアクセスしようとして -- nil値参照エラーが発生
2つの障害の比較
| 項目 | 11月18日 | 12月5日 |
|---|---|---|
| 継続時間 | 約4時間 | 約25分 |
| 原因 | Bot Management設定ファイルの肥大化 | WAF設定変更によるLuaエラー |
| 影響プロキシ | FL2（新バージョン） | FL1（旧バージョン） |
| 影響範囲 | CDN、Turnstile、Workers KV等 | HTTPトラフィックの約28% |
| サイバー攻撃 | なし（内部バグ） | なし（設定変更ミス） |
| 共通点 | 設定変更の段階的ロールアウト不足、グローバル伝播の速さ | |
DownDetectorも落ちた
「サービスが落ちてるか確認しようとしたら、確認するサイトも落ちていた」
Cloudflareの障害が発生したとき、多くの人が最初に確認するのがDownDetectorです。各種サービスの障害状況をリアルタイムで報告するサイトで、「今、本当に落ちてるの？」を確認するのに便利なサービスです。
しかし、11月18日と12月5日の両方の障害で、DownDetector自体もアクセス不能になりました。なぜなら、DownDetectorもCloudflareを使っていたからです。
"When an edge provider stumbles, you don't just lose one website — you lose the ability to verify that sites are down at all. That's why DownDetector being unreachable is more than ironic: it's a symptom of systemic fragility."
エッジプロバイダーが倒れると、サイトがダウンしているかどうかを確認する能力すら失う。DownDetectorが到達不能なのは皮肉以上のもの—これはシステム的な脆弱性の症状だと、専門家は指摘しています。
Source: IT Pro
「単一障害点」問題
なぜCloudflareが落ちると「インターネットが壊れる」のか
集中化のパラドックス
個々のサービスを守るために（DDoS攻撃対策、高速配信など）Cloudflareのような大規模インフラに依存する。しかし、その依存が「単一障害点」を生み出し、システム全体の脆弱性につながる。
- 個別サービスのレジリエンス向上
- しかし全体としての脆弱性も増大
2025年のCloudflare障害一覧
2025年だけでも複数回の障害が発生しており、インターネットインフラの脆弱性が繰り返し顕在化しています。
- 3月21日：R2ストレージ障害（約1時間）
- 6月12日：Workers KV等（約2.5時間）
- 7月14日：DNS障害（約1時間）
- 11月18日：大規模障害（約4時間）
- 12月5日：WAF障害（約25分）
影響は民間だけではない
米国政府機関、航空会社、金融機関、医療システムなど、重要インフラもCloudflareに依存しています。インターネットインフラの障害は、国家安全保障上の問題にもなり得ると専門家は警告しています。
Source: ENGINYRING
おまけ：インターネットの遊び心
DownDetectorが落ちたなら、DownDetectorを監視するサイトを作ればいい
11月18日の障害でDownDetectorが落ちたことを受けて、Webゲーム「TimeGuessr」の開発者Gus Owen氏がユーモアあふれる解決策を思いつきました。「DownDetectorのDownDetector」を作ればいいじゃないか、と。
| 階層 | サイト | DNS | Web | 12/5 |
|---|---|---|---|---|
| 1 | downdetector.com 本家 | Cloudflare | Cloudflare | |
| 2 | downdetectorsdowndetector.com Gus Owen氏作成 | Cloudflare | Cloudflare | |
| 3 | downdetectorsdowndetectorsdowndetector.com Hacker News民が作成 | Porkbun | Apache | |
| 4 | downdetectorsdowndetectorsdowndetectorsdowndetector.com halgir氏作成 | SiteGround | nginx |
12月5日の障害発生時、実際に確認したところdowndetectorsdowndetectorsdowndetector.comだけが生きていました。1〜2段階目は「独立した監視サイト」を謳いながら、DNSからWebサーバーまでCloudflareに依存していて共倒れ。3段階目でようやくDNSもWebも完全にCloudflareから独立したインフラを選んだ人が現れた、という状況でした。私自身その日これらを漁りながら笑ってしまいました。
"Sometimes the internet is fun."
Source: PC Gamer
まだコメントはありません。最初のコメントを残しませんか？