监控nginx websocket并发数需结合stub_status(用waiting+writing估算)、vts模块(按location精准统计后端active连接)及日志打标(识别真实websocket通信),并依据变化模式判断连接健康状态。

要监控 Nginx 代理的 WebSocket 长连接实时在线并发数,核心是区分“连接是否真实活跃”和“是否属于 WebSocket 流量”,因为 stub_status 和 VTS 模块本身都不直接标记协议类型。Nginx 不会单独统计 “WebSocket 连接数”,它只按 TCP 连接状态(Active/Reading/Writing/Waiting)统一管理——而 WebSocket 连接绝大多数时间处于 Waiting 状态(空闲 keepalive),少数时间在 Reading(接收 Ping 或新帧)或 Writing(推送消息)。
用 stub_status 快速估算 WebSocket 并发基数
这是最轻量、无需重编译的方式,适合快速摸底:
- Active connections 是所有 TCP 连接总数,包含 HTTP 和 WebSocket;只要 WebSocket 客户端保持长连接,就会计入其中
- Waiting 数值通常最高,对 WebSocket 场景而言,它 ≈ 当前空闲但未断开的 WebSocket 连接数(即“在线但没发消息”的用户)
- 若业务中 WebSocket 占比高(如聊天室、行情页),可将 Waiting + Writing 视为近似实时在线并发数(Writing 表示正在推送数据,说明连接活跃)
- 命令示例(每秒刷新 Waiting 值):
while true; do curl -s http://127.0.0.1/nginx_status | tail -1 | awk '{print $4}'; sleep 1; done
用 VTS 模块按 location 精准隔离 WebSocket 连接
stub_status 全局统计,无法区分 HTTP 和 WebSocket;VTS 可通过 location 路径做逻辑隔离:
- 确保 Nginx 已编译并启用
nginx-module-vts(如 vozlt 版本),配置中为 WebSocket 路径单独定义 location:
location /ws/ {<br>
vhost_traffic_status off; # 关闭默认统计(避免混入)<br>
proxy_pass http://ws_backend;<br>
# ……其他 WebSocket 代理配置<br>
}
- 访问
/status(JSON 格式),用 jq 提取该 location 对应的 active 连接数:curl -s http://127.0.0.1/status | jq '.servers[] | select(.server == "your-domain.com") | .upstreams[] | select(.upstream == "ws_backend") | .connections.active' - 该 active 值反映的是后端
ws_backend当前承载的连接数,只要后端服务如实上报(如 Node.js 的 ws 库、Spring Boot 的 WebSocketSession),就等效于真实 WebSocket 并发在线数
结合日志与自定义变量做协议级识别(进阶)
如果需 100% 确保只统计 WebSocket,可在 Nginx 日志中打标,并用日志分析工具聚合:
- 在 WebSocket location 中添加自定义变量:
set $conn_type "websocket";<br> log_format wslog '$remote_addr – $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$conn_type" $request_time';
- 配合 logrotate + Filebeat + Prometheus Pushgateway,或直接用 awk 实时统计当前分钟内含
"websocket"的日志行数,作为活跃连接的间接指标(适用于有心跳 ping 的场景) - 注意:此法统计的是“最近有通信的连接”,非纯空闲连接,更适合判断“真实活跃用户数”而非“总在线数”
告警与趋势判断的关键逻辑
单纯看数字意义有限,重点看变化模式:
- Waiting 持续 > Active × 0.9 且 Writing 长期 ≈ 0 → 多数连接空闲,属健康长连接状态
- Waiting 忽然下降 + Writing 暴涨 → 可能发生批量消息推送(如群发通知),需关注后端写压力
- Active 持续上涨但 handled/accepts 比值下降 → 出现连接堆积或异常未释放,可能后端崩溃或网络中断
- 建议设置阈值告警:比如
Active > 5000 且连续 5 次,再结合后端健康检查结果综合判定











