2025年、私たちはさまざまな要因を起因とする180件を超えるインターネット障害を観測しました。この中には、一時的かつ局所的なものから数日にわたる全面的なものまでさまざまなものがありました。第4四半期には、政府主導によるインターネット遮断は1件のみでしたが、複数の国でのケーブル切断による大混乱障害、複数の地域での停電や異常気象によるインターネットサービスの中断も観測されました。また、ウクライナで継続中の紛争も、同国の通信状況に影響を及ぼしました。その他、異常事態ではない技術的な問題による障害も複数観測していますが、プロバイダーが公式に認めたものもあれば、原因が特定できていないものもあります。さらに、いくつかのハイパースケーラー型クラウドプラットフォームやCloudflareで発生した障害により、Webサイトやアプリケーションが利用できなくなる現象も発生しました。
この投稿は観測および確認された障害の概要を説明するものであり、当四半期中に発生した問題を網羅的に、あるいは完全にリストアップするものではありません。これらの異常は、Cloudflareのネットワーク全体で観測される通常のトラフィックパターンからの大幅な逸脱によって検出されます。確認された異常や障害の完全な一覧については、Cloudflare Radar Outage Centerをご覧ください。
2025年10月29日にタンザニアで発生したインターネットの遮断は、大統領選挙中に発生した激しい抗議活動の中確認されました。現地時間12:30（09:30 UTC）頃に最初のトラフィック低下が見られ、前週比で90%以上減少しました。この障害は約26時間続き、一度は10月30日の現地時間14:30（11:30 UTC）頃にトラフィックが回復し始めましたが、これは非常に短時間に終わり、この復旧から約2時間後の現地時間16:15（13:15 UTC）頃に再びトラフィックが大幅に減少しました。この2回目のほぼ完全な障害は11月3日まで続いた後、現地時間17:00（14:00 UTC）を境にトラフィックが急激に回復しました。遮断期間中、アナウンスされたIPv4およびIPv6アドレス空間のわずかな減少も観察されましたが、国全体がインターネットから完全に切断されたことを示すようなアナウンスが完全に失われるといった事態はありませんでした。（自律システムは、他のインターネットプロバイダーにIPアドレス空間を通知し、どのIPアドレス範囲を担当しているかを知らせます。）
その後、タンザニア大統領は、インターネット遮断の影響について、外交団のメンバーや国内に居住する外国人に対し、同情の意を表明しました。なお、同国では2020年の総選挙前にも、インターネットやSNSへの制限が実施されています。
Digicel Haitiでは、ケーブル切断によるインターネット障害が度々発生しており、第4四半期にも同様のインシデントが2件確認されました。1件目は10月16日のもので、Digicel Haiti (AS27653)からのトラフィックが現地時間14:30（18:30 UTC）に減少し始め、現地時間16:00（20:00 UTC）にはほぼゼロにまで減少しました。同社の総括責任者はXの投稿で、「@DigicelHTの国際光ファイバーインフラストラクチャで2か所の切断が発生していることを、当社のお客様にお知らせします。」と発表し、その後トラフィックは現地時間17:00（21:00 UTC）過ぎに回復し始め、約1時間弱で通常の水準にまで回復しました。同総括責任者は現地時間17:33（21:34 UTC）に、「国際インフラストラクチャの最初のファイバーの修理が完了した」と投稿し、サービスが復旧しました。
2件目は11月25日のもので、プロバイダーの総括責任者はXの投稿で、「国道1号線沿いの国際光ファイバーインフラストラクチャ」が切断されたことを知らせています。Cloudflareの観測では、投稿の約1時間前からDigicelのネットワーク上のトラフィックが減少していることを確認しており、現地時間2:00～8:00（07:00～13:00 UTC）にかけて完全な停止状態であることが観測されています。その後、現地時間8:22（13:22 UTC）のフォローアップのXの投稿で、すべてのサービスが復旧したことが伝えられています。
Cybernet/StormFiber（パキスタン）
10月20日の現地時間17:30（12:30 UTC）、Cybernet/StormFiber（AS9541）のインターネットトラフィックが急激に減少し、前の週の同時刻の約50%の水準にまで落ち込みました。同時に、同ネットワークでアナウンスされているIPv4アドレス空間も3分の1以上減少しました。この現象の原因となったものは、スーダン近くの紅海の海底ケーブルPEACEの損傷でした。
PEACEはIMEWEやSEA-ME-WE-4と並び、パキスタンの通信事業者が国際インターネットトラフィックの伝送に使用している海底ケーブルの1つです。同社は10月27日までのサービス完全復旧を公約していましたが、実際にはそれよりも早い10月21日の現地時間2:00（10月20日21:00 UTC ）頃までにトラフィックとアナウンスされたIPv4アドレス空間は、ほぼ通常の水準まで回復していました。
Camtel、MTN Cameroon、Orange Cameroun
10月23日、カメルーン国内の複数のインターネットプロバイダーで見られた異常なトラフィックパターンは、アフリカ西海岸の各国とポルトガルを結ぶWACS（West Africa Cable System）海底ケーブルが原因と報じられています。
公開されたレポートによると、MTNは加入者に「WACS光ファイバーケーブルの事故により、インターネットサービスが一時的に中断している」旨を通知し、Orange Camerounは加入者に「国際アクセス用光ファイバーの事故により、インターネットサービスが中断されている」旨を通知しました。さらにCamtelはXの投稿で、「Cameroon Telecommunications（CAMTEL）より、2025年10月23日未明、バトケ（リンベ）にあるWACSケーブル設備で技術的な事故が発生し、国内全域でインターネット接続障害が起きたことをお知らせします」といった内容の報告を行っています。
影響を受けた各プロバイダーのトラフィックは、現地時間5:00（04:00 UTC）頃に最初の低下が見られ、現地時間22:00（21:00 UTC）頃に通常の水準に回復しました。ただし、当日はトラフィックの変動が非常に激しく、時間帯によっては90～99％の大幅な減少も見られました。このような急激な上下動の明確な原因は不明ですが、おそらく、カメルーンに接続する他の海底ケーブルシステムにインターネットトラフィックを移行させようとした影響の可能性が考えられます。この期間中、MTN CameroonとOrange CamerounではアナウンスされているIPアドレス空間の減少も確認されましたが、Camtelでは変化は見られませんでした。
なお、中央アフリカ共和国とコンゴ共和国の接続性も、今回のWACSの問題の影響を受けたと報告されています。
12月9日現地時間12:15（16:15 UTC）頃、ドミニカ共和国のインターネットプロバイダーであるClaro Dominicana（AS6400）からのトラフィックが急激に減少しました。その後現地時間14:15（18:15 UTC）頃にトラフィックが前週比で77%まで再び低下しましたが、すぐに通常の水準に戻りました。この通信障害は、2か所で発生した光ファイバー障害が原因とみられています。障害発生中に同社が行ったXの投稿で、「一部のサービスで接続の不安定さと速度低下が発生している」旨が伝えられました。Claroはその後のXへの投稿で、切断された光ファイバーケーブルが技術者による修復作業を経て、国内全域のインターネットサービスが復旧した旨を伝えています。
11月11日、Empresa de Transmisión Eléctrica DominicanaによるXの投稿で、ドミニカ共和国で送電線の障害によって電力サービスが中断されたことが伝えられました。この停電の影響で、同国のインターネットトラフィックが現地時間13:15（17:15 UTC）を境に、前週比で50%近くのトラフィックが減少しました。トラフィックの低下は、12月12日の現地時間2:00（6:00 UTC）頃まで続き、その後同社によるXの投稿で「午前2時20分に国家電力システムの復旧が完了し、需要の96%に電力を供給している」旨が伝えられました。
その後に公表された技術報告書では、「サン・ペドロ・デ・マコリス I 138kV変電所で、通電中の送電線が手動で切り離されたことから始まり、これにより大規模な短絡が発生。保護システムは即座に作動したものの、この障害の影響で周辺の複数の送電線が切断され、東部地域で発電されていた約575MWの電力が、送電網から切り離される事態となった。この電力バランスの崩れにより、安全機構が作動して主要な発電所が自動停止した。」と言った内容の説明がされています。
12月9日、ケニア全土の複数地域で大規模な停電が発生しました。電力会社のKenya Powerは、この障害について「ケニアとウガンダを結ぶ地域間送電ネットワークで発生した事故により、ケニア側のシステムで障害が発生した」「影響を受けた地域の大半で約30分以内に電力が復旧した」と発表しました。一方で、インターネット接続への影響は現地時間19:15～23:00（16:15～20:00 UTC）の4時間近く続き、この影響で国内全域のトラフィックは最大18%減少し、特にナクルとキアンブで影響が顕著に見られました。
12月12日、ウクライナのオデーサ州でロシア軍のドローン攻撃があり、倉庫やエネルギー施設が被害を受けました。このうち、電力インフラへの被害により州内の一部地域で停電が発生しました。この停電の影響でインターネット接続断が発生し、トラフィックは前週比で最大57%減少しました。トラフィックは12月13日0:00（12月12日22:00 UTC）に最初の大きな減少が見られた後、その後数日間かけて徐々に回復し、現地時間12月16日14:30（12:30 UTC）頃に通常の水準へと戻りました。
10月28日、ハリケーン「メリッサ」がジャマイカに上陸し、その経路上に被害と破壊の痕跡を残しました。これに伴う停電やインフラの損傷により、インターネットトラフィックは、現地時間6時15分（11:15 UTC）頃を皮切りに約半分に減少し、その後、前週比で最大70%減にまで落ち込みました。ジャマイカからのインターネットトラフィックは、数日間にわたりハリケーン前の水準を大きく下回った状態が続き、11月4日の朝頃から、徐々に通常レベルに近づく動きが見られました。このように、大規模で広範囲に被害をもたらす嵐の後では、インターネットトラフィックが「通常」の水準に戻るまで、数週間から数か月かかることも珍しくありません。電力は数日以内におおむね復旧する場合が多い一方で、物理的なインフラの修復にはより長い時間がかかります。
11月26日、サイクロン「セニャール」がスリランカとインドネシアで壊滅的な洪水と土砂災害を引き起こし、1,000人以上が犠牲となりました。この災害により、両国で通信インフラや電力インフラが大きな被害を受け、複数の地域でインターネット接続が中断され、トラフィック水準が低下しました。
スリランカでは、主要な西部州以外の地域が最も影響を受け、北西部州、南部州、ウバ州、東部州、北部州、北中部州、サバラガムワ州などのいくつかの州では、前週比でトラフィックが80%～95%減少しました。
インドネシアでは、アチェ州とスマトラ地方で最大のインターネット障害が発生しました。アチェ州では、トラフィックが最初に前週比で75%以上減少しました。スマトラ島では、特に北スマトラ州の影響が大きく、当初は約30％の減少が見られたものの、翌週から回復が進み始めました。
10月3日、インドネシアのインターネットプロバイダーSmartfren（AS18004）の加入者がサービス障害による影響を受けました。同プロバイダーはこの問題を、「現在、複数の地域で電話、SMS、データサービスに問題が発生しています。」とXの投稿で認めています。プロバイダーからのトラフィックは、現地時間09:00（02:00 UTC）頃から84%減少しました。この障害は、現地時間17:00（10:00 UTC）頃にトラフィックが通常の水準に回復するまで約8時間続きました。なお、Smartfrenからは、障害の具体的な原因についての説明は公表されていません。
10月23日、英国の大手インターネットプロバイダーVodafone UK（AS5378 & AS25135）で、一時的なサービス障害が発生し、現地時間15:00（14:00 UTC）には、Vodafone ASNの両方のトラフィックがゼロにまでなる事態となりました。AS5378からのアナウンスされたIPv4アドレス空間は75%減少し、AS25135からのアナウンスされたIPv4アドレス空間は完全に消失しました。2時間後の現地時間17:00（UTC 16:00）頃に、インターネットトラフィック、アドレス空間はいずれも通常の水準まで回復しました。Vodafoneは、障害の原因についてSNSでの説明を行っておらず、同社のネットワーク状態確認ページも障害中は利用できない状態でした。
公開されたレポートによると、10月22日、イタリアのプロバイダーFastweb（AS12874）の利用者向けインターネットサービスが、DNSの名前解決に関する問題により影響を受け、観測されたトラフィック量が75%以上減少しました。Fastwebは障害を認めており、現地時間9:30～13:00（08:30～12:00 UTC）にかけて有線インターネットのお客様に影響が出たと伝えています。
今回のFastwebの事例は、接続障害によるインターネット停止ではありませんが、DNSの名前解決に問題が発生した場合の現象は接続障害と非常に類似しています。プロバイダーのDNSリゾルバーで問題が発生している場合、Cloudflareの1.1.1.1パブリックDNSリゾルバーのようなサービスに切り替えることで、多くの場合、接続が回復します。
SBIN、MTN Benin、Etisalat Benin
12月7日、SBIN（AS28683）、MTN Benin（AS37424）、Etisalat Benin（AS37136）で同時にトラフィックの減少が見られました。現地時間18:30～19:30（17:30～18:30 UTC）にかけて、トラフィックは国内全域で前週比で最大80%減少し、EtisalatとMTNではほぼ100%、SBINでは80%以上減少しました。
その日の早い段階で、クーデター未遂が発生していたものの、今回観測されたインターネット障害との直接的な関連は不明です。ルーティングの観点では、影響を受けた3社はいずれも上位回線事業者としてCogent（AS174）を共有しており、Cogent側で発生した局所的な問題が、短時間の障害を引き起こした可能性があります。
12月18日、イスラエルのプロバイダーCellcom（AS1680）は「一部のお客様に影響を及ぼすインターネット接続の障害が発生した」旨の報告内容を公表しています。この不具合により、現地時間9:30～11:00（07:30～09:00 UTC）にかけて、トラフィックは前週比で70%近く減少しました。公開された報告によると、この「不具合」はDNSの障害であった可能性があるとされています。
Partner Communications（イスラエル）
2025年の締めくくりとなる12月30日、イスラエルのプロバイダーであるPartner Communications（AS12400）で大規模な技術的障害が発生し、国内全域にわたるモバイル、テレビ、インターネットサービスが中断される事態が発生しました。同社からのインターネットトラフィックは、現地時間14:00～15:00（12:00～13:00 UTC）にかけて前週比で3分の2減少しました。障害発生中、Cloudflareの1.1.1.1パブリックDNSリゾルバーへのクエリの急増が記録されており、これは同社のDNSインフラに関連する現象であったことが示唆されています。ただし、障害の原因について、同社からの公式な発表はありません。
当社は第4四半期に、Radar上に新たに「Cloud Observatory」ページを公開しました。このページでは、Amazon Web Services、Microsoft Azure、Google Cloud Platform、Oracle Cloud Infrastructureを含むハイパースケーラー型クラウドプラットフォームの可用性とパフォーマンスの問題を地域別に追跡できます。
10月20日、米バージニア州北部にあるAmazon Web Services（AWS）のus-east-1リージョンで、「エラー率と遅延の増加」が発生し、リージョン内の複数のサービスに影響を及ぼしました。この問題は、この地域内のインフラを利用して公開Webサイトやアプリケーションを運用しているお客様だけでなく、オリジンリソースをus-east-1にホストしているCloudflareのお客様にも影響を与えました。
問題の影響は06:30 UTC頃から確認され始め、エラー（5xx系）の応答の割合が増加し、08:00 UTC頃には17%に達しました。us-east-1にあるオリジンへの接続失敗数も増加し、12:00 UTC頃にピークに達しました。
この障害の影響は、主要なネットワーク性能指標にもはっきりと表れていました。これらの指標は障害の発生中、高い状態が続き、インシデントが終了する直前の23:00 UTC頃に通常の水準まで回復しました。Cloudflareがus-east-1のお客様のオリジンサーバーとそれぞれTCPおよびTLS接続を確立するのに必要な時間を示すTCPおよびTLSのハンドシェイク時間が、障害の進行に伴い徐々に悪化しています。さらに、Cloudflareがオリジンからレスポンスヘッダーを受け取るまでの経過時間も、インシデント発生後の最初の数時間で大きく増加し、その後、時間の経過とともに徐々に通常の水準へと回復しています。
10月29日、Microsoft Azureでインシデントが発生し、同社のコンテンツ配信ネットワークサービスである Azure Front Doorに影響を与えました。同社はこのインシデントに関するAzureのレポートで、「2つの異なるコントロールプレーンのビルドバージョン間で行われた特定のシーケンスの顧客設定変更により、互換性のない顧客設定のメタデータが生成されました。これらの顧客設定の変更自体は正当かつ悪意のないものでしたが、生成されたメタデータがエッジサーバーに展開された際に、データプレーンに潜在していたバグが露呈することとなり、この非互換性により、データプレーンサービス内での非同期処理中にクラッシュする事態が引き起こされました。」と説明しています。
インシデントレポートでは開始時刻を15:41 UTCとしていますが、当社の観測ではAzureでホストされているオリジンへの接続試行の失敗が約45分前から増加し始めたことが確認されています。インシデント期間中、TCPおよびTLSハンドシェイク指標も不安定になり、TCPハンドシェイクには一時的に50%以上、TLSハンドシェイクにはピーク時で200%近い遅延が発生しました。これらの指標は20:00 UTC以降に改善し始め、インシデントは10月30日0:05 UTCに終了（Microsoft発表）しました。
これまでに紹介した障害に加え、第4四半期にはCloudflare自身でも2件の障害が発生しました。これは典型的なインターネット障害ではありませんでしたが、インシデント中は配信および保護にCloudflareを使用してしているWebサイトやアプリケーションにアクセスできなくなる現象が生じました。
11月18日に発生した1件目のインシデントは、当社のデータベースシステムの権限変更に起因するソフトウェア障害が原因で、当社のボット管理システムで使用される「機能ファイル」にデータベースから複数のエントリが出力されたことでした。原因分析や詳細な時系列については、関連するブログ記事でご覧いただけます。
12月5日に発生した2件目のインシデントは、Cloudflareが処理する全HTTPトラフィックの約28%を占める一部のお客様に影響を与えました。これは、業界全体で新たに公開された「React Server Components」の新たな脆弱性への対応作業の一環として、Cloudflare内部の「ボディ解析（body parsing）」のロジックに変更を加えたことが直接のきっかけでした。こちらについても、原因分析や詳細な時系列を含む事後分析はブログ記事でご覧いただけます。
このような障害の再発防止策としてCloudflareが進めている取り組みについては、「コードオレンジ：フェイルスモール（小さな失敗を許容し、影響を最小限にし、より大きな失敗を予防）」と題したブログ記事で詳しく紹介しています。
第4四半期に観測された一連の障害は、グローバルな接続性を維持するうえで、リアルタイムデータがいかに重要であるかを改めて示しています。遮断原因が政府命令や小さな技術的な問題に起因するものでも、情報の透明性が確保されていれば、技術コミュニティは迅速かつ効果的な対応が可能になります。Cloudflare Radarでは今後もこうした変化を追跡し、現代のネットワーク環境の複雑さに対応するために必要な情報を提供していきます。これらの観測結果は、Cloudflare Radar Outage Centerやソーシャルメディア、blog.cloudflare.comのブログ記事で共有しています。@CloudflareRadar（X）、noc.social/@cloudflareradar（Mastodon）、radar.cloudflare.com（Bluesky）などのソーシャルメディアでフォローしていただくか、メールでお問い合わせください。
なお、これらのブログ記事では、Radar および Radar Data Explorerのグラフを掲載していますが、その元となるデータは当社のAPIを通じて取得することができます。このAPIを利用すれば、自社環境での監視や分析のためにデータを取得することが可能です。また、Radar MCPサーバーを使用してRadarデータをAIツールに組み込むこともできます。