概述：2021年10月4日15:39（UTC），Facebook、Messenger、Instagram、WhatsApp在全球范围内集体失联，持续六到七个小时，Downdetector收到超过1000万份故障报告，创当时历史纪录。事后复盘显示：引爆它的不是黑客、不是光缆被挖断，而是维护中发出的一条骨干网容量评估命令，加上一个审计工具的Bug，再叠加一套“DNS失联就自撤路由”的联动设计。本文以Cloudflare工程团队的路由侧复盘和Meta官方工程博客为主轴，按时间线拆解这次互联网史上最著名的断网事故，并给出通信运维视角的四条作业。

目录

• 事发：15:39，全球一起“拔网线”
• 一张时间线表，看懂六小时
• 根因：三层设计的完美风暴
• 恢复：为什么修了六个小时
• 影响面：这一跤摔掉多少钱
• 给通信人的四条作业
• 参考来源

事发：15:39，全球一起“拔网线”

2021年10月4日，北京时间深夜、美国西海岸清晨、欧洲傍晚。全球用户陆续发现，Facebook打不开了，WhatsApp消息转圈发不出去，Instagram刷新一片白。这不是区域性劣化，而是全球同时熄灯。

Cloudflare的工程师是最早察觉异常的第三方之一。15:51 UTC，他们内部立项了一个事件工单，标题是“Facebook DNS解析返回SERVFAIL”——一开始还以为是自己家1.1.1.1递归解析器出了问题，准备去状态页发公告时才发现：不是我们的问题，是Facebook整个从互联网上“消失”了。Cloudflare的描述很形象：就好像有人把Facebook所有数据中心的网线同时拔了。

从协议层看，事情一目了然。15:39 UTC起，Facebook的自治域（AS32934）开始大规模撤回BGP路由公告，其中致命的一条：它把自家全部权威DNS服务器所在的IP前缀一并撤掉了。路由没了，全球任何一台递归DNS都连不上Facebook的权威服务器，dig facebook.com一律返回SERVFAIL。Cloudflare在文章里贴出了route-views的实测输出——% Network not in table，那两个前缀从全球路由表里被整个抹掉了。

用户端的表现则五花八门。App打不开、网页报DNS错误是基本盘；依赖"Log in with Facebook"登录的第三方网站跟着遭殃，一批没有其他登录方式的用户被彻底锁在门外。更讽刺的是Facebook内部：据《纽约时报》报道，员工连工牌刷门禁、订会议室都失灵了——这些内部系统同样依赖那套已经瘫痪的DNS和内网服务。工程师发不出外部邮件、连不上公司通讯录，Zoom和Google Docs的企业认证也挂了。修复事故的人，自己先被困在了事故里。

对通信工程师来说，这个场景一点都不陌生。一张网在凌晨时分因一次例行变更整体趴下、告警系统跟着失明、修复人员进不了“机房”——这一整套戏码，运营商核心网 decade 里演过不止一次。区别只在于：Facebook这张“网”的用户数，是普通运营商的十倍。

一张时间线表，看懂六小时

把Cloudflare实测数据、Meta官方复盘和维基百科汇总的媒体报道对齐后，整场事故的关键节点如下（均为UTC时间）：

从15:39到22:50，整整七个小时，比一般运营商重大故障的MTR（平均修复时间）目标高了两个数量级。为什么修这么久？这恰恰是本次事故最值得复盘的部分，下面按“根因—恢复—影响”三层展开。

根因：三层设计的完美风暴

Meta工程副总裁Santosh Janardhan在事发次日发布的官方博客，把根因讲得非常坦率。这不是单一故障，而是三层问题叠成的正反馈，每一层单独看都不致命，摞在一起就是全球大断网。

第一层：一条命令加一个Bug（引爆点）。Facebook用一张自建的全球骨干网把所有数据中心连成一体，日常维护中经常要把骨干网的一部分摘下来检修。事发时，工程师发出了一条本意是“评估全球骨干网容量可用性”的命令，这条命令却意外断开了骨干网的全部连接——相当于瞬间把所有数据中心之间的“光缆”全拔了。按流程，这类危险命令上线前应有审计工具把关，但那个审计工具自己存在Bug，没能拦住它。双保险，变成了零保险。

