概述：2020年6月15日，美国第二大运营商T-Mobile发生建网以来罕见的全美性语音故障：约1亿用户的电话打不出、短信发不出，但手机上网一切正常，故障持续约13个小时。本文以T-Mobile官方说明与当时多家媒体的公开报道为主轴，按时间线复盘这次事故：一条租用光纤电路失效，如何绕过“冗余倒换”这道防线、演变成语音核心的信令风暴，最终放倒全美语音网。对正把语音全面搬上IP的运营商来说，这是一堂绕不开的公开课。
2020年6月15日，美东时间中午前后，T-Mobile的用户开始大面积发现：电话拨不出去，也打不进来，短信发不出去。投诉曲线在Downdetector（全球最大的网络故障众包监测平台之一）上陡然拉起，据当时统计，故障报告峰值超过10万条，创下该平台电信类故障报告的纪录（Downdetector）。
最先发现异常的往往是运气好的人。当天美国社交媒体上流传着一种奇特的对照：微信式应用一切正常，打电话彻底瘫痪——iMessage能收发（走数据通道）、WhatsApp视频照打、网页照刷、视频照看，唯独运营商的语音电话和短信“失联”。这个特征后来成为判断故障层次的关键线索：数据面活着，语音的会话与信令面瘫了。
受影响范围很快清晰：
值得强调一个背景：这一天是美国疫情居家令的高峰期。远程办公、网课、远程问诊、外卖与网约车的短信验证码，全部压在“能打通电话、能收到短信”上。语音的价值在那个下午被重新定价——平时你觉得电话是“附属业务”，等它瘫了你才发现，整个社会的协作都挂在上面。
对电信人来说，这次事故最扎眼的一点和罗杰斯、KDDI如出一辙：故障不是发生在无线侧某个基站，而是发生在把全国语音缝合在一起的核心层面。无线侧倒下是局部阵痛，核心层倒下是全业务归零。
先把公开信息可以拼出的时间线铺开（时间均为美东时间，依据T-Mobile官方通报与当时媒体报道综合，个别时段为约数）：
| 时间（2020-06-15/16，美东） | 事件 | 依据 |
|---|---|---|
| 15日约12:00起 | 全美用户大规模报告语音、短信失败，投诉曲线陡增 | Downdetector统计、社交平台 |
| 15日午后 | 故障定性：语音网络问题，数据上网正常；排除网络攻击 | T-Mobile官方通报 |
| 15日午后至傍晚 | 工程团队隔离失效电路，疏导语音信令，分区分域恢复 | T-Mobile事后说明 |
| 15日夜间 | 故障面逐步收缩，恢复进展对外滚动披露 | 时任CEO社交账号 |
| 16日凌晨约1点 | 语音、短信服务全面恢复，全程约13小时 | T-Mobile通报 |
| 16日白天 | CEO发布首次完整公开说明，解释故障并致歉 | T-Mobile官方博客 |
| 17日 | 发布技术性复盘说明，承诺加固冗余与故障隔离 | T-Mobile官方博客 |
timeline
title T-Mobile 6·15断网13小时
6月15日 约午间 : 语音短信全国性失败 : 投诉曲线陡增
6月15日 午后 : 定性语音网络故障 : 排除网络攻击
6月15日 傍晚 : 隔离失效电路 : 分区分域恢复
6月16日 凌晨 : 语音短信全面恢复 : 全程约13小时
6月16日 白天 : CEO首次完整说明 : 公开致歉
6月17日 : 技术性复盘 : 承诺加固冗余
两个细节值得注意。其一，13小时不算最快的恢复——KDDI用了61小时、罗杰斯用了19小时，T-Mobile的成绩单在“全美级故障”里算体面的；其二，13小时也不算快——故障定性其实很快（当天下午就明确了层次和范围），真正耗时间的是把被连锁异常搅乱的语音路由一点点捋回去，且不能在恢复过程中引发二次风暴。
按T-Mobile事后向监管机构与公众披露的口径（时任CEO Mike Sievert于6月16日至17日先后发布公开说明），这次故障的起点平淡到令人不适：一条租用光纤电路失效（多家当时报道称位于费城地区，未经官方逐字证实）。光缆被挖断、电路闪断，对任何一张大网来说都是每天都在发生的“日常磨损”。真正的问题在后面三段。
第一段：冗余倒换没有接住。 一条电路失效，网络的第一道防线是自动倒换到备份路径。但T-Mobile承认，失效发生后，本应生效的冗余机制没有按预期工作，重路由过程反而引发了语音网络的连锁异常。换句话说，图纸上的冗余不等于运行中的冗余——备份路径存在，但它没有在真实故障中完成自己的使命。
第二段：故障域没有锁住，语音核心被拖垮。 语音全IP化之后，T-Mobile这样的运营商语音业务跑在IMS（IP多媒体子系统）上：终端经EPC附着后，语音会话的信令集中处理，网间互连也经由统一的出口。失效电路所承载的互连与汇聚流量在重路由时搅动了这张信令网，IMS语音核心出现大面积异常，终端呼叫失败。与此同时，海量终端在呼叫失败后自动发起重新注册——数千万台设备同时反复重试，注册风暴进一步放大了核心网负载，形成“越失败越重试、越重试越失败”的正反馈环。
第三段：互连故障让故障跨网传染。 因为受影响路径恰好牵涉网间互连，其他运营商的用户呼叫T-Mobile号码也在失败。这是全IP语音时代的新形态：过去一张网瘫了，隔壁网只是忙一点；现在互连点的异常会让“他家的问题”直接体现成“我打不出电话”。
flowchart TD
A["租用光纤电路失效"] --> B["冗余倒换未按预期生效"]
B --> C["语音路由连锁异常"]
C --> D["IMS语音核心过载"]
D --> E["终端大规模反复注册"]
E --> F["注册风暴放大过载"]
F --> D
D --> G["VoLTE语音瘫痪"]
D --> H["短信瘫痪"]
A --> I["互连流量异常"]
I --> J["他网呼叫T-Mobile号码失败"]
G --> K["应急呼叫受影响的担忧"]
K --> L["监管机构关注"]
理解了这条链，就能回答当天所有用户的那个困惑：为什么能刷视频却打不出电话？ 数据业务走的是分组转发通道，故障发生在语音的会话与信令层面。这正是全IP化的悖论——IP让业务部署更灵活，也让故障形态变得反直觉：无线信号满格、数据满速，语音却全瘫。三场近年著名的事故里都能看到同一个“风暴”影子：软银2018年认证风暴、KDDI 2022年信令拥塞、T-Mobile 2020年注册风暴。终端的指数级重试，是核心网故障从“异常”升级为“灾难”的共同放大器。
把13小时的账摊开算，这次故障的杀伤半径远超“打不了电话”：
还有一个容易忽略的维度：这次故障发生在T-Mobile与Sprint合并后刚满两个半月。两网融合期正是网络变更最密集、路由策略最不稳定的阶段。虽然官方说明未将故障归因于整合工作本身，但对所有正在做网络合并、演进、搬迁的团队来说，这是一个值得记下的时间相关性——大规模架构动作与重大故障之间的因果，往往藏在“恰好那个阶段”里。
做对了什么。 第一，危机沟通是教科书级的。时任CEO当天傍晚即在社交平台发声，明确“不是网络攻击”，16日凌晨宣布恢复，白天发布署名的完整说明，17日再发技术性复盘——三段式披露，节奏清晰，且由最高层出面。对比之下，KDDI、罗杰斯的深度披露都是在监管压力下才完成的。第二，快速排除了安全攻击叙事。全美级故障第一问永远是“是不是被黑了”，及时排除让工程团队能专心抢修，也避免了用户恐慌。第三，恢复策略克制。面对注册风暴，团队没有选择一次性放量恢复，而是分区分域逐步放量——这是对的，一次性放开等于手动制造第二次风暴。
失误在哪。 第一，冗余倒换从未在真实故障中验证过。这是整场事故的总根源，也是所有“纸面冗余”的通病。第二，对租用电路的物理路由缺乏产权级核查——如果备份路径与主用路径物理同沟同桥，冗余就是自欺欺人。第三，终端重试行为缺乏治理，注册风暴把可控故障放大成了全国灾难。第四，13小时的恢复时长说明故障隔离手段不足——理想状态下，一条电路失效的爆炸半径应该被锁死在一个区域。
把这次事故放进本栏目复盘过的重大故障坐标系里，规律会更加刺眼：
| 事件 | 时长 | 规模量级 | 诱因类别 | 一句话本质 |
|---|---|---|---|---|
| T-Mobile 2020语音瘫 | 约13小时 | 约1亿用户语音短信 | 物理断纤+倒换失效 | 冗余没经过实测 |
| KDDI 2022 | 61小时 | 最多约4000万 | 割接+IP地址配置冲突 | 自动化配置失守 |
| 罗杰斯 2022 | 约19小时（不同口径至26小时） | 数百万至千万级 | 维护变更+设备清退遗留 | 变更流程失守 |
| AT&T 2024 | 12小时 | 约1.25亿台设备波及 | 变更操作失误 | 回滚机制失灵 |
| 软银 2018 | 约29小时 | 约3000万+ | 软件证书过期引发认证风暴 | 生命周期管理缺位 |
| Optus 急救线事故 | 13小时 | 急救呼叫受阻 | 防火墙升级变更 | 第三方设备变更事故 |
六场事故，没有一场是黑客干的，没有一场是天灾，全部始于“变更、配置、失效与冗余”这条最日常的战线上。而T-Mobile这一场提供了其中最特殊的样本：它是唯一的“物理层失效直接击穿冗余设计”案例。软件故障可以靠回滚，配置故障可以靠审计，但一条光纤断了之后拼的是设计冗余时留下的每一道防线是否真的存在、真的能用。
1. 冗余倒换必须“故障注入式”实测。 把倒换当成按季度执行的例行演练：在真实流量下人为断主用、看备份能否无感接住。没被实测过的冗余，在拓扑漂移几个月后往往只剩一个好看的配置项。KDDI、罗杰斯、T-Mobile三场事故共同的死因，都是“设计上有，运行中没有”。
2. 租用电路当自有资产管理。 向电路供应商索要物理路由资料，核查主备是否同沟、同桥、同管道。物理同沟的两条“冗余”电路，在挖掘机面前就是一条。产权在别人的冗余，责任在自己头上的故障。
3. 终端重试行为要治理。 核心网故障时，终端的重注册风暴是放大器。应在网络侧预设注册限流与过载保护策略；3GPP对过载控制提供了标准机制，标准允许多种实现，具体行为以各厂家官方文档为准——但“有没有做”是运营商的工程态度问题，不是设备商的选项问题。
4. 互连点按“全国故障”做演练。 网间互连是故障跨网传染的通道。演练场景要包含“互连路径异常时，本网与他网用户的呼叫体验如何退化”，而不是只测本网内闭环。
5. 语音可用性指标换口径。 别用全国平均值衡量语音——平均值会把一亿人的13小时稀释成漂亮的99.99%。用“全国最差区域口径”做语音KPI，故障隔离的设计压力才会真实传导到架构上。
6. 把危机沟通写进故障预案。 一小时首公告、排除攻击声明、CEO出面的完整说明、技术复盘的披露时间表——这四件套应当在故障发生前就写好模板。T-Mobile证明了：同样的故障时长，沟通做得好，品牌甚至能全身而退。
六年过去，语音这件事非但没有退场，反而更重了：VoNR把语音进一步压进5G核心网、卫星直连手机把应急呼叫抬上天空、各国监管对急救呼叫可靠性的罚则逐年加码。语音所承载的社会功能越来越关键，而它的底层脆弱性——信令集中、终端风暴、互连传染、冗余失验——和2020年6月那个下午一模一样。
T-Mobile 6·15事故留下的核心教训只有一句话：冗余不是买来的设备，是实测过的行为。每一条“备份路径”，都要在某个季度演练的深夜里，被真实地断一次、验证一次。否则它只是一份安慰性的拓扑图，等你最需要它的时候，它和你一起瘫在原地。
本文由「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 等场景全覆盖。