Nginx代理WebSocket需精准配置三项协议升级和两项保活控制：proxy_http_version 1.1、proxy_set_header Upgrade $http_upgrade、proxy_set_header Connection "upgrade"；proxy_buffering off、proxy_read_timeout 86400、proxy_send_timeout 86400；且必须置于精确匹配的location块中。
Linux 下用 Nginx 的 location 块代理 WebSocket 长连接，核心不是加一堆参数，而是精准命中三项协议升级动作和两项连接保活控制——缺一不可，且必须写在具体路径的 location 里。
必须配齐的三项协议升级配置
WebSocket 握手依赖 HTTP/1.1 的 Upgrade 机制，Nginx 默认会丢弃关键逐跳头，必须显式透传：
-
强制使用 HTTP/1.1：加上
proxy_http_version 1.1;。HTTP/1.0 不支持协议升级，漏掉这行握手必然失败。 -
透传 Upgrade 头：用
proxy_set_header Upgrade $http_upgrade;。变量$http_upgrade能原样转发客户端带的值（如websocket或h2c），硬写"websocket"会导致非标准客户端握手失败。 -
固定设置 Connection 头：写
proxy_set_header Connection "upgrade";。必须是字符串"upgrade"，不能用$http_connection（它常为keep-alive）或add_header（那是响应头，无效）。
必须启用的两项连接保活控制
默认配置会让连接秒断、消息延迟或粘包，需针对性调整：
-
禁用响应缓冲：加上
proxy_buffering off;。WebSocket 是实时流，开启缓冲会导致帧被暂存、合并甚至延迟，影响协同编辑、实时游戏等场景。 -
延长读写超时：设
proxy_read_timeout 86400;和proxy_send_timeout 86400;（即 24 小时）。默认 60 秒，只要后端空闲超时，Nginx 就静默断开 TCP 连接——前端只看到“突然掉线”。若后端有心跳，至少设为心跳间隔的 3 倍。
路径匹配要精准，别用兜底 location
WebSocket 流量不能混在 location / { } 里，否则易被其他规则干扰或路径截断：
- 用明确前缀匹配，例如
location /ws/ { }或location ~ ^/ws/ { }。^/ws/表示以/ws/开头的完整路径，能匹配/ws/app1、/ws/v2/chat，又避免误伤/websockets/等路径。 -
proxy_pass末尾是否带斜杠决定路径是否剥离。比如proxy_pass http://backend/;会把/ws/chat中的/ws剥离，只传/chat给后端；不带斜杠则全路径透传。 - 可加简单校验增强健壮性：
if ($http_upgrade != "websocket") { return 403; }，拦截非 WebSocket 请求。
HTTPS 场景下额外注意点
走 wss:// 时，Nginx 需终止 SSL 并正确透传协议信息：
-
server块中必须有listen 443 ssl;，并配置正确的ssl_certificate和ssl_certificate_key，证书域名须与请求 Host 匹配。 - 后端仍走
http://（Nginx 解密后明文转发），不要写成https://。 - 补上
proxy_set_header X-Forwarded-Proto $scheme;，方便后端识别 HTTPS 协议，避免生成错误的 http 链接或重定向循环。
