Nginx无法捕获WebSocket异常关闭，仅能透传连接；真正捕获需依赖客户端onclose事件（如code 1006）和服务端close/error事件；关键在于Nginx正确配置以避免干扰：配齐upgrade头、调大超时、关闭缓冲、启用keepalive，并通过日志与透传头辅助定位断连责任方。
Nginx 本身不提供 WebSocket 连接异常关闭的事件监听机制，它不是 WebSocket 服务端，也不维护连接状态；它只是在 HTTP 升级阶段完成协议透传与隧道建立后，将 TCP 流透明转发。因此，“捕获异常关闭”这件事不能在 Nginx 层实现——它既不会触发 onclose，也无法记录“谁断的、为何断的”。
真正能捕获异常关闭的，只有两端：
-
客户端（浏览器/APP）：通过
socket.onclose+event.code（尤其是1006）识别静默中断； -
服务端（如 Node.js ws、Spring Boot、Netty）：通过
close、error、disconnect等事件感知连接终结。
但 Nginx 的配置直接影响能否让这些事件被正确触发。所以所谓“在 Nginx 中捕获”，实质是：确保 Nginx 不干扰、不截断、不静默杀死连接，从而让真实关闭原因能准确暴露给上下层。
以下是关键落点：
确保 WebSocket 握手成功，避免“假失败”
如果握手阶段就出错（如返回 200/400），客户端根本不会进入 OPEN 状态，自然没有 onclose 可监听。
必须配齐三项基础指令：
proxy_http_version 1.1;proxy_set_header Upgrade $http_upgrade;proxy_set_header Connection "upgrade";
缺一即导致后端收不到升级请求，返回普通 HTTP 响应 → 客户端报错但无 onclose 事件。
让真实断连原因浮出水面
Nginx 若提前 RST 断连（如 proxy_read_timeout 超时），客户端收到的是 TCP 层 abrupt close，只能填 1006。这不是“捕获”，而是“放行真实错误”。
要减少误判，需：
- 将
proxy_read_timeout和proxy_send_timeout设为 ≥ 心跳间隔 × 3（例如心跳 30s，设为90或300） - 关闭缓冲：
proxy_buffering off;（避免帧积压掩盖断连时机） - 启用 socket keepalive：
proxy_socket_keepalive on;（辅助探测链路存活）
通过日志定位中断责任方
Nginx 错误日志（error_log）和访问日志（配合 $status、$upstream_status）可辅助判断：
- 若出现
"upstream prematurely closed connection"→ 后端主动断开（查服务端日志） - 若
upstream_status为空或502/504→ 后端未响应或超时 - 若访问日志中 WebSocket 请求状态码是
200或400→ 握手失败，检查头透传 - 若无相关日志，但客户端频繁
1006→ 大概率是 Nginx 或中间设备（防火墙/NAT）静默断连
配合服务端做闭环诊断
Nginx 不捕获，但可帮服务端“留痕”：
- 透传真实 IP：
proxy_set_header X-Real-IP $remote_addr; - 标记代理协议：
proxy_set_header X-Forwarded-Proto $scheme; - 传递 Origin（跨域必需）：
proxy_set_header Origin $http_origin;或$scheme://$host:$server_port;
这样服务端在 @OnClose 或 connection.close 回调中，就能结合 IP、时间、请求头还原上下文，区分是客户端掉线、Nginx 断连，还是自身异常。
不复杂但容易忽略。
