Nginx 不管理 WebSocket 断线重连状态，仅透传连接与升级请求；需配置 proxy_http_version 1.1、Upgrade/Connection 头透传、关闭缓冲与压缩、延长超时、启用 upstream keepalive，并配合前后端实现上下文恢复。
Nginx 本身不参与 WebSocket 或长连接的“断线重连状态机”逻辑，也不保存客户端上下文（如会话 ID、消息序号、未确认帧等）。它只是透传 TCP 连接和 HTTP 协议升级请求。所谓“保护上下文”，实际是指：让 Nginx 不主动中断连接、不破坏协议语义、不丢弃关键头信息，从而为后端服务维持上下文提供稳定通道。真正管理重连状态、恢复会话、续传数据的是前端 SDK 和后端业务逻辑。
确保 WebSocket 升级完整透传
这是上下文不丢失的前提——如果握手失败，连接根本建立不起来，更谈不上上下文维护：
- 必须启用 HTTP/1.1：
proxy_http_version 1.1; - 必须透传 Upgrade 请求头：
proxy_set_header Upgrade $http_upgrade; - 必须将 Connection 头固定设为 upgrade（不是变量，不是 keep-alive）：
proxy_set_header Connection "upgrade"; - 避免使用
add_header设置 Connection，那是响应头，对握手无效
禁用缓冲与超时干扰
Nginx 默认行为（缓冲、压缩、短超时）会截断流、延迟帧、静默关闭空闲连接，直接导致上下文错乱或心跳失效：
- 关闭响应缓冲：
proxy_buffering off;（防止帧粘包或延迟） - 关闭 gzip 压缩：
gzip off;（WebSocket 帧是二进制流，压缩可能破坏边界） - 大幅延长读写超时：
proxy_read_timeout 86400;、proxy_send_timeout 86400;（匹配后端心跳周期，例如后端每 45 秒发 ping，则 timeout 至少设为 60 秒） - 连接超时保持合理：
proxy_connect_timeout 15;（避免建连阻塞，不影响已建立连接）
维持上游长连接池稳定性
频繁重建 upstream 连接会导致后端无法复用 TLS 会话、触发更多 TIME_WAIT、甚至误判为新会话——间接影响上下文连续性：
- 在
upstream块中启用连接复用：keepalive 32;（按 worker 数与并发估算，例如 4 个 worker、峰值 2000 并发，建议设 120–160） - 配合
location中的proxy_http_version 1.1和proxy_set_header Connection ""（清空客户端传来的 Connection 头，避免透传 close） - 设置
keepalive_requests 10000;（避免单连接因请求数限制被提前关闭） - 确保后端响应包含
Connection: keep-alive（多数现代框架默认支持）
配合后端实现有状态重连
Nginx 不做状态管理，但可通过配置降低后端重建上下文的成本：
- 透传原始 IP 和协议信息：
proxy_set_header X-Real-IP $remote_addr;、proxy_set_header X-Forwarded-Proto $scheme; - 若后端依赖 Cookie 或 Token 恢复会话，确保
proxy_cookie_path或proxy_pass_request_headers on;未被意外关闭 - 启用健康检查与故障转移：
proxy_next_upstream error timeout http_500;+max_fails=2 fail_timeout=30s;，避免单点宕机引发全量重连 - 前端仍需实现指数退避重连、连接 ID 缓存、消息去重等逻辑——Nginx 只负责不让它变得更糟
