Nginx稳定代理WebSocket的核心是确保协议升级链路完整、连接不被中断、后端持续响应：需配置proxy_http_version 1.1，透传Upgrade和Connection头（推荐用map动态设置），设proxy_read_timeout与proxy_send_timeout为长值（如86400），并由Nginx终止TLS后以ws://转发至后端。
要让 Nginx 稳定代理 WebSocket 并保障实时数据传输，核心不是“开启某个开关”，而是确保协议升级链路完整、连接不被意外中断、后端能持续响应。实际运行中，多数掉线或延迟问题都源于几个可配置但常被忽略的细节。
必须透传升级请求头
WebSocket 握手依赖客户端发起 Upgrade: websocket 和 Connection: Upgrade 请求头，而 Nginx 默认不转发这些头，也不识别升级意图。若缺失配置，请求会降级为普通 HTTP，返回 200 而非 101，连接直接失败。
- proxy_http_version 1.1：强制使用 HTTP/1.1（WebSocket 升级的前提）
- proxy_set_header Upgrade $http_upgrade：把客户端原始 Upgrade 值（通常是 websocket）原样传给后端
-
proxy_set_header Connection $connection_upgrade：推荐用
map映射动态设置（避免硬写 "upgrade" 导致非 WebSocket 请求异常），例如：
default upgrade;
'' close;
}
防止长连接被超时断开
WebSocket 是长生命周期连接，Nginx 默认 proxy_read_timeout 为 60 秒，空闲时会主动关闭连接，造成“假断连”。这不是网络问题，而是配置限制。
- proxy_read_timeout 86400：设为 24 小时（或业务最长预期空闲时间），保证服务端不发心跳时也不中断
- proxy_send_timeout 86400：同样设大值，避免服务端响应慢触发断连
- proxy_connect_timeout 30：保持默认或略调高即可，仅影响建连阶段
- 注意：
keepalive_timeout控制的是 Nginx 与客户端之间的 TCP 复用，对 WebSocket 连接本身无影响，无需调整
后端需正确响应 101 协议切换
Nginx 只负责转发和协商，最终是否建立 WebSocket，取决于后端能否识别 Sec-WebSocket-Key 并返回标准 101 响应头（含 Sec-WebSocket-Accept）。主流框架如 Node.js 的 ws、Spring Boot 的 WebSocket 模块默认支持；若为自研服务，需确认：
- 是否解析了
Sec-WebSocket-Key并生成对应Sec-WebSocket-Accept - 响应状态码是否为
101 Switching Protocols（浏览器 Network 面板可见） - 是否在握手后切换为 WebSocket 帧通信，而非继续走 HTTP 流程
WSS 场景下 TLS 终止位置要明确
生产环境普遍用 wss://，但 Nginx 不支持直接 proxy_pass 到 wss:// 后端。常见且推荐的做法是：Nginx 终止 SSL，再以 ws:// 明文转发给后端（后端无需处理证书）。这样既安全又高效。
- server 块需启用
listen 443 ssl，并配置有效证书 - location 中
proxy_pass指向http://backend:port（不是 https 或 wss） - 务必传递
X-Forwarded-Proto $scheme，方便后端识别原始协议为 HTTPS - 若后端坚持用 wss:// 上游，则需改用 stream 模块做 TCP 层透传，无法做 HTTP 层头处理
