核心是通过高频双向心跳维持nat映射：客户端按网络类型设25–45秒心跳间隔（留余量），服务端毫秒级回pong，nginx调大超时并启用keepalive，移动端监听visibilitychange规避后台冻结。
解决 NAT 环境下 WebSocket 心跳中断，核心不是“绕过”NAT，而是让心跳流量持续触发 NAT 映射表刷新——NAT 设备本身不识别 WebSocket 协议，只认 TCP 连接上的数据包流动。只要在它的空闲超时阈值内（通常 30–60 秒）有双向数据交互，映射就不会被清除。
合理设置客户端心跳间隔与超时
NAT 超时不可配置，但可预判。必须让心跳发送频率明显快于最短可能的 NAT 超时：
- 4G/5G 移动网络：设心跳间隔 25–30 秒（运营商 NAT 普遍 30–45 秒），ping_timeout ≤ 10 秒
- 家庭 WiFi：设 45 秒间隔（家用路由器多为 60–120 秒），留出安全余量
- 切勿设成固定 60 秒——刚好卡在多数 NAT 清理临界点，极易批量断连
- 确保 ping_interval > ping_timeout，否则未等响应就判定失败；例如 30s 间隔配 8s 超时，而非 30s 配 30s
服务端必须及时响应并维护活跃状态
仅客户端发 Ping 不够。NAT 映射需双向流量维持，服务端收到后必须立即回 Pong（或业务 Ack），且不能延迟、不能积压：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 禁用“攒几个 Ping 一起回”的逻辑，每个 Ping 必须在毫秒级内触发 Pong 帧
- 服务端为每个连接记录 last_heartbeat_at，用独立定时器检查：若 90 秒未更新，主动 close，避免僵尸连接堆积
- Spring Boot 中建议用 @MessageMapping 处理 JSON 心跳，并同步返回 {"type":"pong"}；原生 Ping/Pong 帧更轻量，但需确认代理是否透传
穿透中间代理（如 Nginx）的必要配置
Nginx 等反向代理常比 NAT 更早掐断连接，必须同步调优：
- proxy_read_timeout 和 proxy_send_timeout 均设为 ≥ 心跳间隔 × 2（如心跳 30s，则设 90–120s）
- 启用 proxy_socket_keepalive on，并配合系统参数：tcp_keepalive_time=300、tcp_keepalive_interval=15
- 强制协议升级头：proxy_set_header Upgrade $http_upgrade; 和 proxy_set_header Connection "upgrade";
- 云厂商 LB（如阿里云 SLB）需单独开启“长连接保持”，默认空闲超时可能仅 30 秒
移动端要规避后台冻结干扰
手机系统会在标签页退至后台后冻结 JS 定时器，导致心跳停摆，NAT 映射自然过期：
- 监听 PageVisibility API：document.addEventListener('visibilitychange', () => { if (document.hidden) pauseHeartbeat(); else resumeHeartbeat(); })
- 后台期间不发心跳，但保留 WebSocket 实例；前台恢复后立刻补发一次 Ping 并重置计时器
- 避免依赖 setInterval 发心跳——它在 Android 低内存或 iOS Safari 后台下基本失效
