在实时应用开发中，WebSocket 连接的稳定性直接影响用户体验。今天我们就来聊聊那个令人头疼的错误码 1006，以及如何系统性地解决它。

为什么1006错误如此特殊？

根据 RFC6455 协议规范，WebSocket 的关闭码分为三类：

• 正常关闭：1000（正常关闭）
• 保留段：1001-2999（协议预留）
• 自定义码：3000-4999（应用自定义）

而 1006 是个异类——它表示连接异常断开，但不属于协议定义的任何标准情况。常见触发场景包括：

1. 网络突然中断（WiFi切换/移动网络抖动）
2. 服务端进程崩溃未发送关闭帧
3. 代理服务器强制断开连接

实战解决方案

一、核心防御策略

1. 自动重连机制 采用指数退避算法避免频繁重试：

class WSReconnect {
  private retries = 0;
  private maxRetries = 5;

  reconnect() {
    if (this.retries >= this.maxRetries) return;

    const delay = Math.min(1000 * 2 ** this.retries, 30000);
    setTimeout(() => {
      this.retries++;
      initWebSocket(); // 重新初始化连接
    }, delay);
  }
}

1. 心跳检测系统 通过定时 ping/pong 检测连接活性：

function setupHeartbeat(ws: WebSocket) {
  const interval = setInterval(() => {
    if (ws.readyState === ws.OPEN) {
      ws.ping();

      // 检测pong响应超时
      setTimeout(() => {
        if (lastPong < Date.now() - 30000) {
          ws.close(1006, 'heartbeat timeout');
        }
      }, 30000);
    }
  }, 25000);

  ws.on('pong', () => lastPong = Date.now());
}

二、生产环境优化

• 性能平衡：心跳间隔建议 25-30 秒，避免过频消耗资源
• 安全防护：采用 JWT 校验 + IP 限流防止重连攻击
• 监控指标：
• 连接成功率 = 成功建立连接次数 / 总尝试次数
• 平均重连延迟 = Σ(重连间隔) / 重连次数

三大避坑指南

1. 永远处理 onclose 事件

   ws.onclose = (event) => {
     if (event.code === 1006) {
       // 触发重连逻辑
     }
   };

2. 重试必须带退避 直接固定间隔重试会导致服务端压力骤增

3. 心跳与业务消息分离 使用独立 WebSocket 通道或消息类型区分

思考进阶

• 网络诊断：连续 3 次重连失败可判定为永久故障
• 微服务管理：通过 API Gateway 统一维护连接池

最后提醒：所有方案都要在测试环境充分验证！希望这些经验能帮你少踩坑。