1006是客户端TCP无声断连后自动生成的哑错误，非服务端发送；核心原因是Nginx等代理未正确配置HTTP/1.1、Upgrade头、Connection头及proxy_read_timeout≥心跳×2+缓冲，导致静默RST。
WebSocket代理频繁出现1006异常断连，核心问题不是连接“坏了”，而是某一层（通常是Nginx、ALB或防火墙）在没打招呼的情况下直接掐断了TCP连接。它不发close帧，客户端只能报出1006这个“哑错误”。解决的关键是让代理真正理解并尊重WebSocket的长连接特性。
检查Nginx代理配置是否完整透传
Nginx默认把WebSocket当普通HTTP处理，漏掉任意一项配置都会导致60秒后静默RST。必须同时满足以下四点：
-
启用HTTP/1.1协议：
proxy_http_version 1.1;（HTTP/1.0不支持长连接） -
透传Upgrade头：
proxy_set_header Upgrade $http_upgrade;（注意是$http_upgrade，不是$upgrade） -
透传Connection头：
proxy_set_header Connection "upgrade";（引号不能少，值必须是upgrade小写） -
延长读超时时间：
proxy_read_timeout 300;（建议≥心跳间隔×2+缓冲，例如心跳30秒，这里至少设90，生产环境推荐300）
确认心跳机制与代理超时是否匹配
心跳不是“有就行”，而是要和代理的耐性对上节奏。如果心跳每30秒发一次，但proxy_read_timeout只设了60秒，那第二次ping还没等到pong，Nginx就已经断连了。
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 客户端心跳间隔建议设为≤ 45秒，给网络抖动留出余量
- 服务端必须正确响应PING帧（RFC 6455强制要求），不能忽略或延迟过久
- 避免只在客户端发心跳——服务端也要主动PING，双向保活更可靠
排查其他常见代理层干扰
除了Nginx，很多云服务和网关也有自己的超时逻辑，它们不会告诉你，但会悄悄断连：
- AWS ALB：空闲超时固定60秒且不可调，必须换用NLB，或把心跳缩短至≤25秒
- CDN或边缘网关：检查是否开启“WebSocket支持”开关，部分CDN需单独付费开通
- 公司内部防火墙/NAT设备：可能设置3–5分钟无数据即回收连接，需联系运维调整策略
验证代理是否真正在“转发”而非“拦截”
最直接的办法是绕过代理直连后端服务：
- 浏览器访问
http://服务器IP:端口（跳过域名和HTTPS） - 如果直连稳定、代理访问必现1006，问题100%出在代理配置或链路中
- 用Chrome DevTools → Network → WS → Frames查看最后帧：若卡在Ping无Pong，说明代理或服务端未透传/未响应
