WebSocket连接超时需分层防控：前端用readyState+setTimeout主动监控并清理；服务端配置HandshakeTimeout；代理层调大proxy_read_timeout；降级依据是readyState长期为0、无101响应等信号。
WebSocket 连接超时不是 JS 层能“自动抛出并 catch”的异常，它发生在连接建立阶段（HTTP 升级过程），浏览器不触发 onerror，也不进入 try/catch 流程。处理关键在于主动监控、分层设防、快速干预。
前端：用 readyState + setTimeout 主动判断
浏览器原生 WebSocket 不支持构造时传入超时参数，readyState 可能长期卡在 0（CONNECTING）状态。必须手动加定时器，在约定时间内检查连接是否就绪：
- 实例化后立即启动
setTimeout（建议 5000ms） - 超时回调中检查
ws.readyState !== WebSocket.OPEN - 若仍为
CONNECTING，调用ws.close()并记录日志或触发重连 -
ws.onopen中务必清除定时器，避免误关已建立的连接
服务端：配置握手超时（HandshakeTimeout）
仅前端超时不够——服务端若未设限，TCP 已建连但 HTTP 升级迟迟不完成，前端会一直等待。以 gorilla/websocket 为例：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 使用
Dialer.HandshakeTimeout控制整个握手流程（含 DNS、TCP、HTTP Upgrade） - 公网环境推荐设为
15 * time.Second，内网可缩至5 * time.Second - 避免只设
SetReadDeadline或SetWriteDeadline，它们对握手阶段无效 - 确保服务端
Upgrader和客户端Dialer的超时值一致
代理层：调大 proxy_read_timeout（Nginx/ALB）
很多“60 秒断连”实际是反向代理主动切断，而非代码问题。Nginx 默认 proxy_read_timeout 60s，空闲连接会被静默关闭：
立即学习“Java免费学习笔记（深入）”；
- 必须启用三项关键配置：
proxy_http_version 1.1、proxy_set_header Upgrade $http_upgrade、proxy_set_header Connection "upgrade" -
proxy_read_timeout建议设为3600（1 小时），或至少 ≥ 应用心跳间隔的 2 倍 - AWS ALB/NLB 需同步调整目标组
Idle timeout（最大支持 4000 秒）
识别与降级：别依赖 onerror
onerror 在协议升级失败时经常不触发、延迟触发甚至完全静默，不适合作为主要排查依据：
- 真正有效的信号是：
readyState === 0持续超时、Network 面板无 WS 请求、响应码非101 -
onclose中关注event.code：0（无 reason）大概率是握手失败；1006多为 TCP 层中断（如代理截断） - 发现超时后，应降级提示用户、暂停发送、启动带退避的重连逻辑，而非被动等待