第二层：“健康才广播”的反噬（放大器）。Facebook的权威DNS服务器部署在独立于骨干网的网络上，本意是隔离风险。但它有一条联动设计：一旦DNS服务器发现自己连不上Facebook的数据中心，就判定“网络不健康”，主动撤掉自己的BGP路由公告——免得用户连上一个后端全断的DNS。这个设计的出发点无可指摘，但骨干网整体被拔掉后，全球每台Facebook DNS服务器都自检失败，于是集体闭嘴。结果是一种很别扭的状态：DNS服务器本身活得好好的，但全世界找不到去它们家的路。用电信的行话说，这是一次典型的fail-safe设计退化成了fail-dead——保护机制本身成了故障放大器。

第三层：人机合力重试风暴（雪崩）。解析失败后，真正的流量海啸才刚开始。Cloudflare的复盘记录了1.1.1.1上的实测曲线：一方面App“不接受错误作为答案”，拿到SERVFAIL就疯狂重试；另一方面终端用户也在人肉重试——刷新页面、杀掉App重新打开，有时同样疯狂。两股力量叠加，全球公共DNS承载的查询量达到平时的30倍，一些体量小的递归服务被拖慢，连带Gmail、TikTok、Snapchat的用户都感知到了卡顿——Google公共DNS自己也出现了明显减速。这与移动网络里的信令风暴是同一个物理模型：故障让终端重试，重试让故障加重。

三层级联画成图，是这样一条雪崩链：

flowchart TD
    A["例行维护<br/>评估骨干网容量"] --> B["命令误发<br/>断开全部骨干连接"]
    B --> C["审计工具Bug<br/>未拦截"]
    C --> D["全球数据中心<br/>互相失联"]
    D --> E["DNS服务器<br/>自检失败"]
    E --> F["自动撤掉<br/>BGP路由广播"]
    F --> G["全球解析不到<br/>Facebook域名"]
    G --> H["App与用户<br/>疯狂重试"]
    H --> I["公共DNS查询量<br/>暴涨30倍"]
    I --> J["殃及其他平台<br/>普遍变慢卡顿"]

需要说明的是：第一、二层的事发机理以Meta官方博客与Cloudflare复盘的交叉印证为准；第三层的“30倍查询量”是Cloudflare自家网络的实测数据，口径仅限1.1.1.1。

恢复：为什么修了六个小时

根因清楚了，按理说把命令回滚就行。但Facebook的工程师很快发现，他们面对的是两只拦路虎。

第一只虎：所有远程通道全断了。数据中心之间的连接没了，主用管理通道自然不通；就连为这种场景准备的带外（out-of-band）管理网，也依赖那套已经瘫痪的基础设施。Cloudflare的外部视角证实了这一点：从15:40到21:00之间，Facebook网络上几乎没有任何路由层面的动静——不是没人修，是修复动作根本推不下去。远程全部失效后，Meta只能派工程师人肉赶赴数据中心现场操作服务器。

第二只虎：连进门都难。据维基百科汇总的媒体报道，恢复工作是在加州圣克拉拉的数据中心完成的。这些设施按高等级物理安防设计——本意是防攻击者，结果是“很难进去，进去了硬件和路由器也被设计得难以改动”。启用安全访问协议、获得现场操作权限，每一步都比平时慢。Meta官方博客坦承：这种日常安全加固在面对自家误操作时，确实拖慢了恢复速度；但官方同时认为这个权衡是值得的——安全性平时更重要。这话是否成立，读者可以自行判断。

第三道坎：不敢一键全开。骨干网恢复后，Facebook没有立刻把服务全部拉起。官方博客透露，故障期间个别数据中心的用电功率骤降了“数十兆瓦”的量级——这意味着服务器大规模停摆、缓存全空。如果瞬间恢复全部流量，电力系统、缓存层都可能被回弹的洪峰冲垮，引发第二轮崩溃。好在Meta常年在内部搞“storm”演练（模拟某个服务、数据中心甚至整个区域离线，压测全部基础设施），团队有分段恢复的成熟预案，最终各服务相对平稳地回血。但官方也承认：此前的演练从未模拟过“全球骨干网整体下线”这种场景，以后要补上。

给运维同行划一个重点：这次恢复的本质难点不是“找到根因”（协议层数据15:58就看清了），而是失去了对基础设施的一切操作手段。这一点对所有大型网络——包括电信网——都成立。

影响面：这一跤摔掉多少钱

六个半小时的全球断网，账单远不止股价。下表汇总维基百科引用CNBC、Bloomberg、CNET、Fortune等媒体报道的数据（第三方统计口径，未经Meta官方确认的项均已标注来源属性）：

