概述

你在银行App前刷新十遍，验证码迟迟不来——这条短信在网内到底经历了什么？本文以2024年5月美国AT&T“旧短信迟到八个月”事件为引（据The Verge等媒体当时报道），以一起脱敏后的运营商A2P验证码批量延迟排障实录为主线，按3GPP TS 23.040、TS 23.272、TS 23.540等规范拆解短信在4G/5G网内的完整漂流路径，归纳七类迟到与丢失的高频根因，并给出一套可复用的验证码排障手册。写给每天被“验证码工单”轰炸的核心网与网优工程师。

目录

1. 八个月前的验证码：AT&T的迟到短信
2. 一条验证码的漂流路线：它从来不是直发
3. 七类惯犯：迟到与丢失的根因清单
4. 排障实录：一场验证码延迟的破案过程
5. 5G时代的新变量：SMSF与物联网洪峰
6. 给工程师的十条排障清单

1. 八个月前的验证码：AT&T的迟到短信

2024年5月28日前后，美国运营商AT&T的大量用户遭遇了一场奇特的“时空错乱”：手机接连弹出2023年上半年发出、迟到了八九个月的老短信——旧验证码、旧提醒、旧对话，成批涌入收件箱。据The Verge、CNN等媒体当时汇总报道，受影响的主要是iPhone用户，AT&T承认存在短信延迟送达问题，回应中提及与某个供应商侧系统的处理有关，但完整的公开技术复盘始终没有给出——这起事件至今在业内仍以“据推测”三个字流传（细节未经官方证实）。

AT&T这起事件的传播学意义大于技术学意义，但它戳中了一个工程师都懂的真相：短信是存储转发业务，欠的账迟早要还。短信中心（SMSC）里躺着的不是“已发送”，而是“待发送”。只要队列在，迟到的短信就不会消失，只会挑一个你最尴尬的时刻集中到账——比如八个月后，比如用户正在做二次认证。

而在国内，这类故事有一个更日常的版本：不是迟到八个月，而是迟到四十五分钟——对验证码场景来说，四十五分钟约等于丢失。接下来我们就顺着一条验证码的漂流路线，看看它会在哪些地方搁浅。

2. 一条验证码的漂流路线：它从来不是直发

很多人对短信的想象还停留在“两部手机直连”，而真实链路里，验证码短信（行业称之为A2P短信，Application-to-Person）要跨越两个世界：企业侧的短信世界和运营商侧的信令世界。

先说企业侧。电商平台把验证码通过SMPP协议提交给短信服务商或运营商的行业短信网关（用户侧看到的就是106号段那些通道），网关按签名、模板、频次做一轮合规筛查，再路由到目的号码归属的短信中心。这一段是IT系统，出了问题通常是签名未报备、通道限流、内容触发风控——工程上好查，因为日志都是现成的。

真正难缠的是第二段。按3GPP规范（短信的TPDU层定义在TS 23.040），SMSC要做的不是“发出去”，而是确认对方可收：先通过归属网络查询终端状态，对空闲态终端发起寻呼，终端响应后才下发短消息，成功后凭状态报告（TP-SRR申请时）回执销账。这一段的漂流路线如下：

flowchart TD
    A["企业短信平台"] -->|SMPP提交| B["行业短信网关"]
    B --> C["短信中心SMSC"]
    C --> D["短信防火墙"]
    D --> E["STP按GT路由"]
    E --> F{"终端在哪张网"}
    F -->|5G网络| G["AMF加SMSF下发"]
    F -->|4G网络| H["MME经SGs代收"]
    F -->|IMS注册| I["IP-SM-GW经IMS投递"]
    G --> J["寻呼空闲态终端"]
    H --> J
    I --> J
    J --> K["UE收到短信"]
    K --> L["状态报告回传SMSC"]

三个介入点值得展开：

第一，4G时代的SGs。 LTE建网初期语音走CSFB，短信也借道2G/3G核心网的MSC，由MME通过SGs接口代收代发，架构定义在TS 23.272。这个“借道”设计让4G短信天然多了两跳：MME一跳、MSC一跳，任何一跳的数据不一致，短信就停在半路。

第二，IMS路线。 终端若注册IMS，短信可走IP-SM-GW经IP投递（TS 23.204）。VoLTE用户日常收到的短信，多数走的其实是这条路。它的好处是与语音同管道，代价是链路上又多了注册状态、授权检查两个依赖项。

