Nginx丢弃Upgrade和Connection头是因为它们是HTTP/1.1逐跳头，默认不转发，且Nginx可能降级为HTTP/1.0转发，导致后端收不到升级意图而返回400。
为什么 Upgrade 和 Connection 头被 Nginx 丢掉了
WebSocket 握手本质是 HTTP/1.1 的 Upgrade 请求，但 Nginx 默认把 Upgrade、Connection 当作“逐跳头”（hop-by-hop），不转发给后端。它还会降级用 HTTP/1.0 转发，导致后端根本收不到升级意图。
现象就是：浏览器发了带 Upgrade: websocket 和 Connection: Upgrade 的请求，后端日志里却只看到普通 GET，没有这两个头——于是返回 400。
-
proxy_http_version 1.1必须显式设置，否则 Nginx 默认用 HTTP/1.0 向上游发请求 -
proxy_set_header Upgrade $http_upgrade中的$http_upgrade是 Nginx 内置变量，只在客户端真带了Upgrade头时才非空；硬写死"websocket"会出错 -
proxy_set_header Connection "upgrade"的值必须是小写"upgrade"，写成"Upgrade"或"connection"都会被后端拒绝
location 块里这三行必须紧挨着 proxy_pass 放
顺序错或位置错，配置就无效。Nginx 不会报错，但这些头不会出现在转发请求里。
常见错误写法：
location / {
proxy_pass http://backend;
# 这里隔了其他 proxy_set_header，上面三行就失效了
proxy_set_header Host $host;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}正确写法（三行紧跟 proxy_pass）：
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
location / {
proxy_pass http://backend;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
}- 如果同时代理 HTTP API 和 WebSocket，建议拆成两个
location，比如location /api/和location /ws/，避免 header 冲突 - 不要在
http或server块顶层写这三行，它们只对当前location生效 - 用
curl -v -H "Upgrade: websocket" -H "Connection: Upgrade" http://your-domain/ws可验证 Nginx 是否透传了头
error_log 级别设太低就看不到握手失败原因
Nginx 默认 error_log 级别是 error 或 warn，而握手细节（如 "client sent invalid upgrade header"）只在 info 或 debug 级别输出。
临时调试时，在 nginx.conf 的 http 或对应 server 块里加：
error_log /var/log/nginx/error.log info;
- 改完记得
nginx -t && nginx -s reload，否则不生效 - PHP-FPM 或 Swoole 如果也参与握手（比如用 PHP 做 handshake 拦截），要同步检查它们各自的
error_log和日志级别 - 如果日志里出现
"upstream sent no valid HTTP/1.0 header"，基本可断定是proxy_http_version 1.1没生效
前端连的是 wss，但 Nginx 没配 SSL 就会静默失败
浏览器强制要求 wss 连接必须走 HTTPS，如果 Nginx 没配证书，或证书链不全，握手请求甚至发不到 location 块——直接卡在 TLS 握手阶段，最终也表现为 400 或连接超时。
验证方法：
- 用
curl -I -k https://your-domain/ws看是否能拿到响应头（忽略证书错误） - 用浏览器访问
https://your-domain，地址栏锁图标是否显示“安全”，点开看证书是否有效 - 如果用了 CDN（如 Cloudflare），确认它没把 WebSocket 流量回源成 HTTP；Cloudflare 免费版默认不支持 WebSocket，需升 Pro 或 Enterprise
真正容易被忽略的点：400 错误本身不区分是协议层失败、TLS 层失败，还是后端逻辑拒绝。得靠 error_log + 抓包 + curl 验证三层交叉比对，才能准确定位到底卡在哪一环。
