HTML5WebSocket频繁断开_HTML5心跳包机制保活连接操作指南【攻略】

websocket 连接为什么总是 onclose？不是网络问题，是服务端没收到心跳

浏览器里 WebSocket 看似连上了，几秒到几十秒后突然触发 onclose，控制台没报错、抓包也看不到 RST，大概率是服务端主动踢掉了“静默连接”。http/1.1 没有长连接保活语义，WebSocket 本身也不强制心跳——不发心跳，就等于断线。

常见错误现象：readyState === 1 后毫无征兆变成 0；服务端日志显示 “connection idle timeout” 或直接 close code 1001；用 wscat 手动连却稳定——说明问题出在前端没按服务端约定发心跳。

• 必须确认服务端要求的心跳格式：是 ping 帧（二进制）、文本 "ping"、还是自定义 jsON 字段（如 {"type":"heartbeat"}）
• 服务端超时阈值通常为 30–60 秒，前端心跳间隔建议设为该值的 2/3（如 40 秒发一次），避免边界抖动
• 不要依赖 ws.send() 成功回调来判断心跳送达——它只表示数据进了浏览器发送队列，不代表抵达服务端

用 setInterval 发心跳？别碰，改用 setTimeout 链式调用

setInterval 在页面失焦、系统休眠或 JS 主线程阻塞时会严重漂移，导致心跳堆积或漏发。更糟的是：如果某次 ws.send() 失败（比如 readyState !== 1），setInterval 仍会继续触发，可能引发未捕获异常或重复重连。

正确做法是用 setTimeout 实现“发完再定下一次”，把心跳逻辑和连接状态绑定：

立即学习“前端免费学习笔记（深入）”；

function startHeartbeat() {   if (ws.readyState !== WebSocket.OPEN) return;      ws.send(json.stringify({ type: "heartbeat" }));      // 下次心跳只在本次成功后启动   heartbeatTimer = setTimeout(startHeartbeat, 40000); }  // 连接打开后立即启动 ws.onopen = () => {   startHeartbeat(); };  // 连接关闭/异常时清除定时器 ws.onclose = ws.onerror = () => {   clearTimeout(heartbeatTimer); };

• 每次发心跳前必须校验 ws.readyState === WebSocket.OPEN，否则 send() 抛错且不触发 onerror
• 不要在 onmessage 里重置心跳计时器——服务端心跳响应是单向通知，不是双向 ACK
• 移动端 webview 中，setTimeout 在后台标签页可能被节流至最低 1s，需配合 document.hidden 暂停心跳

onmessage 收到 "pong" 就算心跳成功？服务端根本没发这个

很多人误以为 WebSocket 协议像 HTTP 一样需要客户端发 ping、服务端回 pong。实际上：标准 WebSocket 的 ping/pong 帧由浏览器底层自动处理，JS 层完全不可见。你看到的 "pong" 文本，几乎全是服务端按业务协议伪造的响应。

这意味着：如果服务端文档写的是 “收到 {"type":"ping"} 后返回 {"type":"pong"}”，那它和协议层的 ping/pong 完全无关，只是个业务约定。

• 不要监听 onmessage 判断心跳是否成功——服务端可能根本不回任何消息，只默默续租连接
• 真正可靠的“心跳存活”信号只有两个：ws.readyState === 1 且最近一次 send() 没抛错
• 若服务端要求回执，应在 onmessage 中解析业务字段（如 data.type === "heartbeat_ack"），而非硬匹配字符串

心跳包内容为空或太小，nginx/ALB 直接吞掉

某些反向代理（尤其是 Nginx 默认配置、AWS ALB 的 WebSocket 模式）会对“空消息”或“极短文本帧”做静默丢弃，认为是探测包或无效流量。结果就是：前端按时发了心跳，服务端收不到，连接被代理层切断。

解决方法很简单：让心跳载荷具备明确业务特征且长度可控。

• 避免发送空字符串 ws.send("") 或单字符 ws.send("1")
• 推荐格式：ws.send(JSON.stringify({ type: "heartbeat", ts: date.now() }))（约 40 字符）
• 如果服务端允许，优先用二进制帧：ws.send(new Uint8Array([0x01])) —— 多数代理对二进制帧更宽容
• 检查 Nginx 配置中是否有 proxy_read_timeout 小于心跳间隔，它会强制关闭空闲连接

心跳机制真正的复杂点不在代码，而在两端对“活跃”的定义是否一致：前端以为发了就算，服务端却要求带时间戳校验、或限定每分钟最多 5 次心跳。不看服务端文档，光调前端定时器，永远在修幻觉。