解决WebSocket连接1005无状态关闭异常捕获与日志记录方法【方案】-js教程-PHP中文网

1005是协议层“未收到关闭帧”的表现，非传输错误，故浏览器不触发onerror事件；真正可靠的是onclose事件，它必触发且含event.code（1005时reason通常为空），所有状态归因逻辑须基于此。

解决websocket连接1005无状态关闭异常捕获与日志记录方法【方案】

WebSocket 1005 关闭时为什么拿不到 error 事件

因为 1005 是协议层“未收到关闭帧”的表现，不是传输错误，所以浏览器不会触发 onerror。你看到的 socket.onerror 可能根本不会执行，或者只返回空事件对象（{ isTrusted: true }），没有任何可读线索。

真正可靠的是 onclose 事件——它一定会触发，且带 event.code 和 event.reason。但注意：event.code === 1005 时，event.reason 几乎总是空字符串，不能依赖它定位原因。

别在 onerror 里做关键日志或重连判断
所有连接状态归因逻辑必须基于 onclose 的 code
如果 onclose 没触发，说明连接已“静默断开”，大概率是中间代理（如 Nginx、Spring Cloud Gateway）提前终止了 TCP 连接

服务端如何区分 1005 是客户端主动关还是网关截断

关键看服务端是否收到了合规的关闭帧。以 FastAPI 为例，WebSocketDisconnect 异常只在收到关闭帧后抛出；而 1005 对应的场景通常是：连接被强制中断，服务端甚至没机会进入 except 分支。

验证方法：在服务端日志中搜索 WebSocketDisconnect 是否出现。如果完全没记录，但客户端报 1005，基本可判定是反向代理或 TLS 层问题。

Nginx 配置必须包含 proxy_http_version 1.1 和 proxy_set_header Upgrade $http_upgrade
Spring Cloud Gateway 需启用 spring.cloud.gateway.websocket.protected-headers= 并检查 max-frame-payload-length 是否过小
用 tcpdump 或 Wireshark 抓包，确认 FIN 包是否由服务端发出（正常）还是由网关 IP 发出（异常）

前端日志埋点该记录哪些字段才真正有用

只记 event.code 和时间戳远远不够。1005 的本质是“信息缺失”，所以你要补全上下文，让后续排查能交叉验证。

WebSocket 8.18.2

WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。

下载

每次 onclose 触发时，至少同步记录：

performance.now() 时间戳（比 Date.now() 更精确）
socket.url（确认是否走对了 wss/wss 路径）
navigator.onLine 状态（快速识别是否本地断网）
document.visibilityState（页面切后台常导致浏览器冻结 WebSocket）
上一次 onmessage 的时间差（判断是否长时间无心跳）

示例代码片段：

socket.onclose = function(event) {
  console.warn(`WS closed: code=${event.code}, url=${socket.url}`);
  const log = {
    code: event.code,
    url: socket.url,
    online: navigator.onLine,
    visible: document.visibilityState,
    idle_ms: performance.now() - lastMessageTime,
    ts: performance.now()
  };
  // 发送到日志服务（注意避免日志本身触发新 WS 请求）
  sendToLogger(log);
};