设备为什么总是离线？一次大规模掉线问题的排查笔记
某个周一凌晨，值班告警群炸了：在线设备数从 5200 掉到 2100，又在半小时内慢慢爬回去。设备没重启、平台没发版，问题出在哪？这是一次完整排查的记录。
第一步：看时间规律
把离线事件按时间轴拉出来，发现掉线集中在 03:00~03:05，且几乎所有掉线设备都在同一批基站覆盖区域。这排除了平台侧问题——如果是 Broker 或后端服务异常，掉线应该与设备地域无关。
第二步：理解 MQTT 长连接的保活机制
MQTT 客户端与 Broker 之间靠 keepAlive 维持长连接：客户端承诺在该间隔内至少发一个包（没有业务消息就发 PINGREQ），Broker 超过 1.5 倍 keepAlive 没收到任何包就判定连接死亡。
但这里有个广为人知的陷阱：运营商 NAT 会话的超时时间往往比 keepAlive 短。4G 网络下 NAT 空闲会话通常 5~15 分钟就被回收。如果 keepAlive 设成 20 分钟，NAT 会话早已断开，设备却浑然不觉，下次发数据时才发现连接已死——表现为「假在线」。
第三步：找到真凶
联系运营商后确认：当晚 03:00 这批基站做了核心网会话批量清理（定期维护操作），所有空闲超过阈值的 NAT 会话被强制回收。keepAlive 设置合理（60 秒）的设备在 90 秒内检测到断连并自动重连；而我们有一批老固件 keepAlive 设成了 600 秒，要等 15 分钟才发现自己「死」了——这就是那 3000 台设备。
修复与预防
- 固件 OTA：老设备 keepAlive 统一降到 60~120 秒；
- 断线重连策略：指数退避 + 随机抖动，避免几千台设备同一秒重连把 Broker 打挂（重连风暴）；
- 遗嘱消息（LWT）：异常掉线时 Broker 代为发布离线状态，平台侧实现秒级离线感知；
- 平台监控：对「单位时间离线设备数」设告警阈值，而不是只看在线总数——这次就是总数变化触发的告警，但定位花了两小时。
小结
长连接问题里，设备、网络、平台三方都「看起来正常」是常态。排查口诀：先按维度聚类（地域/批次/固件版本），再顺着协议状态机找谁在说谎。