WebSocket在ip_hash下握手失败的根本原因是后端配置缺失或不一致，ip_hash仅使问题稳定复现；需验证upstream引用、检查Upgrade头配置、服务状态及SSL/SNI设置，并配置proxy_read_timeout保障长连接。
WebSocket 在 ip_hash 模式下握手失败，本质不是 ip_hash 本身导致的，而是它放大了底层配置缺失或不一致的问题。真正出问题的环节，仍是 WebSocket 握手所需的协议透传、HTTP 版本、连接保活等基础配置。而 ip_hash 只是让问题更“稳定地复现”——比如某客户端固定被分到一个后端节点，而那个节点恰好没配好升级头，或者它的健康检查状态异常，结果所有来自该 IP 的 WebSocket 请求都持续失败。
确认 ip_hash 是否真在生效且影响了 WebSocket 流量
很多情况下，你以为启用了 ip_hash，其实它根本没作用于 WebSocket 路径：
- 检查
upstream块是否真的被 WebSocket 的location引用，而不是写在另一个不相关的 upstream 里 - 确保
proxy_pass指向的是带ip_hash的 upstream 名称，不是直接写死后端地址（如http://127.0.0.1:8080） - 用
curl -v http://your-domain/ws发起一次普通 HTTP 请求（非 WebSocket），看响应头中Set-Cookie或服务端日志是否显示固定落到某台机器——这是验证ip_hash生效的低成本方式
重点排查：ip_hash 不会掩盖但会暴露的三类握手缺陷
ip_hash 本身不修改请求头、不干预协议升级，但它会让以下问题从“偶发”变成“必现”：
-
后端节点配置不一致：集群中部分机器 Nginx 配置未同步，缺少
proxy_set_header Upgrade $http_upgrade等关键行，ip_hash把用户钉死在那台错配的机器上，握手就一直 400 -
后端服务未全量部署或健康异常：某台后端 WebSocket 服务未启动、端口未监听，或健康检查失败但仍被
ip_hash分流过去，Nginx 默认返回 502/503，浏览器看到的就是 handshake failed -
SSL 终止与 SNI 冲突（仅 wss 场景）：若使用
ip_hash+ 多域名共用同一 HTTPS server，且后端需区分域名做路由，但proxy_ssl_name未动态设置为$host，可能导致某台后端因 SNI 不匹配拒绝 TLS 握手，进而无法进入 WebSocket 升级阶段
快速验证：绕过 ip_hash 做最小对比测试
临时注释掉 upstream 中的 ip_hash，改用默认轮询，再发起 WebSocket 连接：
- 如果原来 100% 握手失败 → 现在部分成功、部分失败，说明是后端节点配置或状态不一致
- 如果仍然全部失败，说明问题不在分流逻辑，而是整个 Nginx 层缺少核心 WebSocket 支持配置（如
proxy_http_version 1.1缺失） - 成功后，再逐台检查被
ip_hash固定分流的后端节点的 Nginx 配置、服务状态、端口监听情况
补充提醒：ip_hash 和长连接保活的协同要点
ip_hash 解决的是连接初始分发，但 WebSocket 是长连接，后续帧通信必须避免被中间设备断连：
- 务必在启用
ip_hash的 location 块中，同时配置proxy_read_timeout 3600（或更高），否则默认 60 秒空闲就会断开 TCP 连接，导致前端报onclose code 1006 - 不要依赖
keepalive指令代替proxy_read_timeout——前者控制 Nginx 与后端的连接池复用，后者才真正决定客户端连接能挂多久 - 若后端有自定义心跳机制，建议 Nginx 的
proxy_read_timeout设为略大于后端心跳间隔（例如后端每 45 秒发 ping，则设为 60–90 秒）
