在 2025 年，我們觀察到超過 180 次由多種原因引發的網際網路中斷事件，有些是短暫且局部性的，但也有些是持續數日的完全中斷。在第四季，我們僅追蹤到一次由政府指示的網際網路關閉事件，但多起海底電纜切斷事件對數個國家/地區的連線能力造成嚴重破壞。此外，停電與極端天氣亦在多處地區造成網際網路服務中斷，而烏克蘭境內持續進行的衝突也影響了當地的網路連線性。如同以往，我們觀察到的部分中斷是由技術問題所導致——其中一些已由相關業者證實，另一些則原因不明。另外，多家超大規模雲端平台以及 Cloudflare 的事故也影響了網站與應用程式的可用性。
本文旨在概述已觀測並確認的網路中斷事件，並非該季所有發生問題的完整清單。這些異常現象是透過我們網路上觀測到與預期流量模式之間的顯著偏差所偵測出來的。欲查閱經驗證的異常狀況與確認中斷的完整清單，請參考 Cloudflare Radar 中斷中心。
10 月 29 日，由於總統大選期間爆發激烈抗議，坦尚尼亞全國實施了網際網路關閉。流量最初於當地時間約 12:30（世界標准時間 09:30）開始下降，較前一週減少逾 90%。此次中斷持續約 26 小時，流量在 10 月 30 日當地時間約 14:30（世界標准時間 11:30）左右開始恢復。然而，這次的恢復非常短暫，在恢復約兩小時後，當地時間 16:15（世界標准時間 13:15）左右，流量再度驟降。這第二波近乎全面的中斷持續至 11 月 3 日，直到當地時間 17:00（世界標准時間 14:00）後流量才快速回升。在關閉期間，我們也觀察到所公告的 IPv4 與 IPv6 位址空間略有下降，但從未出現完全停止公告的情況（後者意味著該國與全球網際網路徹底斷開連線）。（自發系統會向其他網際網路提供者公告 IP 位址區塊，告知哪些 IP 位址區塊由其管理。）
坦尚尼亞總統後續對外交使節團及居住在該國的外籍人士因網際網路中斷所受影響表示遺憾。該國在 2020 年大選前也曾限制網際網路與社群媒體服務。
Digicel Haiti 對電纜切斷導致的網際網路中斷並不陌生，其網路在第四季又遭遇兩起類似事件。10 月 16 日，Digicel Haiti (AS27653) 的流量於當地時間 14:30（世界標準時間 18:30）開始下降，至當地時間 16:00（世界標準時間 20:00）趨近於零。該公司總經理一則 X 貼文（翻譯版）指出：「我們告知客戶，@DigicelHT 的國際光纖基礎設施發生了兩處斷裂。」當地時間 17:00（世界標準時間 21:00）後流量開始恢復，並在一小時內達到預期水準。當地時間 17:33（世界標準時間 21:34），總經理發文表示「國際基礎設施的第一條光纖已修復」，服務已恢復。
11 月 25 日，該提供者總經理另一則 X 貼文（翻譯版）稱其「位於國家 1 號公路的國際光纖基礎設施」遭切斷。我們約在此前一小時觀察到 Digicel 網路流量下降，當地時間 02:00 至 08:00（世界標準時間 07:00 至 13:00）期間出現完全中斷。當地時間 08:22（世界標準時間 13:22）的後續 X 貼文宣布所有服務均已恢復。
Cybernet/StormFiber（巴基斯坦）
10 月 20 日當地時間 17:30（世界標準時間 12:30），Cybernet/StormFiber (AS9541) 的網際網路流量急遽下降，降至約為一週前同時段 50% 的水準。同時，該網路公告的 IPv4 位址空間減少超過三分之一。此變動原因為 PEACE 海底電纜受損，該電纜在蘇丹附近的紅海區域發生斷裂。
PEACE 是承載巴基斯坦提供者國際網際網路流量的數條海底電纜系統（包括 IMEWE 與 SEA-ME-WE-4）之一。該提供者承諾於 10 月 27 日前完全恢復服務，但流量與公告的 IPv4 位址空間在當地時間 10 月 21 日約 02:00（世界標準時間 10 月 20 日 21:00）已恢復至接近預期水準。
Camtel、MTN Cameroon、Orange Cameroun
10 月 23 日於喀麥隆多家網際網路服務提供者處觀察到的異常流量模式，據報導是由連接西非國家與葡萄牙的 WACS（西非電纜系統）海底電纜問題所致。
一則（翻譯版）公開報導指出，MTN 告知用戶「因 WACS 光纖電纜發生事故，網際網路服務暫時中斷」；Orange Cameroun 則通知用戶「因國際接取光纖發生事故，網際網路服務中斷」。Camtel 的 X 貼文表示「Cameroon Telecommunications (CAMTEL) 告知公眾，2025 年 10 月 23 日凌晨 WACS 電纜設備在 Batoke（林貝）發生技術事故，導致全國網際網路連線中斷。」
受影響服務提供者的流量最初於當地時間約 05:00（世界標準時間 04:00）下降，至當地時間 22:00（世界標準時間 21:00）左右恢復至預期水準。當日這些網路的流量極不穩定，有時跌幅達 90-99%。流量圖表中明顯的尖峰波動原因不明——可能是嘗試將網際網路流量轉移至連接喀麥隆的其他海底電纜系統。此期間 MTN Cameroon 與 Orange Cameroon 公告的 IP 位址空間亦減少，但 Camtel 公告的位址空間未變。
據報導，中非共和國與剛果共和國的連線能力同樣受 WACS 問題影響。
12 月 9 日，我們觀察到多明尼加共和國網際網路服務提供者 Claro Dominicana (AS6400) 的流量於當地時間 12:15（世界標準時間 16:15）左右急遽下降。當地時間 14:15（世界標準時間 18:15）左右流量再次下跌，較前一週暴跌 77% 後迅速恢復至預期水準。連線中斷可能由兩起光纖中斷引起，服務提供者在中斷期間的 X 貼文指出它們「導致部分服務間歇性中斷與緩慢」。Claro 後續在 X 發文表示，技術人員已透過修復切斷的光纖電纜恢復了全國網際網路服務。
根據多明尼加電力傳輸公司 (ETED) 一則 X 貼文（翻譯版），11 月 11 日一條輸電線路中斷導致多明尼加共和國電力服務中斷。此次停電影響了該國的網際網路流量，自當地時間 13:15（世界標準時間 17:15）開始，流量較前一週下降近 50%。流量水準持續偏低，直至當地時間 12 月 12 日約 02:00（世界標準時間 06:00）。ETED 後續一則 X 貼文（翻譯版）指出：「凌晨 2 點 20 分，我們已完成全國電力系統恢復，供電量達到需求的 96%……」
一份後續技術報告發現：「此次大停電始於 138 kV 的 San Pedro de Macorís I 變電站，一條帶電線路被手動斷開，引發了高強度短路。保護系統立即啟動，但故障導致附近多條線路斷開，使東部地區 575 MW 的發電量與電網其他部分脫離。這種不平衡導致主要發電廠依據其內建安全機制自動跳脫。」
12 月 9 日，一場大規模停電影響了肯亞多個地區。肯亞電力公司解釋，停電「是由區域性肯亞至烏干達互聯電網上的一起事故引發，該事故對系統的肯亞側造成了干擾」，並聲稱「受影響地區大部分在約 30 分鐘內恢復供電」。然而，對網際網路連線能力的影響持續了近四個小時，介於當地時間 19:15 至 23:00 之間（世界標準時間 16:15 至 20:00）。此次停電導致全國層級的流量下降幅度高達 18%，流量變化在納庫魯郡和卡姆布郡最為明顯。
12 月 12 日，俄羅斯對烏克蘭敖德薩地區的無人機襲擊損壞了倉庫和能源基礎設施，後者導致該地區部分區域停電。這些停電中斷了網際網路連線，導致流量較前一週下降幅度高達 57%。在 12 月 13 日午夜（世界標準時間 12 月 12 日 22:00）最初下跌後，流量在接下來的幾天內逐步恢復，於當地時間 12 月 16 日約 14:30（世界標準時間 12:30）回到預期水準。
颶風 Melissa 於 10 月 28 日登陸牙買加，沿途造成嚴重災情與破壞。相關的停電與基礎設施損毀影響了網際網路連線，導致流量從當地時間約 06:15（世界標準時間 11:15）開始下滑約一半，最終較前一週大幅減少達 70%。牙買加的網際網路流量在數日內持續低於颶風前的水準，直到 11 月 4 日上午才開始明顯回升至接近正常。通常在造成大規模與廣泛災情的風暴過後，一個國家的網際網路流量可能需要數週甚至數月才能恢復至「正常」水準——儘管電力可能在數天內大致恢復，但實體基礎設施的損壞則需要更長的時間來修復。
11 月 26 日，氣旋 Senyar 在斯里蘭卡和印尼引發災難性洪水與山崩，造成逾 1000 人死亡，並損壞了這些國家的電信與電力基礎設施。基礎設施損壞導致多個地區的網際網路連線中斷，以及隨之而來的流量水準下降。
在斯里蘭卡，西部省以外的地區受影響最嚴重，包括西北省、南部省、烏沃省、東部省、北部省、北中部省以及薩巴拉加穆瓦省等多個省份的流量，均較前一週驟降 80 % 至 95 %。
在印尼，亞齊和蘇門答臘地區遭受的網際網路中斷最為嚴重。在亞齊，流量最初較前一週下降超過 75%。在蘇門答臘，北蘇門答臘受影響最大，初期流量減少 30 %，隨後於下一週開始較明顯回升。
10 月 3 日，印尼網際網路服務提供者 Smartfren (AS18004) 的用戶經歷了服務中斷。該服務提供者在 X 上發文承認問題，並表示（翻譯版）：「目前，電話、簡訊和數據服務在多個地區出現問題。」該服務提供者的流量自當地時間約 09:00（世界標準時間 02:00）開始下降，跌幅最高達 84%。中斷持續約八小時，流量於當地時間約 17:00（世界標準時間 10:00）恢復至預期水準。Smartfren 未提供任何關於服務問題起因的額外資訊。
英國主要網際網路服務提供者 Vodafone UK（AS5378 及 AS25135）於 10 月 23 日經歷短暫服務中斷。當地時間 15:00（世界標準時間 14:00），兩個 Vodafone ASN 的流量降至零。AS5378 公告的 IPv4 位址空間減少 75%，而 AS25135 公告的 IPv4 位址空間則完全消失。網際網路流量與位址空間均在兩小時後恢復，於當地時間約 17:00（世界標準時間 16:00）回到預期水準。Vodafone 未在其社群媒體頻道提供任何關於此次中斷原因的資訊，其網路狀態檢查頁面在中斷期間亦無法使用。
根據一則公開報導，一個 DNS 解析問題於 10 月 22 日影響了義大利服務提供者 Fastweb (AS12874) 客戶的網際網路服務，導致觀察到的流量下降超過 75%。Fastweb 承認了此問題，該問題在當地時間 09:30 至 13:00 之間（世界標準時間 08:30 至 12:00）影響了有線網際網路客戶。
雖然這並非連線故障導致的網際網路中斷，但 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）期間，國家層級的流量較前一週下降高達 80%，Etisalat 和 MTN 的流量下降近 100%，SBIN 的流量下降超過 80%。
儘管當天稍早曾發生未遂政變，但尚不清楚觀察到的網際網路中斷是否與此有關。從路由角度來看，所有三家受影響的網路均以 Cogent (AS174) 作為上游服務提供者，因此 Cogent 的局部問題可能導致了此次短暫中斷。
根據以色列服務提供者 Cellcom (AS1680) 的一則報導公告，12 月 18 日「發生了一項影響網際網路連線的故障，波及部分客戶」。此故障導致流量較前一週下降近 70%，發生時間為當地時間 09:30 至 11:00（世界標準時間 07:30 至 09:00）。根據一篇公開報導，此「故障」可能是一次 DNS 故障。
Partner Communications（以色列）
在 2025 年尾聲，以色列服務提供者 Partner Communications (AS12400) 於 12 月 30 日發生重大技術故障，導致全國行動、電視和網際網路服務中斷。Partner 的網際網路流量在當地時間 14:00 至 15:00（世界標準時間 12:00 至 13:00）期間較前一週下降三分之二。中斷期間，對 Cloudflare 的 1.1.1.1 公用 DNS 解析程式的查詢量激增，顯示問題可能與 Partner 的 DNS 基礎設施有關。然而，該服務提供者未公開確認中斷原因。
在第四季，我們於 Radar 上推出了新的「雲端觀測性」頁面，該頁面追蹤超大規模雲端平台（包括 Amazon Web Services、Microsoft Azure、Google Cloud Platform 和 Oracle Cloud Infrastructure）在區域層級的可用性與效能問題。
10 月 20 日，位於維吉尼亞州北部的 Amazon Web Services us-east-1 區域經歷了「錯誤率和延遲增加」，影響了該區域內的多項服務。此問題不僅影響了依賴該區域內基礎設施、擁有面向公眾網站和應用程式的客戶，也影響了在 us-east-1 託管原始資源的 Cloudflare 客戶。
我們於世界標準時間約 06:30 開始觀察到問題的影響，當時錯誤（5xx 類別）回應的比例開始攀升，並在世界標準時間約 08:00 達到高達 17%。嘗試連線至 us-east-1 來源伺服器時遇到的失敗次數也隨之增加，在世界標準時間約 12:00 達到高峰。
此影響亦清楚反映在關鍵網路效能指標上，相關數值在事件期間持續偏高，直至事件結束前（約世界標準時間 23:00）才恢復正常水平。TCP 和 TLS 交握持續時間在整個事件期間逐漸惡化——這些指標衡量 Cloudflare 與客戶在 us-east-1 的來源伺服器分別建立 TCP 和 TLS 連線所需的時間。此外，在事件最初幾小時內，Cloudflare 從來源伺服器接收回應標頭所需的時間顯著增加，之後才逐漸恢復至預期水準。
10 月 29 日，Microsoft Azure 發生一起影響其內容交付網路服務 Azure Front Door 的事件。根據 Azure 的事件報告：「客戶在兩個不同控制平面建置版本上執行的一系列特定設定變更，導致產生了不相容的客戶設定中繼資料。這些客戶設定變更本身是有效且非惡意的，但它們產生的中繼資料部署到邊緣站點伺服器時，暴露了資料平面中的一個潛在錯誤。這種不相容性觸發了資料平面服務內非同步處理過程中的當機。」
事件報告標記的開始時間為世界標準時間 15:41，但我們觀察到對 Azure 託管來源伺服器的連線嘗試失敗量在此約 45 分鐘前便開始攀升。TCP 和 TLS 交握指標在事件期間也變得更不穩定，TCP 交握時間有時延長超過 50%，TLS 交握時間在高峰時延長近 200%。受影響的指標在世界標準時間 20:00 後開始改善，根據 Microsoft 的說法，事件於 10 月 30 日世界標準時間 00:05 結束。
除了上述討論的中斷事件外，Cloudflare 在第四季也經歷了兩次服務中斷。雖然這些並非傳統意義上的網際網路中斷，但它們發生時確實阻止了使用者存取由 Cloudflare 交付和保護的網站及應用程式。
第一次事件發生於 11 月 18 日，起因是對我們其中一個資料庫系統權限的變更，觸發了軟體故障，導致該資料庫將多個項目輸出到我們的 Bot Management 系統所使用的「功能檔案」中。更多詳細資訊，包括根本原因分析和時間線，可以在相關的部落格文章中找到。
第二次事件發生於 12 月 5 日，影響了一部分客戶，約佔 Cloudflare 處理的所有 HTTP 流量的 28%。其觸發原因是，我們在嘗試偵測與緩解一個新近揭露、影響整個產業的 React Server Components 漏洞時，對請求正文剖析邏輯進行了變更。一篇事後分析部落格文章中介紹了更多細節，包括根本原因分析和時間線。
若想深入瞭解 Cloudflare 為防止類似中斷再次發生所進行的相關工作，請參閱我們的部落格文章《橙色警報：小規模故障》。
第四季觀察到的中斷事件突顯了即時資料對於維護全球連線能力的重要性。無論是政府下令的關閉還是微小的技術問題，透明度都能讓技術社群更快、更有效地做出回應。我們將持續在 Cloudflare Radar 上追蹤這些變化，提供必要的解析以應對現代網路的複雜性。我們透過 Cloudflare Radar 中斷中心、社交媒體，以及在 blog.cloudflare.com 上的文章分享我們的觀察。在社交媒體上關注我們：@CloudflareRadar (X)、noc.social/@cloudflareradar (Mastodon) 和 radar.cloudflare.com (Bluesky)；或透過電子郵件聯絡我們。
溫馨提醒：雖然這些部落格文章使用了來自 Radar 和 Radar Data Explorer 的圖表，但基礎資料可透過我們的 API 取得。您可以使用該 API 擷取資料進行本機監控或分析，也可以使用 Radar MCP 伺服器將 Radar 資料整合到您的 AI 工具中。