curl -i -X POST https://api.example.com/sms/callback -d 'msgid=123&status=DELIVRD' # 期望 200 不要出现 301 或 302
发送记录里 90% 停在 sending 状态，实际用户都收到了。回调地址配的是 http 域名，服务端返回 301 跳到 https，服务商不跟随跳转。这类现象通常不是突然出现的，往前翻半天日志能看到苗头。
追下去是这么回事：回调地址写的是 http 版本，接入层强制跳 https，服务商只发一次请求，不跟 301。回调体没被处理，状态自然不更新。日志里只有一条 301，很容易忽略。
「短信回执未更新」确认了原因之后，改动尽量只碰那一处，顺手改的东西后面最容易出问题。监控和日志的时间要对上，时区不一致会多绕很大一圈。
临时改动用注释写上日期和原因，过两周自己都记不清为什么这么写。
处理上按这个顺序：回调地址直接配 https 避免跳转；回调接口先落库再处理 保证幂等；确认服务商的重试策略和次数；用服务商提供的测试回调打一次 看状态是否流转。
确认没问题再收工，回调后记录状态从 sending 变成 delivered，301 日志消失，历史积压用补推接口刷一遍。