2018年12月6日16时34分，日本软银（SoftBank）移动网全国性瘫痪，约3061万用户（含旗下Y!mobile品牌用户，据软银官方公布）语音、短信、数据业务全断，历时29小时29分才全面恢复。这不是黑客攻击，也不是光缆被挖断——按总务省事后调查，触发点竟是核心网鉴权设备在维护期间爆发软件故障，进而引发“终端重连风暴”，把设备内存活活耗尽。本文依据总务省调查结论、软银说明及NHK、路透等当时报道，完整复盘这起经典事故的时间线、根因链条、恢复难点与问责整改，并给出核心网工程师视角的五条教训。
12月6日是周四。傍晚16时34分前后（NHK等日媒事后援引软银公布的时间），软银网内大量用户突然失去服务：手机左上角信号消失或显示“仅限紧急呼叫”，电话拨不出也打不进，短信和数据业务同步失效。与寻常的局部基站退服不同，这次的投诉从北海道到冲绳同时涌现——是全网级别的故障。
从用户视角看，整个过程大致如下：
| 时间（当地时间） | 事件 | 说明 |
|---|---|---|
| 12月6日 16:34前后 | 故障爆发 | 用户大面积掉网，语音、数据、短信同时中断 |
| 12月6日 傍晚 | 官方确认全国性故障 | 软银对外承认重大故障，但表示原因正在调查 |
| 12月6日 夜间 | 修复无进展 | 官方多次公告“恢复时间未定”，社交平台恐慌蔓延 |
| 12月7日 白天 | 分批恢复 | 部分用户逐步回网，恢复进度反复 |
| 12月7日 22:03前后 | 全面恢复 | 历时约29小时29分（据日媒事后统计） |
| 事后一周内 | 监管介入 | 总务省要求软银提交原因报告与再发防止计划 |
一个值得注意的细节：故障发生在16:34，正是日本各城市晚高峰话务爬坡的起点。这意味着故障爆发时，网络本身就处于高负载状态，数千万下班路上的用户在同一时刻举起手机、发现没信号、开始反复重拨——这为后面第二节的“风暴”埋下了伏笔。
要理解这起事故，得先回忆一下终端上网的“第一道门”：鉴权。
任何一部手机要获得服务，都必须先通过网络认证：终端插入USIM卡后，发起附着或位置更新请求，核心网侧的鉴权中心（HSS/AuC）生成鉴权五元组，与终端完成双向挑战-应答，鉴权通过后终端才被允许驻留网络、建立业务。这条路径是全网站前门——门若打不开，后面的一切业务免谈。
按总务省事后调查结论与软银说明（据当时公开报道），当晚的故障链条是这样的：
flowchart TD
A["核心网鉴权设备例行维护作业"] --> B["设备软件缺陷被触发"]
B --> C["全网SIM卡认证批量失败"]
C --> D["数千万终端反复发起重连与重注册"]
D --> E["认证请求洪峰冲击设备"]
E --> F["设备会话表与内存耗尽"]
F --> G["核心设备宕机 故障向全网蔓延"]
G --> H["语音 数据 短信全面中断"]
G --> I["110 119紧急呼叫大量受阻"]
逐段拆解：
第一环：休眠的软件缺陷。 故障设备为核心网鉴权处理设备，由爱立信供货（据当时报道）。缺陷平时处于休眠状态，维护作业中的特定操作触发了缺陷路径——这也是历次“例行升级出大事”的共同剧本：不是新代码引入了Bug，而是维护动作踩中了旧代码里埋着的雷。爱立信事后确认问题出在设备软件，并向全球运营商客户发布了修复（据爱立信当时声明报道）。
第二环：鉴权失败引发重连风暴。 鉴权批量失败后，终端判定网络不可用，按照协议的退避重试机制反复发起重连。问题在于：数千万部终端的重试时钟几乎同时启动。对设备而言，每一次认证尝试都要分配处理资源与内存；当“请求-失败-再请求”形成正反馈，请求洪峰以指数级增长——这就是信令风暴在鉴权平面的具体形态。
第三环：内存耗尽，雪崩收场。 设备的会话表和内存被重连请求灌满后宕机。更糟的是，宕机本身不会让风暴平息——终端检测到网络不可用，重试只会更密集。此时故障已不可能自行收敛，只能靠人工干预打破死循环。
为什么冗余没兜住？ 按总务省调查结论的公开报道，问题设备的冗余与隔离设计不充分，故障未被限制在局部。这其实是风暴类故障的通病：主备倒换的设计前提是“正常负载可倒”，而重连风暴意味着备节点一接手，就要立刻吞下全网终端的认证洪峰——备件等于陪着主用一起死。冗余方案在纸上成立，在风暴面前不堪一击，是这起事故最刺痛工程界的教训。
29小时的时长里，真正的故障点可能几小时内就已定位。大头时间花在“怎么把网络安全地扶起来”。工程上至少有四重困难：
其一，不能一开了之。 设备重启后，如果放任全网终端同时涌入，第二次风暴会在几分钟内把刚起来的设备再次打垮。唯一可行的做法是分批、分区、限速放行用户回网，让重连流量始终低于设备的崩溃水位。这决定了恢复必然是小时级而非分钟级的精细活。
其二，终端侧行为不可控。 重连的节奏由各终端的退避算法决定，标准允许各终端厂商有多种实现，具体重试行为以各厂家实现为准。网络侧工程师没有一个“全网静默十分钟”的开关，只能在自己能控的网元侧做准入和限流。
其三，观测手段跟着受损。 鉴权设备自己病了，依赖它信令数据的排障视图也随之失真。工程师相当一部分时间是在“盲区”里拼图：从用户投诉分布、外围网元日志、设备水位曲线里反推故障边界。
其四，恢复顺序有讲究。 110、119等紧急呼叫通道以及灾害预警下发，必须优先恢复；普通用户业务的放行节奏要为紧急通道让路。软银在恢复期间反复提示用户“不要反复开关机、不要持续重拨”，本质上就是在帮网络侧压住风暴流量。
一起移动网故障的社会影响，远不止“打不了电话”：
| 影响领域 | 具体表现 |
|---|---|
| 个人通信 | 约3061万用户（软银官方公布）语音、短信、数据全断 |
| 紧急救援 | 大量110、119报警电话无法接通，成为监管追责核心（据总务省及媒体事后披露） |
| 公共预警 | 依赖移动网下发的灾害预警、紧急速报送达受阻 |
| 金融支付 | 银行ATM、刷卡与移动支付大面积受阻（据当时报道） |
| 物流出行 | 快递派送、共享单车、打车等依赖移动网的服务停摆（据当时报道） |
| 企业经营 | 依赖移动数据的门店、外勤、物联网终端集体失联 |
其中最沉重的是紧急呼叫受阻。移动通信是日本社会防灾体系的神经末梢——地震速报、海啸警报都经由移动网小区广播下发。一张覆盖数千万人的网瘫痪近30小时，意味着这29小时里整个国家在防灾层面处于“半聋半哑”状态。这也是事后总务省将整改重点放在紧急通信保障上的根本原因。
事故的问责链条很快就位。软银时任社长宫内谦出面道歉；总务省在事发后迅速启动调查，认定事故为重大通信障害，要求软银提交原因报告与再发防止计划，并给予行政指导。爱立信方面确认设备软件存在问题并致歉，向全球客户发布修复（以上均据当时公开报道）。
软银的整改方向，按其公布的再发防止计划（据当时报道归纳）主要包括：核心网设备的地理冗余与负荷分散改造、针对重连风暴的准入与限流机制、鉴权成功率等关键指标的监控强化，以及常态化的大规模故障演练。用户侧，软银向受影响用户发放了补偿（以积分等形式，据当时报道）；部分用户提起集体诉讼，案件历时数年方才了结，单个用户的获赔金额与事故的社会代价相比微不足道——这几乎是全球电信事故赔偿的通例。
真正的插曲发生在四年后。2022年7月，KDDI发生更长时间的全国断网：约61小时、影响约4000万用户，机制不同（语音交换设备维护引发的配置异常与拥塞，叠加eSIM管理缺陷），但剧本惊人相似——同样始于维护窗口，同样因雪崩式拥塞失控，同样拖了几天才恢复（以上为公开报道数据）。两起事故相隔四年、分属两家运营商，说明这类故障模式并没有被行业真正吃透：缺陷会换马甲，风暴会再回来。
把三起被广泛研究的全国级事故放在一张表里看，规律一目了然：
| 案例 | 时间 | 触发点 | 失效机制 | 时长 | 影响规模 |
|---|---|---|---|---|---|
| 软银 | 2018年12月 | 鉴权设备维护触发软件缺陷 | 认证失败引发重连风暴，内存耗尽 | 约29.5小时 | 约3061万用户 |
| Rogers（加拿大） | 2022年7月 | 核心网维护中的配置变更 | 路由信息撤收，路由表丢失 | 约19小时 | 逾千万用户 |
| KDDI | 2022年7月 | 语音网设备维护配置异常 | 语音网拥塞失控，eSIM管理缺陷放大 | 约61小时 | 约4000万用户 |
三起事故，三个国家，三种技术机制，唯一的共同点：全都始于维护窗口。
1. 把鉴权路径当成“全网站前门”来设防。 鉴权平面的容量规划不能按平均话务模型做，要按最坏情况做——全网终端同时重连的风暴容量。凡属全网公共瓶颈的网元（鉴权、DNS、DHCP、PFCP会话面），都要有准入控制和限流设计：风暴来临时，宁可让一部分终端晚十分钟上网，也不能让设备崩掉重来。
2. 冗余要做故障注入验证，不要信架构图。 主备、地理冗余画在PPT上都成立，但备份节点能否扛住“主用崩溃瞬间涌入的重连洪峰”，只有拔了主用才知道。容灾演练要注入真实规模的信令风暴，而不是切换一两千用户走个过场。
3. 维护窗口是高危时段，不是低风险时段。 三起大事故全部始于维护作业。维护操作必须有灰度与回退预案，软件变更先过影子环境；16:34的教训是“低话务时段”的判断不能想当然——傍晚话务爬坡期，任何全网级设备的操作都要掂量风暴叠加的后果。
4. 监控盯住风暴前兆指标。 鉴权成功率、注册信令量、设备会话表与内存水位，这几类指标要进核心大屏并配硬阈值。信令风暴是指数曲线，发现得晚十分钟，恢复就要多花十个小时。告警的意义不是记录死亡，而是抢救在暴发前。
5. 紧急呼叫保障要单独立项、单独演练。 110/119受阻是软银事故监管问责的核心，也是历次大断网的公共伤疤。核心网故障场景下紧急呼叫的旁路机制、恢复顺序、与监管的联动上报，必须常态化演练——这条线在哪个国家都是红线，踩线不只是技术事故，更是社会事件。
复盘这起事故，剧本朴素得令人不安：一次例行维护、一个休眠的软件缺陷、一场正反馈的重连风暴，30.61万人→3061万人的影响面，只隔着一个鉴权设备的内存条。电信网络早已不是“通信工具”，而是城市运转的神经系统——可用性指标小数点后面的每一个9，背后都是ATM机、急救电话和地震警报。设备商会修复缺陷，运营商会加固冗余，监管会下发指导，但真正值钱的是那套反复被验证的工程直觉：对维护窗口保持敬畏，对风暴保持预判，对“前门”保持冗余，对紧急呼叫保持谦卑。
毕竟，下一次例行升级的工单，可能已经躺在你的系统里了。
本文由「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 等场景全覆盖。