WebSocket握手成功标志是HTTP/1.1 101 Switching Protocols响应，且响应头含Upgrade: websocket和Connection: Upgrade；返回200/400/502说明后端未就绪或路径错误。
确认后端服务已暴露 WebSocket 握手端点
测试前，确保每个后端节点都能独立响应 WebSocket 握手请求（HTTP 101 Switching Protocols）。可直接用 curl 模拟握手：
curl -i -N -H "Connection: Upgrade" -H "Upgrade: websocket" -H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" http://192.168.1.100:8080/ws- 观察响应中是否含
HTTP/1.1 101和Upgrade: websocket；若返回 200/400/502，说明后端未就绪或路径不匹配
用唯一 Sec-WebSocket-Key 验证连接绑定效果
WebSocket 每次新建连接都会生成唯一的 Sec-WebSocket-Key，Nginx 若配置了 hash $http_sec_websocket_key，同一 key 的所有帧必须始终打到同一台后端。测试方法如下：
- 在浏览器控制台或使用
wscat连接一次：wscat -c ws://your-domain.com/ws，记下本次连接的Sec-WebSocket-Key（可在 DevTools → Network → WS → Headers 中查看 Request Headers） - 断开重连（不刷新页面，仅调用
ws.close()后新建new WebSocket(...)），此时 key 会变，可能路由到另一节点——这是正常行为，不表示会话保持失败 - 关键验证：保持连接打开状态（不 close），持续发送多条消息（如 ping、自定义业务帧），通过后端日志或
tcpdump观察这些帧是否全部到达同一台服务器 IP 和端口
结合 sticky cookie 或 ip_hash 实际观测路由一致性
若使用 sticky cookie（如 sticky cookie ws_route expires=1h path=/;）或 ip_hash，需验证客户端是否被稳定绑定：
- 访问
http://your-domain.com/ws建立连接后，在浏览器 Application → Cookies 中检查是否收到ws_route=server-1类似 cookie；重复刷新页面，确认该 cookie 不变且后续连接仍落到同一后端 - 若用
ip_hash，可用不同公网 IP（如手机热点 + 家庭宽带）分别连接，对比后端 access 日志中的$remote_addr和目标 server，验证相同 IP 总是命中同一台 - 禁用浏览器缓存或使用隐身窗口，避免旧 cookie 干扰测试结果
抓包与日志交叉比对连接生命周期
最可靠的验证方式是网络层与应用层日志联动分析：
- 在 Nginx 侧开启详细日志：
log_format ws_log '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$upstream_addr" "$upstream_http_set_cookie";'，并在 location 中启用该格式 - 在每台后端服务开启连接建立/关闭日志，记录 client IP、连接 ID、接收首帧时间、最后活跃时间
- 用
tcpdump -i any port 8080 -w ws-test.pcap抓包，过滤出某客户端 IP 的 TCP 流，确认整个连接周期内所有数据包目的 IP 固定为一台后端，无跳转
