结论：自动重连和心跳检测必须客户端、网关层、服务端三方协同，缺一不可；仅靠客户端单方面实现无法解决网关静默断连问题。
直接说结论：自动重连和心跳检测不能只靠客户端单方面实现，网关层必须协同配合；否则客户端再努力，也会被中间设备（如Nginx、云WAF、运营商防火墙）静默断连。
WebSocket 连接在网关层被静默中断的典型表现
客户端 onclose 事件没触发，ws.readyState 仍为 1（OPEN），但后续 send() 报错或无响应；抓包可见 FIN 包从未发出，连接在 TCP 层已失效。这是网关/代理超时切断导致的“假在线”状态，仅靠客户端心跳无法及时感知。
常见诱因包括：
- Nginx 默认
proxy_read_timeout是 60 秒，若服务端 60 秒内未发任何数据，连接会被关闭 - 某些云厂商 LB（如阿里云 SLB）空闲超时设为 30 秒且不可调
- 企业防火墙对长连接有主动探测和强制回收策略
网关配置必须显式支持 WebSocket 升级与超时延长
以 Nginx 为例，以下配置缺一不可，且顺序和值必须精确：
location /ws/ {
proxy_pass http://backend;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade"; // 注意：必须是字面量 "upgrade"，不是 $connection_upgrade
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_read_timeout 300; // 关键！至少设为心跳间隔的 3 倍
proxy_send_timeout 300;
proxy_buffering off;
}
容易踩的坑：
-
proxy_set_header Connection写成$connection_upgrade—— 某些旧版 Nginx 不识别该变量，导致升级失败返回 400 -
proxy_read_timeout小于客户端心跳间隔 —— 网关先断，心跳根本收不到响应 - 漏掉
proxy_buffering off—— 缓冲区可能延迟转发 Pong 帧，导致客户端误判超时
服务端心跳响应必须用标准 Ping/Pong 控制帧
客户端发 Ping（opcode 0x9），服务端必须用原生 Pong（opcode 0xA）响应，不能用普通文本消息（如 "pong"）代替。否则：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 部分 WebSocket 库（如 Netty-WebSocket）会忽略非控制帧的心跳应答
- 中间代理可能丢弃非标准 payload，导致客户端收不到响应
- 违反 RFC 6455，无法通过合规性测试
Node.js（ws 库）示例：
ws.on('ping', (data) => {
// 必须调用 ws.pong()，而非 ws.send('pong')
ws.pong(data);
});
Java（Jetty）示例：
session.getRemote().sendPing(data); // 发送 ping // 收到 ping 后自动回 pong，无需手动 send
客户端心跳 + 网关超时 + 服务端控制帧必须三者对齐
三者时间参数不匹配，是重连风暴和假断连的主因。推荐基准值（可微调）：
- 客户端心跳发送间隔：
25000ms（25 秒） - 网关
proxy_read_timeout：300秒（5 分钟） - 服务端心跳超时判定阈值：
45000ms（45 秒）—— 即连续 2 次未收到 Pong 才触发重连
为什么这样配？因为：
- 25 秒心跳确保在 300 秒网关超时前至少发 12 次，留足容错余量
- 45 秒判定阈值避开单次网络抖动（如 GC 导致服务端延迟响应），又比网关超时早 255 秒，留出重连窗口
- 若把心跳设成 5 秒，服务端压力陡增，且多数网关根本不允许这么高频保活
最易被忽略的一点：网关层没有日志记录 WebSocket 连接关闭原因。线上问题排查时，别只盯着客户端 console 和服务端 error 日志，一定要查网关 access log 中对应连接的最后一条记录 —— 它往往写着 "499 Client Closed Request" 或 "502 Bad Gateway"，这才是真实断连源头。
