nginx代理websocket性能评估需聚焦长连接、高并发、低延迟下的稳定性与吞吐能力，核心是正确配置upgrade透传、选用专用压测工具、分层定位瓶颈，并基于真实业务建模。
要评估 Nginx 代理 WebSocket 流量的调度性能，核心在于验证其在长连接、高并发、低延迟场景下的稳定性与吞吐能力，而非简单复用 HTTP 压测方法。
确认 Nginx 配置是否真正支持 WebSocket 透传
WebSocket 依赖 Upgrade 协议切换，Nginx 默认不自动透传相关头字段。若配置遗漏，连接会在握手阶段失败，导致“Error during WebSocket handshake”等错误，此时压测结果无意义。
必须显式设置以下关键指令：
- proxy_http_version 1.1：启用 HTTP/1.1 才支持 Upgrade 机制
- proxy_set_header Upgrade $http_upgrade：将客户端的 Upgrade 请求头原样转发
- proxy_set_header Connection "upgrade"：覆盖默认的 Connection: close，确保后端识别升级意图
- proxy_read_timeout 86400（或更大）：防止空闲长连接被 Nginx 主动断开
选择适配 WebSocket 特性的压测工具和指标
传统 HTTP 工具（如 ab、wrk）无法维持长连接并模拟真实消息交互，会导致结果严重失真。应使用专为 WebSocket 设计的工具：
- wstest（Autobahn）：支持大规模并发连接 + 消息频率控制，可生成详细延迟分布与连接成功率报告
- artillery（配合 websocket plugin）：支持 YAML 脚本定义连接生命周期、心跳、消息发送节奏
- k6（with k6-websocket）：可编程强，适合模拟不同用户行为路径（如登录→订阅→发消息→断开）
关注的核心指标不是 QPS，而是：稳定连接数上限、99% 消息端到端延迟（含网络+代理+后端）、连接建立成功率、连接意外中断率。
隔离 Nginx 代理层，定位瓶颈所在
WebSocket 性能瓶颈可能出现在 Nginx、内核网络栈、后端服务三者任一环节。需分步排除：
- 绕过 Nginx，直连后端 WebSocket 服务，压测相同连接规模，对比延迟与掉线率——判断后端是否已成瓶颈
- 启用 Nginx stub_status 模块，监控
Active connections和Reading/Writing/Waiting状态分布，确认连接是否积压在 Nginx 层 - 检查系统级参数：
net.core.somaxconn、net.ipv4.ip_local_port_range、fs.file-max及 Nginx worker 进程的 worker_connections 是否足够
真实业务流量建模比峰值数字更重要
单纯追求“10 万并发连接”意义有限。实际中，连接生命周期、消息密度、数据包大小差异极大：
- 聊天类应用：连接长（小时级），消息稀疏（秒级/分钟级），但每条消息小（
- 实时行情推送：连接长，消息密集（毫秒级），单条小但总吞吐高
- 远程控制信令：连接中等（分钟级），消息突发性强，含较大 base64 媒体描述
压测脚本应按真实比例混合建模——例如：70% 长连接保活 + 20% 持续消息流 + 10% 频繁重连，才能反映 Nginx 在真实负载下的调度效率与资源占用趋势。
