Nginx WebSocket代理稳定性需验证三方面：握手必须返回101状态码及Upgrade/WebSocket响应头；空闲连接需调大proxy_read_timeout等超时参数防静默断连；双向通信要禁用缓冲压缩、开启socket keepalive并测试高并发与断网恢复。
测试 Nginx WebSocket 代理的实时双向通信稳定性，不能只看连接是否“能通”，而要模拟真实业务中长连接、空闲、心跳、突发消息、断网恢复等场景。核心是验证三件事：握手是否稳定成功、连接是否被静默中断、双向帧是否低延迟无丢失。
确认握手阶段是否真正走通
这是所有稳定性的前提。若握手失败，后续全是空谈。
- 打开浏览器开发者工具 → Network 标签页 → 过滤 ws 或 websocket，发起连接后检查该请求的状态码：必须是 101 Switching Protocols，不是 200、502 或 302
- 检查响应头是否包含：
Upgrade: websocket和Connection: upgrade；请求头中必须有Upgrade: websocket和Connection: Upgrade - 用 curl 手动模拟（替换 your-domain 和路径）：
curl -i -H "Connection: upgrade" -H "Upgrade: websocket" -H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" http://your-domain/ws
正常应返回 101 及对应 Sec-WebSocket-Accept 头
验证长连接在空闲时是否被 Nginx 主动断开
这是生产环境掉线最常见原因——Nginx 默认 60 秒 proxy_read_timeout 会杀掉“没动静”的连接。
- 让客户端连接后不发任何消息，仅维持心跳（如每 30 秒 ping 一次），持续观察 5 分钟以上
- 同时 tail -f 查看 Nginx error log：
若出现upstream prematurely closed connection，说明后端未响应或已断；
若出现client timed out或upstream timed out，基本可定位为 proxy_read_timeout / proxy_send_timeout 过小 - 建议将两个超时统一设为 86400（24 小时），并确保后端心跳间隔 ≤ 超时值的一半（例如心跳 30 秒，则超时至少设为 60 秒）
模拟双向数据流与异常扰动
真实场景下，连接不仅要“活着”，还要能扛住消息洪峰、网络抖动和短暂中断。
- 用工具（如 wscat、websocat 或自写脚本）向服务端高频发送消息（如 100 条/秒），同时服务端反向推送，观察是否有丢帧、粘包或延迟突增
- 主动制造网络干扰：在连接建立后，临时禁用客户端网卡 5–10 秒再恢复，看是否自动重连、会话状态是否保持（取决于应用层设计）
- 检查 Nginx 是否意外缓冲或压缩帧：
确认配置中含proxy_buffering off;和gzip off;；
若开启 proxy_cache 或 proxy_buffer_size 过小，可能导致小帧堆积、延迟不可控
检查底层 TCP 层是否配合保活
Nginx 的 HTTP 层超时只是第一道防线，操作系统 TCP Keep-Alive 才是最后兜底。
- 在 Nginx 配置中启用：
proxy_socket_keepalive on; - 搭配内核参数（需 root 权限）：
net.ipv4.tcp_keepalive_time = 300（5 分钟后开始探测）net.ipv4.tcp_keepalive_intvl = 15（每次探测间隔）net.ipv4.tcp_keepalive_probes = 3（失败 3 次则断连） - 该组合可确保即使应用层心跳失败，TCP 层仍能在约 5.5 分钟内发现链路异常并通知上层
