Nginx本身不自动重连，WebSocket闪断后能否恢复取决于其是否透传协议升级头、是否过早关闭空闲连接；关键配置包括proxy_http_version 1.1、proxy_set_header Upgrade $http_upgrade与Connection "upgrade"、proxy_read_timeout等超时设为≥心跳间隔、proxy_buffering off，并通过101状态码及抓包验证透传有效性。
WebSocket 代理在 Nginx 中遭遇网络闪断后能否自动恢复，关键不在于 Nginx 主动“重连”，而在于它是否透传了连接状态、是否干扰了客户端/服务端的原生重连机制。Nginx 本身不维护 WebSocket 连接，只做转发；真正的自动恢复由前后端协作完成。排查重点是：Nginx 是否静默中断了长连接、是否过早关闭空闲连接、是否未正确升级协议，导致重连失败或延迟。
确认 Nginx 正确完成了 WebSocket 协议升级
WebSocket 连接始于 HTTP Upgrade 请求，Nginx 必须透传 Upgrade 和 Connection 头，并设置 proxy_http_version 1.1。缺失任一环节，后端收不到升级请求，会当作普通 HTTP 处理，连接立即断开。
- 检查配置中是否有：
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade"; - 用浏览器开发者工具或 curl 验证响应头是否含
Upgrade: websocket和Connection: upgrade；若返回 200 但无这些头，说明升级失败，问题出在 Nginx 配置或 upstream 拒绝了升级。
检查超时参数是否过短，导致闪断后连接被 Nginx 主动关闭
网络闪断期间，TCP 连接可能暂时卡住（如 SYN 重传、RTO 超时），但未彻底断开。若 Nginx 的超时值设得太小，会在恢复前就 kill 掉连接，使客户端无法复用原 socket，只能走完整重连流程（更慢、更易失败）。
- 必须调整以下三项（单位：秒），且建议设为相同值或相近值：
proxy_read_timeout 60;
proxy_send_timeout 60;
proxy_connect_timeout 10; -
proxy_read_timeout尤其关键：它控制 Nginx 等待后端响应的最大时间，WebSocket 心跳或空闲数据也受此约束。若设为 30 秒，而网络抖动持续 35 秒，Nginx 会先断开，客户端感知为“连接异常”，触发重连——但此时后端其实还活着，造成不必要的重连风暴。
验证客户端与后端的心跳和重连逻辑是否健壮
Nginx 不参与心跳，但会透传 ping/pong 帧（只要不配置 proxy_buffering off 且 buffer 未满）。若客户端发 pong 后迟迟没收到服务端 ping，或重连时反复 400/502，大概率是 Nginx 中间层阻断或上游未响应。
- 在客户端开启日志，记录每次
onclose的event.code和event.reason；1006（abnormal closure）常表示 TCP 层中断，1001（going away）可能源于上游主动断开。 - 用
tcpdump或tshark抓包比对：客户端发 ping → Nginx 转发 → 后端收 ping → 后端回 pong → Nginx 回传 → 客户端收 pong。若中间某环缺失，就能定位是 Nginx 丢帧、上游无响应，还是防火墙拦截。
排除 Nginx 缓冲与代理缓冲区干扰
默认情况下，Nginx 可能缓存 WebSocket 数据帧（尤其小包），导致延迟或粘包，影响心跳及时性。极端情况下，buffer 满后会关闭连接。
- 添加配置禁用代理缓冲：
proxy_buffering off;
proxy_buffer_size 4k;
proxy_buffers 8 4k; - 避免使用
proxy_cache或gzip on（WebSocket 数据一般已压缩，gzip 可能损坏二进制帧）。 - 若用 SSL，确认
ssl_buffer_size 4k（而非默认 16k），减少 TLS 分片延迟。
