502错误主因是Nginx未正确透传WebSocket升级请求，导致后端未收到Upgrade头而无法响应101；需验证后端直连是否返回101、检查proxy_pass路径拼接是否准确、确认proxy_http_version 1.1及Upgrade/Connection头配置完整。
WebSocket 代理出现 502，不是后端“挂了”就完事——它大概率是 Nginx 根本没把连接当 WebSocket 处理，上游服务压根没收到 Upgrade 请求。所以检查后端状态，不能只看进程在不在，得验证它是否真正收到了、并响应了 WebSocket 握手。
直接测试后端 WebSocket 服务是否可连通
绕过 Nginx，用真实客户端直连后端，确认服务本身能完成握手：
- 用 curl 模拟 Upgrade 请求（注意必须带完整头）：
curl -i -N -H "Connection: Upgrade" -H "Upgrade: websocket" -H "Sec-WebSocket-Version: 13" -H "Sec-WebSocket-Key: $(openssl rand -base64 16)" http://127.0.0.1:8080/ws
若返回 101 Switching Protocols，说明后端监听正常、能响应升级；若返回 400/404/超时，则问题在后端路径、端口或逻辑本身。 - 用浏览器开发者工具的 Console 直连后端地址（如 new WebSocket("ws://127.0.0.1:8080/ws")），观察 Network → WS 标签页是否有连接建立和消息收发。
确认后端监听地址与路径完全匹配
Nginx 的 proxy_pass 路径拼接极易出错，导致后端收不到 /ws 而是 / 或 /ws/：
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
- 查后端实际监听路径：比如 Node.js 的 Express + ws，运行 app.ws('/ws', handler)，那它只认 精确路径 /ws，不接受 /ws/ 或 /api/ws。
- 对照 Nginx 配置：
✅ 正确写法（显式补全路径，不触发重写）：
location /ws { proxy_pass http://backend/ws; }
❌ 危险写法（末尾 / 会删掉 /ws 再拼接，变成 http://backend/）：
location /ws { proxy_pass http://backend/; }
检查后端日志里有没有收到请求
502 出现时，立刻查后端访问日志或应用日志：
- 如果日志里 完全没记录任何 /ws 请求，说明 Nginx 连连接都没发出去——问题在 Nginx 配置未生效、upstream 不可达、或被防火墙拦截。
- 如果日志显示收到了请求但很快断开（如 “connection reset”、“upgrade failed”），说明 Nginx 把 Upgrade 请求当普通 HTTP 处理了，没透传关键头，需检查 proxy_set_header 配置。
验证 Nginx 是否正确透传了 WebSocket 头
这是最常被忽略的一环。打开 Nginx 错误日志（/var/log/nginx/error.log），搜索关键词：
-
upstream prematurely closed connection while reading response header from upstream → 表明后端收到了请求但提前断连，大概率是 Nginx 没设
proxy_http_version 1.1和proxy_set_header Connection "upgrade"。 - client sent invalid request while reading client request line → 常见于路径重写错误或鉴权中间件干扰了 Upgrade 流程。
