Nginx 代理 WebSocket 老断线？多半是这 5 个配置没补齐

很多人第一次用 Nginx 反向代理 WebSocket，表面上配置已经写了 `proxy_pass`，浏览器也能连上，但跑一会儿就断，或者握手直接返回 400。问题通常不在 WebSocket 本身，而在 Nginx 还是按普通 HTTP 请求去转发，没有把升级连接需要的几个细节补齐。

最关键的有 4 个点：一是 `proxy_http_version 1.1`，没有它，升级握手就可能失败；二是补上 `Upgrade` 和 `Connection` 头；三是把 `Host` 和客户端 IP 继续往后传；四是适当拉长 `proxy_read_timeout`，不然长连接容易被代理层当成空闲连接踢掉。

先把最小可用配置跑通

如果只是单个 WebSocket 服务，最稳的起步写法其实不复杂：`location /ws/` 里写 `proxy_pass`，再配 `proxy_http_version 1.1`、`proxy_set_header Upgrade $http_upgrade`、`proxy_set_header Connection "Upgrade"`。这几行不是装饰，是 WebSocket 代理能不能正常工作的底线。

别忽略超时和上游状态

很多“偶发掉线”并不是程序崩了，而是 Nginx 侧超时太短，或者后端本身在重启。生产环境里建议把 `proxy_read_timeout` 适当调大，并结合上游服务日志一起看。要是后端本来就会热更新重启，那还得顺手考虑连接重试，而不是只盯 Nginx 配置。

再往前走一步，如果 WebSocket 后面接了多台服务，就要考虑负载均衡、粘性会话和 HTTPS 下的 `wss://`。但不管架构多复杂，第一步永远是先把升级头、HTTP 版本和超时配置做对，不然排查只会越查越乱。