WebSocket协议升级失败无法被JS捕获，因发生在HTTP到WS切换阶段，浏览器静默失败；应通过readyState状态、Network面板、响应码等主动识别，并设置超时、校验URL和协议匹配来兜底。
WebSocket 协议升级失败不是 JavaScript 层能“捕获并处理”的异常，而是连接根本没建立成功——它发生在 HTTP 到 WebSocket 的切换阶段，浏览器静默失败，不触发 onerror，也不抛出可 try-catch 的 JS 错误。所以处理重点不是“捕获异常”，而是提前识别、快速定位、主动干预。
一、怎么知道协议升级失败了
-
WebSocket.readyState长期卡在0（CONNECTING），或瞬间跳到3（CLOSED） - DevTools → Network → 切到 WS 标签页，里面空空如也（说明握手请求压根没发出去）
- Console 出现
Mixed Content、Blocked loading mixed active content或wss://xxx failed: Error in connection establishment - Network → XHR/Doc 标签下能看到对
/ws的请求，但响应是400/403/502，没有101 Switching Protocols
这些信号比任何 JS 异常都更真实。
二、前端能做的主动检查和兜底
- 检查协议是否匹配：HTTPS 页面必须用
wss://，HTTP 页面只能用ws:// - 校验 URL 拼写：路径末尾多一个
/（如wss://api.com/ws/vswss://api.com/ws）可能被后端路由拒绝 - 加连接超时保护（防无限等待）：
const ws = new WebSocket(url);
const timeout = setTimeout(() => {
if (ws.readyState === WebSocket.CONNECTING) {
ws.close();
console.error('WebSocket 协议升级超时，可能被拦截');
// 触发降级提示或重试逻辑
}
}, 5000);
ws.onopen = () => clearTimeout(timeout);- 监听
onclose并结合event.code判断：-
code === 1006：TCP 层断开（升级成功但后续断连，和升级失败无关） -
code === 0且无event.reason：典型握手失败表现（浏览器未收到 101） -
code >= 4000：自定义关闭码，服务端主动拒绝（如 Origin 不合法）
-
三、别指望 onerror 能告诉你原因
onerror 在协议升级失败时经常不触发，或延迟触发、甚至完全静默。它更适合捕获已建立连接后的发送/接收错误（比如 send() 时连接已关）。把故障排查依赖 onerror 是常见误区。
四、真正有效的“处理”其实是协同排查
JavaScript 本身无法修复协议升级失败。你写的代码再健壮，也改变不了：
立即学习“Java免费学习笔记（深入）”；
- Nginx 没透传
Upgrade和Connection头 - WAF 把
Upgrade: websocket当攻击拦截 - 后端 PHP-FPM 模式下直接忽略 upgrade 请求
- TLS 证书不被信任导致 wss 握手终止
所以最务实的做法是：
- 前端加日志和超时，明确提示“连接未升级，请检查网络配置”
- 控制台输出建议检查项：
请打开 Network → WS 标签页，确认是否看到 101 响应 - 提供一键复制的 curl 命令，方便后端或运维验证握手是否可达：
curl -i -N -H "Connection: upgrade" -H "Upgrade: websocket" -H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" https://yourdomain.com/ws
不复杂但容易忽略。
