历史上五次最大的网络故障：Facebook消失时，850万台电脑失灵，AWS导致网络瘫痪

2026年8月14日

每隔几年，就会发生一次单一的故障，导致互联网停止像基础设施一样运作，开始显得脆弱。应用程序静默，支付终端停滞，支持热线充满了同时提出相同问题的人。下面的事件是影响最广泛的几次。

没有正式的故障排行榜，任何排名都涉及判断。我们的排名考虑了三点：受到影响的人数或设备数量、干扰持续的时间，以及后续造成的现实伤害。最后一个因素是最重要的。导致飞机停飞或使紧急电话失效的故障与干扰娱乐的故障不同，即使用户数量看起来相似。

1. Meta，2021年10月：Facebook从互联网中消失的那一天

2021年10月4日，Facebook、Instagram、WhatsApp和Messenger同时消失，持续约六个小时。原因并不是攻击。在例行维护中，配置更改撤销了边界网关协议路由，这告诉其他互联网的Meta网络在哪里。正如Cloudflare所描述的那样，Meta的DNS服务器停止了自我宣布，该公司实际上从全球路由表中抹去了自己的方向。

恢复进程因相同的依赖关系而减缓。内部工具和构建访问系统依赖于已经消失的网络，因此工程师们难以接触到他们需要修复的硬件。网络分析公司Kentik估算，损失的访问时间约为1.2万亿人分钟，这一数字反映了Meta用户基数的庞大，而不是任何单一的戏剧性后果。

使得这次故障成为我们衡量的最大故障的原因在于其影响范围。没有其他单一事件在同一时刻移除四项亿万人使用的服务。

2. CrowdStrike，2024年7月：850万台机器，和46000个航班停飞

2024年7月19日，CrowdStrike的Falcon安全软件的故障更新使全球的Windows机器陷入启动循环。微软估计大约有850万台设备受到影响，这一数字由路透社报道，并取自微软自己的评估。

后果异常明显。航空公司、医院、广播公司、银行和零售商发现员工凝视无法启动的终端。为BBC Future撰写的报道引用了FlightAware的航班跟踪数据，显示在后来的几天中约有46000个航班延误或取消。

恢复进程缓慢，因为许多机器需要手动干预，在一些情况下需要进入安全模式以删除一个文件。需要人为接触每个受影响设备的故障无论响应团队规模多大都不会快速缩减。

3. 亚马逊网络服务，2025年10月：当一个地区承载整个网络时

2025年10月20日，亚马逊网络服务在弗吉尼亚州北部的US-EAST-1区域发生故障，服务中断超过十五小时。网络监控公司ThousandEyes追踪到导致故障的原因是影响DynamoDB数据库服务的DNS解析失败，然后在依赖于该服务的系统中引发连锁反应。

由于US-EAST-1是最古老和使用最频繁的AWS区域，受到影响的范围远超亚马逊。TIME的报道描述了消费者应用程序、游戏、金融服务和工作工具等服务的中断，包括那些之间没有明显关联的服务，除了共享同一云区域。

此事件说明了一个结构性问题，而不是一种新颖的故障。集中带来相关性：当网络的较大份额依赖于同一地区时，区域性问题表现得像全球性问题。

4. 罗杰斯，2022年7月：一个国家级网络和紧急电话

2022年7月8日，加拿大运营商罗杰斯通信遭遇无线和有线网络的全国范围故障，持续大部分一天。在随后的审查中，加拿大广播电视和电信委员会记录到大约1200万用户在核心网络进行维护更改后失去了服务。

严重性源于手机以外的事情。Interac支付服务失败，使零售商无法接受卡片支付，一些客户无法拨打911。CBC新闻的报道记录了这两种影响，而紧急呼叫失败促使监管方面的审查和官方关于网络韧性的承诺。

按人口排名，这一事件比上面三个要小。按每个受影响人员的伤害排名，可以说是名单上最严重的。

5. Dyn，2016年10月：使主页离线的攻击

2016年10月21日，DNS提供商Dyn遭到了一次峰值约为每秒1.2太比特的分布式拒绝服务攻击，这一攻击由Mirai僵尸网络生成，使用的是受到损害的消费设备，如摄像头和路由器。

由于Dyn解析了许多知名网站的域名，这次攻击使许多网站几乎同时出现故障。正如《卫报》当时报道的那样，包括Twitter、Spotify、Reddit和Netflix等服务对北美和欧洲的用户变得无法访问。安全记者布莱恩·克雷布斯（Brian Krebs）在KrebsOnSecurity的账户中追踪到攻击流量来自遭到攻击的摄像机和数字录像机。

它因与其他事件不同的原因而占据一席之地。这是行业意识到不安全的消费硬件可以形成基础设施规模的力量的时刻。

这五个事件的共同点

这个模式令人不安。五个事件中有四个是自我造成的：路由更改、软件更新、DNS依赖、维护错误。只有Dyn的攻击是恶意的。互联网历史上最大的干扰大多来自于可信系统内部的常规工作失误，而不是对手的攻击。

第二种模式是依赖。在每种情况下，损害都是通过某种共享的东西传播的，无论是路由表、安全代理、云区域、运营商核心还是DNS提供商。韧性失效并不是因为某个组件出现故障，而是因为过多的东西同时依赖于这个组件。

那些刚好错过的事件值得提及：2021年6月Fastly配置错误，短暂导致大量主要新闻和政府网站瘫痪，以及2017年2月亚马逊S3的故障，该故障中断了整个网络中对存储的依赖服务。这两起事件都很严重，但都不及以上五个事件的影响范围或持续时间。

提前知道并不能防止故障。它会改变你的反应。

这些故障都无法通过监测来防止。监测改变的是发生故障和你得知故障之间的间隔，这通常是可以避免的成本积累的地方：工作人员排查错误的事情、客户未被告知、在情况不明时决策延迟。

Status Is Down跟踪数千个服务和网站的可用性，因此当共享依赖关系出现故障时，你可以查看问题是出在自己还是他们。你可以在我们的实时故障视图上检查当前情况，浏览报告的服务中断或网站目录，查询这五起事件所属于的类别：社交媒体与网络、网络和云托管、电信与互联网及在线支付与钱包。

我们的故障报告会在事件发生时覆盖这些事件。如果你宁愿被通知而不是自己去检查，我们的监测计划为你依赖的服务添加了警报，你可以创建账户以开始跟踪它们。我们无法阻止下一次大规模故障。我们可以确保你不是最后一个得知的人。

查找服务或网站