WebSocket连接超时必须分层主动控制，因客户端、代理层、服务端、网络设备各有独立超时机制，任一环节遗漏将导致卡死、重连风暴或资源泄漏；前端用setTimeout监控readyState，服务端配HandshakeTimeout，代理层调大proxy_read_timeout，保活需合理设置ping/pong及应用层心跳。
WebSocket 连接超时不能靠“等它自己断”，必须分层主动控制。因为客户端、代理层、服务端、网络设备各自有独立的超时机制，漏掉任一环节都可能造成连接卡死、重连风暴或资源泄漏。
前端连接阶段：用 setTimeout 监控 readyState
浏览器原生 WebSocket 构造函数不支持超时参数，ws.readyState 从 0（CONNECTING） 到 1（OPEN） 的耗时完全不可控，弱网下可能停滞 20–30 秒才触发 onerror 或 onclose。
- 实例化后立即启动定时器，例如 5000ms
- 一旦 ws.readyState === 1，清除定时器
- 超时未就绪，调用 ws.close() 并进入重连流程
- 不能只依赖 onerror——某些网络中断场景下该回调根本不会触发
服务端握手阶段：配 HandshakeTimeout（Go）或等效参数
以 gorilla/websocket 为例，Dialer.HandshakeTimeout 是唯一真正管控 TCP 建立 + HTTP 升级全过程的超时项，优先级高于底层 net.DialTimeout。
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 避免只设 SetReadDeadline / SetWriteDeadline——它们对握手阶段无效
- HandshakeTimeout 设太短（如 1s）易在内网误杀正常连接
- 公网建议 15 * time.Second，K8s Pod 间调用可设为 5 * time.Second
- 服务端 Upgrader 和客户端 Dialer 应保持值一致，防止感知错位
反向代理层：重点调大 proxy_read_timeout（Nginx/ELB）
Nginx 默认 proxy_read_timeout 60s，会在 WebSocket 空闲 60 秒后主动切断连接——这不是代码问题，是代理层截断。
- 必须同时配置三项：proxy_http_version 1.1、proxy_set_header Upgrade $http_upgrade、proxy_set_header Connection "upgrade"
- proxy_read_timeout 推荐设为 3600（1 小时），或根据业务心跳间隔动态设定（需 ≥ 心跳周期）
- ALB/NLB 用户需同步调整目标组的 Idle timeout，最大支持 4000 秒
- proxy_send_timeout 一般无需改动，它影响的是 Nginx 向后端发数据的超时
长连接保活：合理设置 ping/pong 与应用层心跳
WebSocket 协议本身无内置心跳，ping/pong 行为完全由服务端驱动；前端无法通过 ws 对象直接控制 ping 超时。
- 服务端 pingTimeout 应为 pingInterval 的 2–3 倍，例如 25000ms / 45000ms，兼顾灵敏度与容错性
- Python websockets 库要求 ping_timeout < ping_interval，否则报 ValueError
- 在 STOMP 或 ELB 场景下，建议叠加轻量应用层心跳（如每 25 秒 send {type: "keepalive"}）
- 心跳间隔必须严格小于所有中间设备（Nginx、ELB、防火墙）的空闲超时设置