第三，5G时代的新角色SMSF。 5G把短信从CS域彻底解放出来，架构定义在TS 23.540：SMSF（短消息服务功能）与AMF配合，短消息装在5G NAS消息里直接投递，不再依赖任何电路域设备。这是本文第5节的主角，先按下不表。

再把几个直接影响“迟到还是丢失”的关键参数列出来（以下为标准定义与常见工程口径，标准允许多种实现，具体重发策略以各厂家官方文档与本地数据配置为准）：

顺手澄清一个流传极广的误区：手机设置里的“短信中心号码”只影响主发，不影响接收。你收不到验证码，改那个号码毫无用处——收不到是MT（下行）链路的事，而短信中心号码只管MO（上行）。这条误区每天仍在各大运营商客服热线上重演。

3. 七类惯犯：迟到与丢失的根因清单

把多年工单里反复出现的根因摊开，验证码问题基本逃不出下面七类（按“从全网到单用户”的爆炸半径排序）：

第1类和第6类是真正让人半夜爬起来的。第1类的机制很阴险：首次投递失败后，SMSC按策略重试，重试间隔逐次拉长，一旦某个环节（比如寻呼成功率）劣化几个百分点，积压就开始滚雪球——成功率指标看起来只掉了2%，P95延迟却可能翻五倍，因为排在队尾的短信要等前面所有重试轮次走完。这也是验证码排障的第一课：永远不要用“成功率”评估验证码业务，要看延迟分位数。验证码的有效窗口只有几分钟，成功率99%而P99延迟二十分钟，在用户那里约等于全断。

第6类则几乎每家运营商都交过学费。GT（Global Title）是七号信令世界的门牌号，STP按它转接信令。SMSC扩容、割接、容灾演练都会动GT数据，而GT数据往往是主备STP、省际路由、目标网数据多处存放——任何一处漏刷，那一片目的码号就变成信令黑洞：提交正常、下发无踪、话单无失败记录（因为短信只是安静地留在队列里重试）。AT&T那次“迟到八个月”，工程界普遍怀疑就有队列解锁的成分在——推测归推测，但队列账要认。

4. 排障实录：一场验证码延迟的破案过程

下面是一次笔者亲历复盘的脱敏版本（数字取整、拓扑简化、按工单系统时间记录），一家省级运营商与两家头部银行通道的联合排障，事故形态非常典型。

排障的路径，本质上是一个漏斗——从模糊的用户感知，一层层收窄到具体的数据配置：

flowchart TD
    A["投诉面：哪些号码哪些App"] --> B["话单面：延迟分位数"]
    B --> C["网元面：SMSC队列水位"]
    C --> D["信令面：STP探针抽包"]
    D --> E["数据面：GT路由表核对"]
    E --> F["锁定变更与漏刷点"]
    F --> G["补刷回退并验证"]

这次排障留下三条值得刻在墙上的教训：

第一，变更的时间相关性是最便宜的破案线索。 19:50的演练回退，20:10的投诉高峰，二十分钟的间隔几乎就是“提交通常、投递失败、转存储重试”的第一轮周期。如果当晚有“变更日敏感业务拨测”这道门禁，二十分钟可以压缩到五分钟。可惜工单系统里，变更记录和投诉工单住在两套互不说话的数据库里。

第二，“成功率99.2%”是这起事故最大的烟雾弹。 如果当晚值班工程师只看成功率大屏，这会是一个“查无此故障”的夜晚。事后该省把行业短信监控从成功率口径全面切换到按CP、按通道维度的P95/P99延迟分位数，同类问题的平均定位时长从两小时缩短到十五分钟——这是本次事故唯一值得写进KPI的产出。

第三，投诉面要反着看。 涉及多家CP，说明问题在运营商侧；只涉及一家CP，先查企业侧通道。这个简单的分岔判断能砍掉一半的扯皮时间，而联合排障里最贵的从来不是技术定位，是两拨人在电话里互相证明“我这边没问题”。

5. 5G时代的新变量：SMSF与物联网洪峰

5G对短信的改造是结构性的。按TS 23.540（3GPP官方规范入口），5GS里新增SMSF作为短消息的专职网络功能，与AMF协作完成注册、寻呼与投递，短消息封装在5G NAS消息中传输（NAS层定义见TS 24.501）。对工程师来说，这意味着三件事：

其一，短信彻底“服务化”。 短信链路上的每一跳都是SBI接口，是HTTP/2加TLS。它继承了5GC的灵活，也继承了5GC的全部故障形态：NRF查询失败、服务注册漂移、证书过期、过载拒绝。老短信工程师熟悉的七号信令排障手艺（STP追踪、GT核对）必须向SBI日志与链路追踪迁移，而新一代排障工具链对“状态报告丢失”这类老问题的观测点位还没有完全对齐——过渡期的排障，往往要新旧两套工具并行取证。

