电缆切断、暴风雨和 DNS 攻击：2025 年第四季度互联网中断事件概述

2025 年，我们观察到超过 180 起互联网中断事件，导致出现这些事件的原因多种多样，有些是短暂的部分中断，而另一些则是持续数日的完全中断。在第四季度，我们仅追踪到一次政府指示的互联网关闭事件，但一些国家/地区发生了多次电缆切断事件，对网络连接造成严重破坏。停电和极端天气导致多地互联网服务中断，乌克兰持续不断的冲突也影响了当地的网络连接。与以往一样，我们观察到的许多中断事件是由于技术问题造成，其中一些事件原因得到了相关服务提供商的承认，而另一些事件则原因不明。此外，几个超大规模云平台以及 Cloudflare 发生的服务中断事件也影响了网站和应用的可用性。 

这篇博客文章是对观察到和已确认的中断事件的总结性概述，并不是第四季度所发生问题的详尽或完整清单。我们通过 Cloudflare 网络中观察到的趋势与预期流量模式的显著偏差检测了这些异常情况。请访问 Cloudflare Radar 中断中心，查看已验证的异常情况以及已确认的中断事件的完整列表。 

10 月 29 日，坦桑尼亚互联网服务中断，因为在该国总统大选投票期间发生了暴力抗议。流量最初在当地时间 12:30 左右 (09:30 UTC) 骤降，比上一周下降了超过 90%。此次中断持续约 26 小时，流量在 10 月 30 日当地时间 14:30 (11:30 UTC) 左右开始恢复。然而，那次恢复非常短暂，大约两小时后，即当地时间 16:15 (13:15 UTC) 左右，流量再次大幅下降。第二次近乎完全的网络中断一直持续到 11 月 3 日，并在当地时间 17:00 (14:00 UTC) 后，流量显著恢复。根据观察，已公布的 IPv4 和 IPv6 地址空间在断网期间也出现了名义上的数量下降，但从未出现公告完全丢失的情况，如果公告完全丢失，即表明该国互联网完全断开。（自治系统会向其他互联网服务提供商公布 IP 地址空间，让它们知道各自负责的 IP 地址块。）

随后，坦桑尼亚总统向遭受此次互联网服务中断影响的驻该国外交使团成员和外籍人士表示了慰问。2020 年坦桑尼亚大选之前，该国的互联网和社交媒体服务也受到过限制。

Digcel Haiti 对电缆切断造成的互联网中断并不陌生，遗憾的是，该公司在第四季度又经历了两起此类事件。10 月 16 日，来自 Digicel Haiti (AS27653) 的流量于当地时间 14:30 (18:30 UTC) 开始下降，随后在当地时间 16:00 (20:00 UTC) 几乎降至零。该公司总经理在 X 平台上发帖指出：“我们在此通知客户，@DigicelHT 的国际光纤基础设施目前出现了两处故障。”当地时间 17:00 (21:00 UTC) 之后，流量开始恢复，并在接下来的一小时内达到了预期水平。当地时间 17:33 (21:34 UTC)，总经理发帖声称，“国际基础设施中的第一根光纤已修复”，并且服务已恢复。 

11 月 25 日，该公司总经理在 X 平台上发布另一条帖子指出，公司“1 号国道上的国际光纤基础设施”已被切断。根据观察，大约一小时前，Digicel 网络流量下降，并在当地时间 02:00 - 08:00 (07:00 - 13:00 UTC) 期间完全中断。当地时间 08:22 (13:22 UTC)，总经理发布的一条 X 更新帖表示，所有服务均已恢复。

10 月 20 日当地时间 17:30 (12:30 UTC)，Cybernet/StormFiber (AS9541) 的互联网流量急剧下降，降至上周同一时段的 50% 左右。与此同时，该网络已公布的 IPv4 地址空间数量减少了超过三分之一。造成这些变化的原因是 PEACE 海底光缆受损，它在苏丹附近的红海地区遭到破坏。 

