短信发送失败排查指南：从‘发送中’到‘发送失败’，你的短信卡在了哪一步？-洪萨配资

短信发送失败排查指南：从‘发送中’到‘发送失败’，你的短信卡在了哪一步？

短信作为基础通信服务，其稳定性直接影响用户体验。当一条短信从"发送中"变为"发送失败"时，背后可能涉及无线信号、核心网元、短信中心（SMSC）等多个环节的异常。本文将系统梳理短信传输全链路中的关键检查点，帮助技术人员快速定位问题根源。

1. 短信传输全链路解析

短信业务采用存储转发机制，主要涉及三个核心环节：

MO（Mobile Originated）流程：主叫用户发送短信至短信中心
路由查询流程：短信中心通过HLR查询被叫用户路由信息
MT（Mobile Terminated）流程：短信中心向被叫用户投递短信

典型失败场景分布比例如下（基于运营商统计数据）：

失败环节	占比	常见原因
无线接入层	38%	信号弱、信道拥塞、终端异常
核心网传输层	25%	信令超时、网元拥塞
SMSC处理层	22%	中心过载、参数配置错误
HLR/VLR查询层	15%	用户状态异常、路由信息不一致

2. 分阶段故障排查手册

2.1 发送端（MO阶段）问题排查

当用户点击发送后出现即时失败提示，通常问题出在MO阶段。建议按以下顺序检查：

终端侧验证：
- 检查手机信号强度（RSRP应＞-110dBm）
- 验证短信中心号码设置（通过*#*#4636#*#*查看）
- 尝试发送测试短信到其他号码

无线网络检查：

# 通过基站日志检查无线连接状态 grep "SMS Submission" /var/log/bsc.log | grep [用户IMSI]

关注RACH接入成功率
检查SDCCH信道占用率（正常＜70%）

核心网信令跟踪：
提示：在MSC上捕获MAP信令，重点关注SRI-SM和ForwardSM消息

2.2 短信中心（SMSC）处理排查

短信到达SMSC后可能因以下原因滞留：

容量问题：

-- 检查SMSC队列深度 SELECT queue_name, current_size, max_size FROM smsc_queues WHERE queue_type = 'INBOUND';

当current_size接近max_size时需扩容

HLR查询异常：
- 对比HLR返回的错误码：
  - ABSENT_SUBSCRIBER：用户关机
  - MEMORY_CAPACITY_EXCEEDED：存储满
  - UNKNOWN_SUBSCRIBER：号码不存在

重发策略配置：

<!-- 典型重发配置示例 --> <retry_policy> <initial_interval>5m</initial_interval> <max_attempts>6</max_attempts> <expiry_time>72h</expiry_time> </retry_policy>

2.3 接收端（MT阶段）问题定位

当短信显示"已发送"但接收方未收到时，需检查MT阶段：

被叫状态检查：
- 通过HLR查询用户最新状态：
```
hlr_query -m [被叫MSISDN] -c GET_SUBSCRIBER_STATUS
```
- 常见返回状态码：
  - 0x01：正常待机
  - 0x02：关机
  - 0x04：漫游限制
VLR投递验证：
- 检查MSC-VLR接口信令：
```
tshark -i eth0 -Y "gsm_map.opcode == 0x2b && gsm_map.imsi == [被叫IMSI]"
```
- 关注AlertSC和ReadyForSM消息
终端接收能力：
- 检查被叫终端：
  - 存储空间剩余（至少需10KB）
  - 短信过滤设置
  - 是否启用飞行模式

3. 典型故障场景处置方案

3.1 区域集中性故障

特征：同一基站下多个用户发送失败

处置步骤：

检查BSC-MSC间七号链路状态
验证SCCP子系统状态：
```
ss7stat -s SCCP -a
```
采集无线侧KPI：
- SDCCH掉话率
- 立即指配成功率
- Paging响应率

3.2 特定用户持续性失败

排查流程：

提取用户信令跟踪：

cd /opt/traces && zgrep [用户IMSI] *.pcap.gz

检查HLR用户数据一致性：

SELECT * FROM subscriber_data WHERE imsi = '[用户IMSI]' AND hlr_node = 'PRIMARY';

验证VLR中用户状态：

vlr_tool --query --imsi [用户IMSI] --field AttachStatus

3.3 跨运营商短信异常

特殊检查项：

互联关口局（GMSC）路由表：
```
gsm_map_route -d [对方运营商PLMN]
```
号码携带数据查询：
```
npdb_query -n [被叫号码] -t MNP
```

信令编解码验证：

wireshark -r trace.pcap -Y "gsm_sms.tp_pid == 0x00"

4. 高级诊断工具与技巧

4.1 信令跟踪组合分析

推荐使用三层关联分析：

无线层：通过XCAP协议捕获空口信令
核心网层：在MSC采集MAP信令
业务层：SMSC交易日志分析

典型关联命令：

# 时间戳对齐分析 paste -d '|' wireless.log core_network.log smsc.log | sort -t '|' -k3

4.2 性能基线对比法

建立正常情况下的时延基线：

流程段	标准时延	告警阈值
MO提交	1.2s	>3s
HLR查询	0.8s	>2s
MT投递	1.5s	>4s
端到端	3.5s	>8s

4.3 智能日志分析脚本

# 失败模式识别脚本示例 import re from collections import Counter def analyze_sms_failures(log_file): error_patterns = { 'HLR_TIMEOUT': r'HLR response timeout', 'VLR_REJECT': r'VLR returned error code (\d+)', 'SMS_CENTER_QUEUE_FULL': r'queue capacity exceeded' } results = Counter() with open(log_file) as f: for line in f: for err_type, pattern in error_patterns.items(): if re.search(pattern, line): results[err_type] += 1 return results.most_common(3)

在实际运维中，我们发现最耗时的往往不是技术排查，而是确定问题边界。曾经处理过一个案例：某省用户投诉短信延迟，最终发现是相邻省份HLR数据同步异常导致的跨省路由错误。这提醒我们，当常规排查无果时，需要扩大检查范围到关联系统。