关键在于精准透传WebSocket升级请求并保持长连接：需配置proxy_http_version 1.1、proxy_set_header Upgrade $http_upgrade、proxy_set_header Connection "upgrade"，并延长proxy_read_timeout、proxy_send_timeout和keepalive_timeout至86400秒，确保location路径精确匹配，HTTPS下WSS自动支持。
要让前端 Web 应用通过 Nginx 与后端 WebSocket 服务（如 Socket.IO、Spring WebSocket、或自研 ws 服务）稳定通信，关键不是“开启 WebSocket”，而是正确透传升级请求、保持长连接、避免超时中断。Nginx 本身不处理 WebSocket 协议，它只负责反向代理和协议透传，因此配置必须精准匹配 WebSocket 的 HTTP 升级机制。
必须设置的三个核心代理头
WebSocket 连接始于一个带 Upgrade: websocket 和 Connection: Upgrade 的 HTTP 请求。Nginx 默认会过滤掉这些头，导致后端收不到升级信号，降级为普通 HTTP 响应。需显式透传：
- proxy_http_version 1.1：启用 HTTP/1.1（WebSocket 升级依赖此版本）
- proxy_set_header Upgrade $http_upgrade：将客户端的 Upgrade 头原样传给后端
- proxy_set_header Connection "upgrade"：固定设为 upgrade（注意加引号，避免被解析为变量）
防止连接被意外关闭
Nginx 默认超时较短（60 秒），而 WebSocket 是长连接，空闲时无数据流，容易被中间设备（如负载均衡器、防火墙）或 Nginx 自身断开。需延长以下超时时间：
- proxy_read_timeout 86400：控制 Nginx 等待后端响应的最大时间（单位秒），建议设为 24 小时或更长
- proxy_send_timeout 86400：控制 Nginx 向后端发送请求后的等待时间
- keepalive_timeout 86400：保持客户端连接的空闲超时（影响 TCP 层复用）
注意：这些值应与后端服务的 ping/pong 心跳间隔协调。例如后端每 30 秒发一次 ping，Nginx 的 proxy_read_timeout 至少设为 45 秒以上。
路径与 location 匹配要精确
WebSocket 路径通常带前缀（如 /ws、/socket.io），location 配置不当会导致升级失败或 404：
- 用
location /ws/ { ... }代理wss://example.com/ws/chat，确保末尾斜杠一致 - Socket.IO 若启用了 path（如
path: '/my-socket'），Nginx location 必须完全匹配该 path - 避免使用
location ~ \.ws$等正则匹配，易遗漏 header 或产生重写干扰
SSL/TLS 下的 WSS 支持无需额外配置
只要 Nginx 已正确配置 HTTPS（证书、listen 443 ssl），并把 wss 请求 proxy_pass 到后端 ws 地址（如 http://backend:8080），整个链路就自动支持 WSS。Nginx 在 TLS 层解密后，以明文 HTTP + Upgrade 方式转发给后端，不涉及 WebSocket 加密逻辑。唯一要求是后端服务监听的是 HTTP（非 HTTPS）WebSocket 端点。
若后端也强制要求 WSS（极少见），则需用 proxy_pass https://backend，并配置 proxy_ssl_* 系列指令验证证书，但通常不必要且增加复杂度。