PEACE 是为巴基斯坦网络提供商传输国际互联网流量的几个海底光缆系统之一（其它还包括 IMEWE 和 SEA-ME-WE-4）。该提供商承诺在 10 月 27 日之前全面恢复服务，但在 10 月 21 日当地时间 02:00 左右（10 月 20 日 21:00 UTC），流量与已公布的 IPv4 地址空间均恢复到接近预期水平。

据报道，根据，10 月 23 日观察到喀麦隆多家互联网服务提供商出现了流量异常，原因是连接非洲西海岸各国与葡萄牙的西非海底光缆系统 (WACS) 出现问题。 

一份已发布的报告（翻译版）指出，MTN 通知用户“WACS 光缆发生了故障，随后互联网服务暂时中断”，Orange Cameroun 通知用户“由于国际接入光缆发生故障，互联网服务中断。”Camtel 发布了一条 X 帖子表示：“喀麦隆电信 (CAMTEL) 特此通知公众，2025 年 10 月 23 日凌晨，位于巴托克 (LIMBE) 的 WACS 光缆设备发生技术故障，导致全国互联网连接中断。” 

起初，受影响的网络提供商的流量在当地时间 05:00 (04:00 UTC) 左右出现下降，随后在当地时间 22:00 (21:00 UTC) 左右恢复到预期水平。流经这些网络的流量在当天波动较大，有时甚至下降 90-99%。目前尚不清楚造成流量波动的原因，可能是由于尝试将互联网流量转移到连接喀麦隆的其他海底光缆系统。在此期间，MTN Cameroon 和 Orange Cameroon 已公布的 IP 地址空间也出现下降，但 Camtel 已公布的 IP 地址空间没有变化。

据报道，中非共和国和刚果共和国的网络连接也受到了 WACS 故障问题的影响。

12 月 9 日，我们观察到多米尼加共和国互联网服务提供商 Claro Dominicana (AS6400) 的流量在当地时间 12:15 (16:15 UTC) 左右急剧下降。流量水平在当地时间 14:15 (18:15 UTC) 左右再次下降，比上周降低 77%，之后迅速恢复到预期水平。此次网络连接中断可能是由两处光纤故障造成，因为服务提供商在中断期间发布了一条 X 帖子指出，故障“导致部分服务出现间歇性中断和运行速度变慢”。Claro 公司发布了一条 X 更新帖指出，技术人员已修复断裂的光缆，全国范围内的互联网服务已经恢复。

根据 Transmisión Eléctrica Dominicana (ETED) 发布的一条 X 帖子（翻译版）可知，11 月 11 日，多米尼加共和国的输电线路故障导致了电力服务中断。此次停电影响了该国的互联网流量，导致从当地时间 13:15 (17:15 UTC) 开始，流量比上一周下降了将近 50%。流量水平一直维持在较低水平，直到 12 月 12 日当地时间 02:00 (06:00 UTC) 左右，随后 ETED 发布了一条 X 帖子（翻译版）指出：“凌晨 2:20，我们已经完成了国家电力系统的恢复，可以满足 96% 的需求。”

随后的一份技术报告指出，“最初是 138 kV San Pedro de Macorís I 变电站停电，该变电站的一条带电线路被手动断开，引发了高强度短路。保护系统立即做出响应，但故障导致附近的几条线路相继断开，将东部地区 575 兆瓦发电容量与电网其余部分隔离开来。这种失衡导致主要发电厂自动跳闸，这是发电厂内置安全机制的组成部分”。

12 月 9 日，肯尼亚多个地区遭遇大面积停电。Kenya Power 解释说，此次停电“是由肯尼亚-乌干达区域互联电网的一个故障引发，这对肯尼亚一侧的电力系统造成了干扰”，并声称“大约 30 分钟内，大部分受影响地区已恢复供电。”不过，互联网连接中断从当地时间 19:15 至 23:00 (16:15 - 20:00 UTC) 持续了将近四个小时。停电导致肯尼亚全国流量下降了 18%，其中 Nakuru County 和 Kaimbu County 的流量变化最明显。