账面之外还有两笔隐形成本。其一，第三方生态被殃及：所有用"Log in with Facebook"做登录的网站都被连坐，一批用户当天彻底无法访问自己的账号。其二，对发展中市场的冲击：大量用户依赖Facebook的Free Basics免费上网计划获取信息，断网直接影响了当地的通信、生意甚至人道救援协调——对这些人来说，Facebook不是“某个App”，而是他们接入互联网的全部。

作为对比，有意思的一个细节是：这场大断网发生在当时全球用户量最大的互联网平台身上，但它毕竟只是“一家公司消失”。同样的机理若发生在运营商骨干网或公共信令网上，波及的就是紧急呼叫——这也是为什么各国监管对电信重大故障的处罚和整改要求，比对互联网公司严格得多。

给通信人的四条作业

以下是笔者基于十八年核心网与运维一线经验，对这次事故的解读，属观点性内容，供同行参考。

第一，检验你的fail-safe是“降级”还是“消失”。“健康才广播”的设计逻辑，电信网里随处可见：小区失联自动去激活、会话边界设备在后端不可达时拒绝注册、网元健康检查不过就踢出资源池。这些设计的共同隐患是：当“健康信号”本身因上游故障而不可信时，保护机制会引发雪崩式自关闭。设计评审时要多问一句——上游整体失联时，本单元是应该降级服务（保留最小能力、标记降级状态），还是整体消失？Facebook的答案是后者，代价是七小时。正确的姿势是前者：宁可带着降级标识继续干活，也不要把自己从全网路由表里抹掉。

第二，重试必须带背压，全网层面要有过载控制。30倍的DNS查询风暴与移动网络的信令风暴同源同型：日本KDDI 2022年、软银2018年的两次全国性大故障，走的都是“故障引发终端海量重注册/重试，重试压垮更多网元”的同一条路径。运营商侧的对策是一套组合拳：终端退避加随机抖动，网络侧网元过载时主动返回明确的重试指示而非静默丢弃，SIP/ Diameter这类信令协议启用过载控制机制，把“用户的不耐心”从正反馈掰成负反馈。互联网公司的DNS重试风暴和电信网的注册风暴，在数学上是同一个方程，值得放在同一张教材里讲。

第三，带外通道要真的“外”。这次事故里最扎眼的细节是：主用通道和带外通道一起失效。很多网络的“带外管理”其实经不起推敲——物理上同沟同槽、电力上同源同柜、人员上是同一批运维。检验标准只需一条：把生产网整体拔掉，你还能看到设备吗？如果答案是否，那不叫带外，叫第二把挂在一把钥匙上的锁。对核心网机房而言，独立的物理通道、独立的供电、独立权限的紧急进场流程，三样缺一不可。

第四，变更闸门自己也要被审计，恢复动作要演练。一条能拔掉全球骨干的命令，唯一的闸门是一个有Bug的审计工具——单点防护形同虚设。变更管理的关键不在“有审批”，而在审批链路上没有共同故障点：命令灰度执行、分域生效、随时可停，高危命令强制双人复核加自动回滚脚本。同样重要的是演练覆盖面：Meta的storm演练救了恢复阶段，但他们自己承认没练过“骨干整体下线”。运营商的黑天鹅演练清单里，应该主动加入“最核心的共享依赖整体失效”这一项——公共信令网、统一DNS、集中化网管，每一个都是候选场景。

最后说一句题外但重要的话：这次事故里，Facebook的损失是六千万美元广告费和一天股价；但如果同样的“一条命令”落在承载紧急呼叫的电信网上，代价的计量单位就不是钱。这就是为什么运营商的变更窗口、审批流程和演练密度，理应比互联网公司更苛刻——这一点，值得每一个正在“互联网化”的网络团队自省。

参考来源

1. Understanding How Facebook Disappeared from the Internet — Cloudflare Blog — Cloudflare路由工程师Tom Strickx与Celso Martinho的“外部视角”复盘，BGP撤回时间线、DNS解析实测、30倍查询风暴曲线均出自此文，是本文的技术主轴之一
2. More details about the October 4 outage — Meta Engineering — Facebook工程副总裁Santosh Janardhan事发次日的官方复盘，骨干网命令误发、审计工具Bug、DNS联动设计、现场恢复与storm演练细节均出自此文
3. 2021 Facebook outage — Wikipedia — 时间线与影响面数据的汇总条目，引用《纽约时报》、BBC、CNBC、Bloomberg等媒体报道，用于交叉验证与第三方影响数据

本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。