其二，物联网短信的洪峰逻辑变了。 抄表、门磁、 Tracker 这类NB-IoT设备平时安静，一旦平台下发批量指令或设备集体重连，短信量会呈脉冲式冲高。老的SMSC容量模型按人话务峰设计，对脉冲型物联流量的弹性不足；而物联终端的处理能力又参差不齐，投递过快反而造成终端侧缓存溢出。多家设备平台的实践是把物联短信与人工验证码分通道、分优先级调度，避免抄表洪峰挤占你登录银行的最后一格带宽。

其三，短信的“最后通道”地位反而更硬了。 在国内语境里，短信是政务、金融、应急通知的兜底通道，实名与监管属性让它不可替代；在海外，A2P短信是运营商为数不量的高毛利增长业务。硬币的另一面是灰路由与防火墙治理：据TransUnion等机构发布的Message Connection Loss系列报告口径（行业媒体广泛转引，建议检索原文核实），全球运营商每年因业务短信未送达、被灰路由截流的损失在百亿美元量级。短信防火墙在过滤灰路由的同时，如何不误杀正常验证码，是每家运营商风控团队永恒的走钢丝——本文第3节的第3类“惯犯”，大半是这个钢丝上掉下来的。

6. 给工程师的十条排障清单

最后把散落在各节的实战经验收拢成清单，建议贴在工位上：

1. 监控口径：验证码类业务看P95/P99延迟分位数，按CP、按通道拆维度；成功率只适合看大盘趋势。
2. 先分岔再动手：多家CP同坏查网内，一家CP独坏查企业侧，五分钟省下两小时扯皮。
3. 话单三对齐：提交时间、首次投递时间、最终投递时间——三者差值就是延迟的结构分解。
4. 状态报告是第一手证据：TP-SRR回执码（失败原因）直接指向是寻呼失败、终端不可达还是被拦截。
5. 变更日加门禁：凡动SMSC、STP、GT数据，变更后自动触发全网段拨测，主备STP数据一致性强制核查。
6. 队列水位要设两级阈值：一级告队列深度，二级告排空速率——积压的斜率比存量更能提前预警。
7. 别只盯着SMSC：防火墙误拦、网关限流、企业侧签名过期，都在同一现象里排队等你误判。
8. 寻呼相关项单列：MT延迟的区域分布图与寻呼KPI热力图叠加，第2类惯犯一秒现形。
9. 5G短信双轨取证：SMSF/AMF侧SBI日志与传统信令探针并行采集，过渡期问题常跨两域。
10. 对用户的账要认：延迟投诉的补偿与公告口径提前备好，AT&T的教训是——欠的短信迟早到账，欠的沟通迟早发酵。

短信这项半个世纪前的技术，至今仍以每天千亿级的量在人类社交与认证体系里漂流。它没有5G的华丽参数，却在每一个验证码背后默默走完寻址、寻呼、投递、回执的完整旅程。看懂这条漂流路线，你才算真正看懂了这张网的毛细血管——毕竟，让用户在三分钟内收到六位数字，就是无数张5G网络每天最重要的一场考试。

参考来源

1. TS 23.040（短信TPDU与端口寻址规范）— 3GPP DynaReport — 短信层三协议、有效期、状态报告与应用端口寻址的权威定义，具体版本可经portal.3gpp.org检索
2. TS 23.272（CSFB架构与SGs接口）— 3GPP DynaReport — 4G时代MME经SGs代收短信的架构依据
3. TS 23.540（5G短信架构与SMSF）— 3GPP DynaReport — 5GS短消息架构、SMSF与NAS承载短信的规范入口
4. The Verge — 2024年5月AT&T旧短信迟到事件的报道入口，按"AT&T delayed text messages 2023"检索原文；官方未公布完整技术根因，文中相关推测均已标注
5. GSMA — A2P短信与短信防火墙相关报告入口，按"SMS firewall"、"A2P SMS"检索；TransUnion《Message Connection Loss》系列数据经行业媒体转引，建议以原文为准

说明：本文排障实录为笔者亲历案例的脱敏复盘（数字取整、拓扑简化）；参数表中的重发策略等属常见工程口径，标准允许多种实现，具体行为以各厂家官方文档为准；未经官方证实的信息已在文中逐一标注。

本文由「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 等场景全覆盖。