12 月 12 日，俄罗斯无人机袭击了乌克兰境内的敖德萨地区，不仅损坏了当地的仓库和能源基础设施，而且导致该地区部分区域停电。停电中断了互联网连接，导致与上一周相比，流量下降了高达 57%。经过 12 月 13 日当地时间午夜（12 月 12 日 22:00 UTC）的首次下降后，流量在接下来的几天内逐渐恢复，于 12 月 16 日当地时间 14:30 (12:30 UTC) 左右恢复到预期水平。

飓风“梅利莎”于 10 月 28 日登陆牙买加，沿途造成了严重的损坏和破坏。随之而来的停电和基础设施损坏影响了互联网连接，因此，起初从当地时间 06:15 (11:15 UTC) 左右开始，流量下降了大约一半，最终比上一周下降了 70%。牙买加的互联网流量在飓风来临前的几天里一直远低于飓风前的水平，直到 11 月 4 日上午才开始逐渐恢复到预期水平。面对造成了大规模广泛破坏的暴风雨，一个国家/地区的互联网流量通常可能需要数周或数月时间才能恢复到“正常”水平。虽然电力供应可能在几天内基本恢复，但修复已受损的物理基础设施则需要花费更长时间。

11 月 26 日，气旋“森雅”在斯里兰卡和印度尼西亚引发了灾难性洪水和山体滑坡，造成 1000 多人死亡，破坏了这些国家的电信和电力基础设施。基础设施损坏导致多个地区的互联网连接中断，流量也随之下降。

在斯里兰卡，除西部省以外的多个地区都受到最严重的影响，多个省份的流量比上一周下降了 80% 到 95%，包括西北省、南部省、乌瓦省、东部省、北部省、中北省和萨伯勒格穆沃省。

在印度尼西亚，亚齐省和苏门答腊地区的网络中断最为严重。亚齐省的流量最初比上一周下降了超过 75%。苏门答腊地区的北苏门答腊省受影响最严重，流量最初比上一周下降了 30%，随后在下一周开始加快恢复。

10 月 3 日，印度尼西亚互联网服务提供商 Smartfren (AS18004) 的用户遭遇了服务中断。该服务提供商在一条 X 帖子中确认了相关问题，帖文指出（翻译版）：“目前，多个地区的电话、短信和数据服务出现了故障”。该服务提供商的流量从当地时间 09:00 (02:00 UTC) 左右开始下降，降幅高达 84%。中断持续了大约八个小时，流量在当地时间 17:00 (10:00 UTC) 左右恢复到预期水平。Smartfren 并未提供任何关于服务故障原因的额外信息。

英国主要互联网服务提供商 Vodafone UK（AS5378 与 AS25135）在 10 月 23 日经历了短暂的服务中断。当地时间 15:00 (14:00 UTC)，两个 Vodafone ASN 的流量均骤降至零。源自 AS5378 的已公布 IPv4 地址空间减少了 75%，而源自 AS25135 的已公布 IPv4 地址空间则完全消失。两个小时后，也就是当地时间 17:00 (16:00 UTC) 左右，互联网流量和地址空间均恢复到预期水平。Vodafone 没有在其社交媒体频道中提供任何关于此次中断原因的信息，该公司的网络状态检查器页面在中断期间也不可用。

根据一份已发布的报告，10 月 22 日，意大利网络服务提供商 Fastweb (AS12874) 的一个 DNS 解析问题导致其用户的互联网服务中断，进而导致观测到的流量下降超过 75%。Fastweb 确认了这个问题，该问题在当地时间 09:30 - 13:00 (08:30 - 12:00 UTC) 期间影响了有线互联网客户。

虽然此次网络中断并非由网络连接故障导致，但 DNS 解析问题对互联网流量的影响非常相似。如果服务提供商的 DNS 解析器出现问题，切换到 Cloudflare 1.1.1.1 公共 DNS 解析器等服务通常可以恢复网络连接。

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%。

