websocket错误码1006表示连接异常关闭，即tcp层已断开但未完成标准关闭握手，需结合网络、心跳、代理超时及客户端状态等上下文综合排查。

WebSocket 错误码 1006 表示连接异常关闭（Abnormal Closure），它不是由服务端或客户端主动发送 close 帧触发的，而是底层连接在无明确关闭握手的情况下突然中断。这个错误本身不带额外信息，无法直接定位原因，需结合上下文综合排查。

检查网络与连接生命周期

1006 往往出现在 TCP 层已断开但应用层未收到标准关闭通知时。重点关注：

• 客户端是否在页面卸载、标签页冻结、浏览器休眠前未调用 websocket.close()，导致 socket 被强制释放
• 是否存在 NAT 超时、代理（如 Nginx、CDN）静默断连：例如 Nginx 默认 proxy_read_timeout 为 60 秒，超时后会直接断开 TCP 连接，不发 close 帧
• 移动设备切后台、Wi-Fi 切换蜂窝网络、弱网重连失败等场景下，底层 socket 可能被系统回收

验证服务端实现与心跳机制

服务端未正确处理 PING/PONG 或未及时响应，容易引发被动断连：

• 确认服务端是否启用并正确响应 WebSocket ping 帧（RFC 6455 要求必须回应 pong）
• 检查服务端心跳间隔是否合理（如设为 30 秒），且客户端有对应的心跳保活逻辑
• Node.js 的 ws 库需手动设置 pingInterval 和监听 pong 事件；Java 的 Spring WebSocket 需配置 setHeartbeatValue

审查客户端状态管理与错误处理

前端代码中常见疏漏会掩盖真实问题：

• 未监听 onerror 和 onclose 事件，或仅打印 event.code 而忽略 event.reason（该字段多数情况下为空，但部分浏览器或代理可能填充）
• 重连逻辑未做退避（如立即重试），导致短时间内高频建连被防火墙或服务端限流拦截
• 使用了不兼容的子协议（subprotocol），服务端拒绝升级但未返回明确错误，客户端误判为连接建立成功后迅速断开

抓包与日志辅助定位

当常规代码检查无果时，需借助底层工具确认断开时机和方向：

• 用 Chrome DevTools 的 Network → WS → Frames 查看最后收发帧类型和时间戳，确认是否卡在 ping 后无 pong 回应
• 通过 Wireshark 抓包，过滤 tcp.port == [ws_port]，观察 FIN/RST 包由哪端发出（客户端发 RST 多因 JS 主动 close 异常；服务端发 RST 多为进程崩溃或负载过载）
• 服务端开启 WebSocket 调试日志（如 ws 库的 options.log 或 Tomcat 的 org.apache.catalina.websocket 日志级别设为 FINE）

1006 是个“结果型”错误，本质是连接不可用后的兜底标识。真正的问题通常藏在超时配置、心跳缺失、资源释放不及时或中间件策略中。聚焦连接稳定性设计，比单纯捕获 1006 更有效。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！