## 概述 你在银行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承认存在短信延迟送达问题，回应中提及与某个供应商侧系统的处理有关，但完整的公开技术复盘始终没有给出——这起事件至今在业内仍以“据推测”三个字流传（细节未经官方证实）。 | 项目 | 情况（据媒体当时报道） | |---|---| | 时间 | 2024年5月28日前后集中爆发 | | 现象 | 成批收到2023年上半年发出、迟达8-10个月的旧短信 | | 覆盖面 | 以iPhone用户为主，跨多款机型，说明与终端型号无强关联 | | 官方口径 | 承认延迟送达，提及供应商侧因素，未公布完整技术根因 | | 工程界主流推测 | 某个积压已久的重投递队列被变更“解锁”，一次性清库 | AT&T这起事件的传播学意义大于技术学意义，但它戳中了一个工程师都懂的真相：**短信是存储转发业务，欠的账迟早要还**。短信中心（SMSC）里躺着的不是“已发送”，而是“待发送”。只要队列在，迟到的短信就不会消失，只会挑一个你最尴尬的时刻集中到账——比如八个月后，比如用户正在做二次认证。 而在国内，这类故事有一个更日常的版本：不是迟到八个月，而是迟到四十五分钟——对验证码场景来说，四十五分钟约等于丢失。接下来我们就顺着一条验证码的漂流路线，看看它会在哪些地方搁浅。 ## 2. 一条验证码的漂流路线：它从来不是直发 很多人对短信的想象还停留在“两部手机直连”，而真实链路里，验证码短信（行业称之为A2P短信，Application-to-Person）要跨越两个世界：**企业侧的短信世界**和**运营商侧的信令世界**。 先说企业侧。电商平台把验证码通过SMPP协议提交给短信服务商或运营商的行业短信网关（用户侧看到的就是106号段那些通道），网关按签名、模板、频次做一轮合规筛查，再路由到目的号码归属的短信中心。这一段是IT系统，出了问题通常是签名未报备、通道限流、内容触发风控——工程上好查，因为日志都是现成的。 真正难缠的是第二段。按3GPP规范（短信的TPDU层定义在[TS 23.040](https://www.3gpp.org/dynareport/23040.htm)），SMSC要做的不是“发出去”，而是**确认对方可收**：先通过归属网络查询终端状态，对空闲态终端发起寻呼，终端响应后才下发短消息，成功后凭状态报告（TP-SRR申请时）回执销账。这一段的漂流路线如下： ```mermaid 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节的主角，先按下不表。 再把几个直接影响“迟到还是丢失”的关键参数列出来（以下为标准定义与常见工程口径，标准允许多种实现，具体重发策略以各厂家官方文档与本地数据配置为准）： | 参数 | 作用 | 工程意义 | |---|---|---| | TP-VP（有效期） | 短信在SMSC的最长保留时间 | 设太短，用户一开机短信已作废；设太长，积压队列膨胀、迟到短信集中爆发 | | 重投递策略 | 首次寻呼失败后的重试节奏 | 重试间隔级联放大，一条失败的短信可能拖几十分钟才认输 | | 寻呼尝试次数 | 空闲态终端叫不醒时的容忍度 | 次数过少会推高“存储后投递”占比，延迟直接体现在P95/P99上 | | TP-SRR（状态报告申请） | 是否要求回执 | 验证码通道通常强制开启，回执码是排障的第一手证据 | | 应用端口寻址 | 把短信递给手机里哪个App | TS 23.040定义的端口机制，端口冲突时短信“到了手机却没进App” | | SMPP提交速率 | 网关对企业的限流窗口 | 大促、早高峰时限流触发，表现为提交侧排队而非网内丢弃 | 顺手澄清一个流传极广的误区：手机设置里的“短信中心号码”只影响**主发**，不影响接收。你收不到验证码，改那个号码毫无用处——收不到是MT（下行）链路的事，而短信中心号码只管MO（上行）。这条误区每天仍在各大运营商客服热线上重演。 ## 3. 七类惯犯：迟到与丢失的根因清单 把多年工单里反复出现的根因摊开，验证码问题基本逃不出下面七类（按“从全网到单用户”的爆炸半径排序）： | # | 典型现象 | 根因 | 特征 | 定位手段 | |---|---|---|---|---| | 1 | 全网批量延迟，跨App跨通道 | SMSC或网关队列积压、重投递风暴 | 延迟随队列水位同步涨落，话单出现积压峰 | 队列水位监控、话单时延曲线 | | 2 | 单区域延迟集中 | 寻呼失败率高、寻呼信道拥塞 | 投诉集中在空闲态占比高的小区群 | 寻呼KPI、MT投递尝试分析 | | 3 | 个别App验证码收不到 | 反垃圾误拦截、签名或端口策略错配 | 固定签名/固定通道集中失败，同类通道正常 | 防火墙拦截日志比对 | | 4 | 换机换卡后收不到 | USIM短信存满、终端端口冲突 | 该号码所有MT短信均失败或滞留 | 状态报告失败码、终端侧排查 | | 5 | 出访漫游用户收不到 | GT路由错配、国际信令转接异常 | 仅国际漫游号码出现，本地正常 | STP信令追踪、IREG拨测 | | 6 | 变更后突然出现黑洞 | GT路由表主备不一致、数据漏刷 | 严格跟随变更时间窗口，事发即峰值 | 变更工单比对、主备数据核查 | | 7 | 边缘区域偶发丢失 | 弱覆盖下寻呼响应失败 | 农村山区、高楼层乒乓区集中 | MR定位、路测复测 | 第1类和第6类是真正让人半夜爬起来的。第1类的机制很阴险：首次投递失败后，SMSC按策略重试，重试间隔逐次拉长，一旦某个环节（比如寻呼成功率）劣化几个百分点，积压就开始滚雪球——**成功率指标看起来只掉了2%，P95延迟却可能翻五倍**，因为排在队尾的短信要等前面所有重试轮次走完。这也是验证码排障的第一课：永远不要用“成功率”评估验证码业务，要看**延迟分位数**。验证码的有效窗口只有几分钟，成功率99%而P99延迟二十分钟，在用户那里约等于全断。 第6类则几乎每家运营商都交过学费。GT（Global Title）是七号信令世界的门牌号，STP按它转接信令。SMSC扩容、割接、容灾演练都会动GT数据，而GT数据往往是主备STP、省际路由、目标网数据多处存放——任何一处漏刷，那一片目的码号就变成信令黑洞：提交正常、下发无踪、话单无失败记录（因为短信只是安静地留在队列里重试）。AT&T那次“迟到八个月”，工程界普遍怀疑就有队列解锁的成分在——推测归推测，但队列账要认。 ## 4. 排障实录：一场验证码延迟的破案过程 下面是一次笔者亲历复盘的脱敏版本（数字取整、拓扑简化、按工单系统时间记录），一家省级运营商与两家头部银行通道的联合排障，事故形态非常典型。 | 时间 | 事件 | |---|---| | 20:10 | 客服热线告警：某银行验证码延迟30-90分钟，社媒开始出现集中吐槽 | | 20:25 | 比对投诉清单：涉及多家CP、多个签名，排除单一企业侧通道问题 | | 20:40 | 话单对账：提交时间正常，MT下发话单时延P95达47分钟，成功率99.2%——典型的“成功但迟到” | | 21:00 | SMSC队列水位正常，排除全网积压；但MT首次投递失败率从0.8%跳升至4.3% | | 21:20 | STP信令探针抽样：到某目标局向的SCCP寻址出现“改向”——发往新GT的寻址全部超时重试后转存储投递 | | 21:40 | 核对变更记录：当晚19:50另一团队完成SMSC容灾演练后回退，主用STP的GT数据已刷，**备用STP一处目的网数据漏刷** | | 22:10 | 补刷数据，MT首次投递失败率三分钟内回落，队列水位快速排空 | | 次日 | 复盘定级：验证码类业务变更纳入“双STP一致性核查+自动拨测”门禁 | 排障的路径，本质上是一个漏斗——从模糊的用户感知，一层层收窄到具体的数据配置： ```mermaid 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官方规范入口](https://www.3gpp.org/dynareport/23540.htm)），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](https://www.3gpp.org/dynareport/23040.htm) — 短信层三协议、有效期、状态报告与应用端口寻址的权威定义，具体版本可经portal.3gpp.org检索 2. [TS 23.272（CSFB架构与SGs接口）— 3GPP DynaReport](https://www.3gpp.org/dynareport/23272.htm) — 4G时代MME经SGs代收短信的架构依据 3. [TS 23.540（5G短信架构与SMSF）— 3GPP DynaReport](https://www.3gpp.org/dynareport/23540.htm) — 5GS短消息架构、SMSF与NAS承载短信的规范入口 4. [The Verge](https://www.theverge.com) — 2024年5月AT&T旧短信迟到事件的报道入口，按"AT&T delayed text messages 2023"检索原文；官方未公布完整技术根因，文中相关推测均已标注 5. [GSMA](https://www.gsma.com) — 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 等场景全覆盖。