WebSocket 60秒断开1006错误解决方法

WebSocket连接在浏览器中运行60秒后出现1006错误（连接异常关闭），并非心跳机制失效，而是Node.js `http.Server`默认60秒超时与`ws`库`noServer: true`模式冲突导致TCP连接被静默终止；本文直击问题本质，提供两种可靠解决方案：推荐使用`new WebSocket.Server({ server })`让库自动接管upgrade并禁用超时，或在手动处理upgrade时务必调用`server.setTimeout(0)`彻底关闭HTTP服务器超时机制，同时辅以客户端健壮重连逻辑，从而一劳永逸解决“精准60秒断连”这一高频痛点，实现WebSocket长连接真正稳定可靠。

WebSocket 在浏览器中运行 60 秒后触发 1006 错误（连接异常终止），即使已实现每 5 秒 Ping-Pong 心跳，根本原因在于 Node.js http.Server 默认超时机制与 ws 库 noServer: true 模式不兼容，导致底层 TCP 连接被静默关闭。

WebSocket 在浏览器中运行 60 秒后触发 1006 错误（连接异常终止），即使已实现每 5 秒 Ping-Pong 心跳，根本原因在于 Node.js `http.Server` 默认超时机制与 `ws` 库 `noServer: true` 模式不兼容，导致底层 TCP 连接被静默关闭。

WebSocket 1006 错误是客户端常见的“连接异常关闭”状态码，它不表示协议级错误（如 1002/1003），而是表明 TCP 连接在未正常发送 close frame 的情况下突然中断——典型表现为浏览器控制台仅显示 Closed 1006 :（空 reason），且 onerror 事件完全不触发。在您的代码中，问题根源并非心跳缺失，而是服务端架构设计缺陷：createServer().handleUpgrade(...) 配合 noServer: true 时，Node.js 内置的 http.Server 仍会为每个 upgrade 请求创建一个 socket，但因未被 http 模块“接管”，该 socket 会受默认 server.timeout（60 秒）和 server.headersTimeout（也常为 60 秒）双重约束，最终被内核强制断连。

✅ 正确的服务端初始化方式（推荐两种）

方案一：使用 ws.Server({ server })（最简健壮）

const { createServer } = require('http');
const WebSocket = require('ws');

const server = createServer(); // 创建标准 HTTP 服务器
const wss = new WebSocket.Server({ server }); // 自动绑定 upgrade 事件

wss.on('connection', (ws, req) => {
  console.log('Client connected:', req.socket.remoteAddress);

  ws.on('message', (data) => {
    const message = data.toString();
    if (message === 'Ping') ws.send('Pong');
    console.log('Received:', message);
  });

  ws.on('close', () => console.log('Connection closed'));
  ws.on('error', (err) => console.error('WS error:', err));
});

server.listen(8000, '127.0.0.1', () => {
  console.log('Server running on http://127.0.0.1:8000');
});

✅ 优势：ws 自动处理 upgrade 事件并禁用相关超时；无需手动调用 handleUpgrade；天然支持 HTTPS（只需传入 https.Server）。

方案二：显式监听 upgrade 并手动分发（高阶可控）

const { createServer } = require('http');
const WebSocket = require('ws');

const server = createServer();
const wss = new WebSocket.Server({ noServer: true });

// 关键：禁用 HTTP 超时，避免 socket 被误杀
server.setTimeout(0); // 禁用 socket 超时（单位 ms）
server.keepAliveTimeout = 0; // 禁用 keep-alive 超时（Node.js ≥ 18.0.0）

server.on('upgrade', (req, socket, head) => {
  // 手动验证并升级（可加入鉴权逻辑）
  if (req.headers.upgrade !== 'websocket') {
    socket.destroy();
    return;
  }
  wss.handleUpgrade(req, socket, head, (ws) => {
    wss.emit('connection', ws, req);
  });
});

wss.on('connection', (ws) => {
  // 同上：处理消息、心跳、关闭等
  ws.on('message', (data) => {
    if (data.toString() === 'Ping') ws.send('Pong');
  });
  ws.on('close', () => console.log('Client disconnected'));
});

server.listen(8000, '127.0.0.1');

⚠️ 注意：若选用此方案，必须显式设置 server.setTimeout(0)，否则 60 秒超时无法规避。

? 客户端补充建议（增强健壮性）

虽然服务端修复是关键，但客户端也应完善容错：

let ws;
function connect() {
  ws = new WebSocket('ws://127.0.0.1:8000');

  ws.onopen = () => {
    console.log('Connected');
    sendPing();
  };

  ws.onmessage = (e) => console.log('Received:', e.data);

  ws.onclose = (e) => {
    console.warn(`Disconnected: ${e.code} - ${e.reason || 'No reason'}`);
    if (e.code !== 1000) setTimeout(connect, 1000); // 非正常关闭自动重连
  };

  ws.onerror = (err) => console.error('WebSocket error:', err);

  function sendPing() {
    if (ws.readyState === WebSocket.OPEN) {
      ws.send('Ping');
      setTimeout(sendPing, 5000);
    }
  }
}
connect();

? 总结

• ❌ 错误模式：noServer: true + 手动 handleUpgrade → 触发 HTTP 服务器默认超时 → TCP 强制断连 → 1006
• ✅ 推荐实践：优先使用 new WebSocket.Server({ server })，由库自动管理生命周期
• ⚠️ 若需自定义 upgrade 流程，务必调用 server.setTimeout(0) 并确保 handleUpgrade 调用及时
• ? 1006 不是 WebSocket 协议错误，而是传输层中断，排查方向永远优先服务端网络/超时配置，而非客户端心跳频率

修复后，WebSocket 可稳定运行数小时甚至数天，彻底消除“精准 60 秒崩溃”的诡异现象。

今天关于《WebSocket 60秒断开1006错误解决方法》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！