虽然当天早些时候该国发生了一起未遂政变，但目前尚不清楚观察到的此次网络中断是否与政变相关。从路由角度来看，这三个受影响的网络都使用 Cogent (AS174) 作为上游服务提供商，因此，Cogent 的局部问题可能引发了此次短暂的网络中断。  

据报道，以色列网络服务提供商 Cellcom (AS1680) 的一份公告显示，12 月 18 日出现了“互联网连接故障，影响了部分客户”。此次故障发生在当地时间 09:30 - 11:00 (07:30 - 09:00 UTC) 期间，导致流量比上一周下降了将近 70%。一份已发布的报告指出，此次“故障”的原因可能是 DNS 解析失败。

2025 年即将结束之际，12 月 30 日，以色列网络服务提供商 Partner Communications (AS12400) 发生了重大技术故障，导致以色列全国范围内的手机、电视和互联网服务中断。此次故障发生在当地时间 14:00 - 15:00 (12:00 - 13:00 UTC) 期间，导致 Partner Communications 的流量比上一周下降了三分之二。服务中断期间，Cloudflare 1.1.1.1 公共 DNS 解析器接收的查询量激增，这表明问题可能与合作伙伴的 DNS 基础设施息息相关。不过，该服务提供商并未公开确认导致此次服务中断的原因。

第四季度，我们在 Cloudflare Radar 上推出了全新的 Cloud Observatory 页面，用于跟踪包括 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 UTC 时开始产生影响，因为错误（5xx 类）响应比例开始攀升，并在 08:00 UTC 左右达到 17%。us-east-1 中尝试连接源服务器时出现的故障数量也随之增加，并在 12:00 UTC 左右达到峰值。

事件的影响也清晰地体现在关键网络性能指标上，这些指标在整个事件期间一直保持较高水平，直到事件结束前不久（即 23:00 UTC 左右）才恢复到正常水平。在整个事件期间，TCP 与 TLS 握手持续时间逐渐变差，这些指标旨在衡量 Cloudflare 与 us-east-1 中的客户源服务器建立 TCP 与 TLS 连接所需的时间。此外，在事件发生后的最初几个小时内，Cloudflare 从源服务器接收响应标头所需的时间显著增加，之后逐渐恢复到预期水平。

10 月 29 日，Microsoft Azure 发生了一起事件，影响到其内容分发网络服务 Azure Front Door。Azure 的事件报告显示，“客户在两个不同的控制平面构建版本上执行特定顺序的配置更改，导致生成了不兼容的客户配置元数据。这些客户配置更改本身是有效且无恶意的，但它们生成的元数据在部署到边缘站点服务器后暴露了数据平面中的一个潜在错误。这种不兼容性导致在数据平面服务内进行异步处理时触发了崩溃。”

事件报告标记的开始时间是 15:41 UTC，但我们观察到，连接到 Azure 托管源的失败尝试数量在大约 45 分钟之前已开始攀升。事件发生期间，TCP 与 TLS 握手指标也变得更加不稳定，TCP 握手时间有时延长超过 50%，TLS 握手时间在峰值时延长了将近 200%。受影响的指标在 20:00 UTC 后开始改善，Microsoft 表示，此次事件于 10 月 30 日 00:05 UTC 结束。

除了上述中断之外，Cloudflare 在第四季度还经历了两次中断。虽然这些不是传统意义上的互联网服务中断，但确实导致用户在中断期间无法访问由 Cloudflare 路由和保护的网站与应用。

首次中断发生在 11 月 18 日，是由软件故障引起，该故障是因为我们数据库系统权限变更而触发，权限变更导致数据库将多个条目输出到 Cloudflare 机器人管理系统使用的“特征文件”。如需了解更多详细信息，包括根本原因分析和时间线，请参阅相关的博客文章。

第二次中断发生在 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 的图表，但底层数据均可通过 Cloudflare API 获得。您可以使用 API 来检索数据，进行本地监测或分析，也可以使用 Radar MCP 服务器将 Radar 数据集成到自有 AI 工具中。