nat网关环境下长连接被强制断开，核心原因是中间设备对空闲连接静默回收，导致应用层“假死”；须同步配置内核tcp keep-alive（tcp_keepalive_time=120、intvl=30、probes=3）、禁用nagle算法，并实现双向应用层心跳（客户端≤25秒发ping、服务端45秒检测+60秒清理），同时优化nat网关snat端口资源与客户端超时重连机制。
NAT网关环境下长连接被强制断开，核心原因是中间设备（如运营商NAT、云厂商NAT网关、企业防火墙）对空闲连接执行静默回收——连接在应用层“看起来还活着”，但底层已被切断，onClose不触发、无错误日志、tcpdump可见包发出去却无回包。这不是代码bug，而是网络基础设施的固有行为。
调整TCP空闲超时参数，匹配NAT设备容忍窗口
Azure NAT网关默认TCP空闲超时为4分钟（240秒），但实际生效受SNAT端口压力影响；多数运营商NAT超时集中在60–180秒。不能依赖系统默认的2小时Keep-Alive探测（太晚），必须主动干预：
- 服务端启用内核级TCP Keep-Alive，并缩短探测周期：
net.ipv4.tcp_keepalive_time = 120（空闲120秒后开始探测）
net.ipv4.tcp_keepalive_intvl = 30（每30秒发一次探测包）
net.ipv4.tcp_keepalive_probes = 3（连续3次无响应即断连） - 客户端同步配置Keep-Alive，避免单向保活失效
- 禁用Nagle算法（TCP_NODELAY=1），防止小包合并导致心跳延迟
实现双向应用层心跳，绕过中间设备静默丢弃
TCP Keep-Alive包可能被部分NAT/防火墙忽略，必须叠加应用层心跳。关键点是双向独立控制，且区分业务数据与心跳：
- 客户端每≤25秒发送
{"type":"ping"}（避开60秒超时临界点） - 服务端收到后仅回复
{"type":"pong"}，不更新最后活跃时间戳 - 只有非心跳消息（如业务指令、状态上报）才更新
$connection->lastMessageTime - 服务端每45秒扫描连接，对
time() - lastMessageTime > 60的连接主动close()
优化NAT网关侧资源配置，缓解端口耗尽与连接堆积
连接频繁断开有时并非心跳问题，而是SNAT端口枯竭或连接数超限（Azure NAT网关单IP支持50,000并发连接）：
- 检查SNAT连接总数和失败连接数指标，若失败数持续上升，优先扩容
- 为NAT网关绑定更多公网IP（最多16个），每个IP提供64,512个SNAT端口
- 将应用分散到多个子网，各配独立NAT网关，避免单点瓶颈
- 适当调低TCP空闲超时（最低支持4分钟），加速端口释放，但需与心跳间隔协同
客户端必须配套超时重连与网络状态感知
服务端清理了连接，客户端若无响应，会陷入假死：
- 客户端发ping后等待pong，超时（建议≤3秒）立即
close()并触发重连 - 监听系统网络变化（WiFi/移动网络切换、DHCP租期到期），网络恢复后主动重建连接
- 重连采用指数退避（如1s→2s→4s→8s），避免雪崩式重连冲击服务端
