Nginx代理WebSocket长连接稳定性验证需分层进行：先用curl和抓包确认握手成功（返回101）及帧透传；再校验客户端心跳间隔、后端响应逻辑与proxy_read_timeout是否对齐（建议设为86400）；接着实测空闲2–4小时、弱网抖动及后端故障切换；最后通过增强日志字段精准定位断连根因。
测试 Nginx 代理 WebSocket 长期连接稳定性，重点不是“压并发”，而是验证连接能否在真实空闲、心跳、弱网、重连等场景下持续存活。核心在于分层验证：先通链路，再保心跳，最后模拟异常。
一、基础握手与链路连通性验证
配置生效后，不直接开压测工具，先用最轻量方式确认握手成功：
- 用 curl 模拟客户端发起升级请求，检查是否返回 101 Switching Protocols：
curl -i -N -H "Connection: Upgrade" -H "Upgrade: websocket" -H "Sec-WebSocket-Key: $(openssl rand -base64 16)" http://your-nginx-ip/ws/ - 抓包（Wireshark 或 tcpdump）过滤目标端口，确认 TCP 三次握手完成、无 RST 包、且后续有 WebSocket 帧（如 0x89 PING、0x8A PONG）流动
- 查看后端服务日志，确认收到连接并打印唯一标识（如 X-Backend: node-2），证明 Nginx 分发正确、未轮询漂移
二、心跳周期与超时对齐验证
长期连接稳定性的最大雷区是超时参数错位。需人工或脚本验证三者是否协同：
- 确认客户端心跳间隔（如 30 秒发一次 PING）
- 确认后端服务心跳响应逻辑（收到 PING 后立即回 PONG，并更新 last_active 时间戳）
- 检查 Nginx 的 proxy_read_timeout 是否 ≥ 客户端心跳间隔 × 2（例如心跳 30s，Nginx 至少设为 90s；生产推荐 86400）
- 可临时将 Nginx 超时设为 120s，用浏览器控制台手动发心跳，观察连接在 100s 后是否被断——若断，说明参数未生效或被覆盖
三、长时间空闲 + 弱网扰动实测
模拟真实用户锁屏、切后台、移动网络切换等典型断连场景：
- 建立连接后，停止所有业务消息，仅维持心跳（30s 间隔），持续观察 2–4 小时，记录是否出现 1006 错误
- 用 tc（Linux 流量控制）注入网络抖动：
tc qdisc add dev eth0 root netem delay 300ms 50ms loss 1%
观察连接是否自动恢复，PONG 是否延迟突增（反映 tcp_nodelay 是否生效） - 主动 kill 后端一个实例，看 Nginx 是否将新连接正确路由到存活节点（需配合 ip_hash 或 sticky cookie）
四、Nginx 日志辅助定位断连根因
开启详细日志字段，出问题时不靠猜，直接查：
- 在 log_format 中加入：
$upstream_addr $upstream_response_time $upstream_http_sec_websocket_accept $request_time - 连接断开时，查对应时间点日志：
若 $upstream_addr 为空 → Nginx 未转发成功（可能 upstream 不可用）
若 $upstream_response_time 接近 proxy_read_timeout → 是 Nginx 主动断连
若 $upstream_http_sec_websocket_accept 缺失 → 握手阶段失败（头没透传）
