2022年7月2日凌晨1时35分，日本第二大移动运营商KDDI（au品牌）因一次传输网路由器维护作业中一条路由配置错误，引发终端注册请求重传风暴，VoLTE节点与签约数据库相继拥塞，导致全国语音与数据服务瘫痪61小时25分钟，波及超过3900万用户，机场地勤、银行ATM、铁路货运、气象观测大面积停摆。本文以KDDI官方事故说明与日本总务省监管文件为锚，逐层拆解这条“配置错误→重传风暴→全国拥塞→恢复困难”的完整故障链，以及它留给全球网优运维人员的四条教训。
KDDI是日本用户规模第二的移动运营商，旗下有au、UQ mobile、povo三个品牌，还向乐天等MVNO提供全国漫游。2022年7月2日（周六）凌晨1点35分（日本时间），KDDI网络开始出现大规模通信故障，官方事后确认的影响窗口一直持续到7月4日（周一）下午3点，合计61小时25分钟，范围为全国。
按照KDDI提交给总务省的口径，受影响用户为：语音（VoLTE）约2278万人（以故障期间呼出量与平时人均呼叫量之差折算），数据（4G/5G）用户765万以上（以位置登记数差值的最大值计）。而 Light Reading 的报道给出了更大的口径：算上三大品牌及租用其网络的MVNO，超过3900万用户受到影响。社长高桥诚在周日早晨的记者会上道歉，承认这是公司历史上最大规模的通信故障（据 Japan Times 报道）。
事故当天，日本总务相金子惠义即依据《电气通信事业法》认定其为“重大事故”——该法的认定门槛是影响3万以上用户且持续1小时以上，KDDI这次事故超标了三个数量级。
| 项目 | 内容 |
|---|---|
| 发生时间 | 2022年7月2日 01:35（JST） |
| 恢复时间 | 2022年7月4日 15:00（合计61小时25分钟） |
| 影响范围 | 日本全国 |
| 语音受影响用户 | 约2278万（KDDI官方口径） |
| 数据受影响用户 | 765万以上（KDDI官方口径） |
| 总影响规模 | 超3900万（含MVNO，Light Reading口径） |
| 直接诱因 | 多摩站点全国传输网路由器维护中路由配置错误 |
| 根因定性 | 变更准备不足＋非标状态拥塞预案缺失＋恢复流程缺失 |
timeline
title KDDI断网61小时关键节点
2022-07-02 01:35 : 多摩传输网路由器维护作业中路由配置出错
2022-07-02 凌晨 : 位置更新信令被丢弃引发重传风暴 : VoLTE节点拥塞扩散
2022-07-02 上午 : 确认全国性故障 : 大量手机显示圈外 : 社长记者会道歉
2022-07-02 至 03日 : 限流扩容多路并进 : 拥塞反复拉锯
2022-07-03 : 断开全国18台VoLTE节点中的6台 : 切断终端重传源头
2022-07-04 15:00 : 通信量恢复至前一周水平 : 官方计时结束
2022-07-28 : 向总务省提交重大事故报告书
2022-08-03 : 总务省发出行政指导
2022-11-01 : KDDI提交整改落实报告
需要说明的是，事故初期外界对根因有多种猜测。Light Reading 在7月4日的报道中写道，"一种说法是语音交换平台在例行维护中被替换，另一种说法是更换核心路由器"——当时KDDI尚未给出详细解释。直到7月29日KDDI发布正式说明，链条才完全清晰：故障源是传输网路由器的路由配置错误，而不是交换设备硬件损坏。设备商背不了这个锅，这是一次彻头彻尾的“人的错误＋流程的失败”。
KDDI官方的事故说明把故障链分为三步，我们对照移动网络的标准工作原理逐层拆开。
第一击：路由配错，位置更新包被丢弃。 手机要打通VoLTE电话，前提是先完成位置登记（Location Registration）——终端把自己的位置区通报给网络，网络据此知道“你在哪个池子里”，来去话才可能接续。7月2日凌晨，KDDI在多摩（东京都多摩地区枢纽站点）对全国传输网路由器做维护，作业中路由配置错误，导致发往该方向的位置登记请求被静默丢弃。对终端来说，请求发出去石沉大海，按照协议机制只能一轮又一轮加速重传——短时间内，海量终端的重传信令涌向多摩的VoLTE节点，瞬间将其压垮。
第二击：分布式处理把火引向全国。 KDDI的VoLTE节点之间存在分布式处理机制：一个节点过载时，话务和信令会经全国传输网分流到其他节点。这个平时提高可用性的设计，在故障态成了火势蔓延的通道——多摩的过载被“复制”到了全国各地的VoLTE节点。
第三击：签约数据库被打爆。 VoLTE节点和移动网络设备（PGW，分组数据网关）每次处理业务都要到签约数据库（Subscriber DB，即HLR/HSS类网元）做鉴权认证。节点拥塞后处理超时、触发重传，每一次重传都意味着对数据库的又一次鉴权查询。信令流量指数级膨胀，全国签约数据库随之拥塞——这是整张网的“心脏”，它一停，所有用户的状态查询、鉴权、登记全部停摆。
第四击：限流无效，物理断开6台节点。 KDDI对数据库实施了流量控制，但拥塞未消——部分VoLTE节点仍在持续发出超额信令。最终的处置方式相当“壮士断腕"：将全国18台VoLTE节点中的6台直接断开，让挂在这些节点上的终端彻底收不到响应、停止重传，数据库负荷才终于回落。这一步之后，恢复工作才真正开始推进。
flowchart TD
A["多摩传输网路由器维护作业"] --> B["路由配置错误"]
B --> C["位置登记请求被丢弃"]
C --> D["海量终端加速重传"]
D --> E["多摩VoLTE节点拥塞"]
E --> F["分布式处理分流至全国节点"]
F --> G["全国VoLTE节点拥塞"]
G --> H["节点与PGW反复向签约DB发起鉴权"]
H --> I["签约数据库全国性拥塞"]
I --> J["手机显示圈外，语音数据全停"]
I --> K["对DB实施限流"]
K --> L["拥塞未消除，部分节点持续超发信令"]
L --> M["断开18台VoLTE节点中的6台"]
M --> N["重传源头切断，负荷回落"]
N --> O["逐步恢复，7月4日15时全量恢复"]
值得强调的是KDDI自己在复盘报告里写下的三个定性，这三句话比任何技术细节都更扎心：
三条对应的是变更管理、容量韧性、应急预案三块短板，全部是流程与人的问题，没有一条是设备的问题。
很多人第一反应是：一个路由配错，改回来不就行了？为什么拖了两天半？答案是：错误改回来之后，网络已经进入了一种“错误的自洽状态”，你面对的不再是原故障，而是拥塞本身。
这里要先讲清楚移动网的一个底层机制。按照3GPP的通用设计，网络在过载时可以拒绝终端的附着/位置更新请求，并通过信令下发退避定时器，要求终端在定时器到期前不得再次发起请求——这是保护网络不被“雷群效应”（thundering herd，即海量请求同时重试）压垮的标准手段。以下分析基于这一通用机制（KDDI官方说明仅描述了“终端持续重传”的现象与“断开节点以消除终端重传”的处置，未公布协议层细节）。
KDDI这次事故里，拥塞控制机制实际上经历了三次失灵：
其一，重传未被第一道闸门拦住。 路由错误导致的丢包不是显式拒绝——终端收不到拒绝信令，也就拿不到退避指令，只能按协议自身的重传节奏不断重试。发起到被丢弃，全程没有任何“让终端等一等”的反馈，重传风暴愈演愈烈。
其二，限流打错了靶子。 KDDI对签约数据库做了限流，但入方向的信令源头——那些持续超发请求的VoLTE节点——仍在工作。限流数据库只治了症状：请求进不来，业务也不通，而拥塞压力并未消除。
其三，用户的自救行为在帮倒忙。 手机显示“圈外”，用户的第一反应是开关飞行模式、重启手机。但重启会清空终端里所有协议状态，包括退避定时器——刚被网络劝住的用户，重启后又以满血状态发起全新注册请求。每一次用户自救，都是往拥塞的火上浇一瓢油。 周六上午故障发酵期恰逢用户大规模重启时段，这也是故障迟迟压不下去的重要原因之一。
最终“断开6台节点”之所以有效，恰恰是因为它反其道而行：不是让网络撑住更多请求，而是让一部分终端彻底死心。节点断开后，挂在其上的终端收不到任何载波信号，转入正常的找网流程，重传源头被物理消灭，数据库负荷才得以回落。
这段经历给所有网络设计者的启示非常直接：拥塞控制必须区分“保护自己”和“欺骗终端”——你要么明确拒绝并下发退避，让终端知难而退；要么干脆让终端收不到信号、老老实实进入慢速找网。最糟糕的状态是“半通不通”：请求被默默吞掉，终端以为下一秒就能成功，拼命重试。KDDI为全网同学演示了这种状态的破坏力。
这次事故最让人警醒的地方在于：受影响的不只是39万公里外刷手机的普通人，而是整个日本社会镶嵌在通信网上的那一层“数字皮肤”。 根据KDDI官方列出的企业客户影响清单和 Light Reading 的报道，受波及的基础设施包括：
| 领域 | 受影响系统 | 具体情况 |
|---|---|---|
| 气象 | 气象厅观测数据采集 | 全国1300个观测站中约900个数据中断（Light Reading） |
| 金融 | 银行体系外ATM | 大垣共立银行190台ATM停摆 |
| 物流 | 配送状态更新与司机联络 | 货运追踪与派送调度受阻 |
| 交通 | JR货运列车运行管理 | 货运受到影响 |
| 交通 | 机场无线对讲、公交IC卡 | 机场地勤通信、巴士乘车结算异常 |
| 汽车 | 车联网服务 | 丰田、铃木车载通话功能中断 |
| 公共 | 水表数据采集 | 智能水表抄表中断 |
| 人身安全 | 紧急呼叫 | 北海道两名登山者一度无法通过手机求救（Light Reading） |
| 同业 | 乐天移动 | 租用KDDI的漫游补充受波及 |
其中两条尤其值得展开。一是紧急呼叫。现代VoLTE网络中，紧急呼叫与普通呼叫共用注册与鉴权链条，网络拥塞时IMS紧急呼叫的建立同样受阻。手机“圈外”状态下用户甚至无法手动选择其他运营商网络急救——北海道两名登山者的遭遇，把“通信是生命线”这句话变成了具体的险情。二是2C网络对2B/物联网业务的次生灾害。水表、ATM、物流终端这些物联网设备没有“人工重试”的智慧，网络恢复后它们要靠自己的重连机制爬回来，恢复进度千差万别，KDDI事后给企业客户的影响说明专门列出这些行业，本身就是对“通信即基础设施”的承认。
资本市场也投了票：7月4日（复牌后）KDDI股价早盘一度下挫4%，收盘跌1.7%。当然，和后来的监管动作相比，这算是轻的。
事故的处置链条完整地走了日本电信监管的标准程序，值得国内同行对照参考。
第一步，重大事故认定与报告。 7月2日当天，总务省依《电气通信事业法》第28条认定为重大事故。7月28日，KDDI与冲绳Cellular向总务省正式提交重大事故报告书，说明事故经过、原因与再发防止措施（总务省当日发布新闻稿确认受领）。
第二步，行政指导。 8月3日，总务省向KDDI发出《关于电气通信事故妥善应对的指导》——这是监管层面的正式训诫，要求限期整改并回报。
第三步，第三方检证。 总务省设立“电气通信事故检证会议”，自2022年8月起对事故展开独立验证——运营商自查之外引入第三方视角，避免“自己查自己”的利益冲突。
第四步，整改落实回报。 11月1日，KDDI提交对行政指导的整改报告，内容包括：通信设备维护作业的作业规程与标准修订、拥塞检测机制强化等。
KDDI自身的整改动作则在报告提交前就已铺开，其官方公布的落地时间表如下：
| 问题环节 | 整改措施 | 落地时间 |
|---|---|---|
| 维护作业 | 作业与项目审批流程修订 | 2022-07-14 |
| 维护作业 | 计划作业的项目风险分析机制 | 2022-07-22 |
| 故障扩大 | VoLTE节点拥塞检测精细化工具 | 2022-07-28 |
| 故障扩大 | 拥塞控制设计的复核与检查 | 2022年8月底完成 |
| 故障拖长 | 拥塞场景下的恢复流程修订 | 2022-07-11 |
| 故障拖长 | VoLTE节点拥塞恢复工具开发 | 2022年8月底前 |
| 客户通告 | 信息披露时效与透明度改进 | 7月14日起分步实施 |
第五步，事故返还。 7月29日KDDI公布返还方案，分两层：依契约条款，对连续24小时以上完全无法使用全部服务的271万用户（冲绳7万）返还相当于2天基本费用的金额；另向全部智能手机、功能机及Home plus phone用户（KDDI3589万＋冲绳66万）每户返还未税200日元，9月账单直接抵扣。povo2.0因月租为零，改赠1GB/3日流量包。约合1.2美元的“道歉金”在日本社交媒体上引发不少吐槽，但站在制度角度，明确、自动、无需申请的返还机制值得肯定——用户不需要举证，账单自动减免。
更深远的影响在立法层面。 据日媒报道，这次事故叠加此前docomo、SoftBank的多起故障，直接推动了日本《电气通信事业法》修正案在2024年经国会通过：将NTT docomo、KDDI、SoftBank、乐天等大型运营商指定为监管对象，重大事故强制报告义务升级，瞒报漏报最高可处1亿日元罚则，并自2025年起施行。Light Reading 在2022年报道中引用分析师 Marc Einstein 的预判——"我不会惊讶于看到类似当年银行ATM故障后金融厅式的监管收紧”——两年后应验。
复盘别人的事故，最终要落到自己身上。以18年核心网与运维经验视角，我把这次事故翻译成四条可以拿回自己网络里做的推演。
推演一：你的变更窗口里，谁在盯着“非预期行为”？ KDDI的路由配错发生在凌晨1点半的维护作业中——和全球99%的割接一样。问题是：作业单上有“路由配置变更后需验证哪些信令流”的确认项吗？位置更新成功率、寻呼成功率这些核心KPI，在割接后的前15分钟有人值守吗？多数重大故障的第一现场，都是割接后的“确认空窗期”。建议把“割接后15分钟KPI人工盯守”写进作业规程，并明确“发现劣化立即回退”的授权——回退的决策权必须前移到现场，而不是层层上报。
推演二：你演练过“网络不正常时的网络”吗？ KDDI承认“未充分考虑非标准网络状态下的拥塞控制”。平时压测都是模拟“业务增长”，谁模拟过“信令风暴"？建议定期做信令过载演练：人为制造HSS/HLR高负荷，观察节点的限流行为、终端的退避表现、告警的涌现顺序。3GPP标准允许网络设备有多种过载实现，具体行为以各厂家官方文档为准——但无论实现如何，“故障态下全网信令路径会怎么走”这张图，必须在故障发生前就画出来。
推演三：恢复预案里，有没有“断臂”选项？ KDDI最终靠断开6台VoLTE节点止血。这个动作看似粗暴，实则需要预案支撑：哪些节点可以断、断开影响多少用户、断开后终端行为如何预期、什么条件下断——没有事前设计，故障中没人敢拍这个板。复盘报告里KDDI自己写了“没有针对复杂拥塞状态的恢复程序”。每张核心网的应急预案里，都应该有一页“极端止血手段清单”，并经过管理层事先授权。
推演四：物联网业务和手机用户，是同一条命吗？ 这次ATM、水表、物流、车联网陪葬，暴露的是2B/物联网业务对公网的深度依赖且无差异化保障。短期内未必人人都能上专网切片，但至少可以做到：梳理关键2B业务的承载路径与故障影响面，签订SLA前明确“大面积公网故障不在保障范围”或为其预留备用的通信通道，恢复顺序上明确物联网终端的批量重连控制——否则网络恢复的那一刻，千万台物联网设备同时重连，就是第二场拥塞。
KDDI这次事故没有黑客、没有硬件缺陷、没有天灾，起因只是凌晨维护作业中的一条路由配置——但这恰恰是它最值得写进教材的原因。现代移动网络是一台精密的信令机器，位置更新、鉴权、重传、退避，每一个机制单独看都是保护网络的善政，组合在错误的条件下却会形成自我强化的死亡螺旋。61小时25分钟的计时器告诉所有运营商：故障的规模，从来不取决于第一个错误的尺寸，而取决于你的网络和你的流程，能否在错误发生后的第一个小时里摁住它。
三年过去，日本已经为此改了法律。而在世界的其他角落，类似拓扑、类似流程、类似凌晨割接的作业仍在每晚进行。KDDI交了学费的这道题，值得每一家运营商在自己网上重新做一遍。
本文由「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 等场景全覆盖。