stub_status可直接监控WebSocket活跃连接数，因其统计所有HTTP连接（含Upgrade后的长连接），其中Waiting值长期占Active的90%以上时可近似为WebSocket连接数，需高频采集+时序分析并结合日志与系统连接数交叉验证。
stub_status 本身不区分协议类型，它统计的是 Nginx 工作进程当前持有的所有 HTTP 连接（含 WebSocket 升级后的长连接），因此可直接用于监控 WebSocket 活跃连接数的实时波动趋势，但需注意其统计边界和解读逻辑。
确认 stub_status 模块已启用并正确暴露
WebSocket 连接在 Nginx 中完成 Upgrade 后，仍维持为一个 TCP 连接，并计入 stub_status 的 Active connections 总数。前提是：
- 执行
nginx -V 2>&1 | grep -o with-http_stub_status_module，确保输出存在； - 在 server 块中配置独立 location（如
/ws-status），启用stub_status on； - 必须限制访问（如
allow 127.0.0.1; deny all;），避免敏感连接信息泄露； - 关闭日志：
access_log off;，防止高频采集刷爆磁盘。
识别 WebSocket 连接在 stub_status 中的体现方式
访问 http://127.0.0.1/ws-status 返回类似内容：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
Active connections: 86 server accepts handled requests 12450 12450 38921 Reading: 0 Writing: 2 Waiting: 84
其中关键点：
- Active connections: 86 是当前所有活跃连接总数，包括普通 HTTP、keep-alive 空闲连接，以及已完成 WebSocket Upgrade 的长连接；
- WebSocket 连接几乎不会处于 Reading 或 Writing 状态（除非正在收发帧），绝大多数时间落在 Waiting —— 即空闲 keep-alive 连接；
- 若业务中 WebSocket 是主要流量，且 Waiting 值长期占 Active 的 90% 以上，基本可认为该数值近似 WebSocket 活跃连接数。
构建波动趋势监控的关键操作
单次查看无意义，需高频采集+时间序列分析：
- 用脚本每 5–10 秒执行一次：
curl -s http://127.0.0.1/ws-status | grep "Active connections:" | awk '{print $3}'； - 将结果打上时间戳写入时序数据库（如 Prometheus + node_exporter textfile collector）；
- 在 Grafana 中绘制折线图，观察突增（如秒级上涨数百）、缓降（客户端批量断连）、周期性波动（心跳间隔导致）等模式；
- 设置告警：例如 1 分钟内 Active connections 上涨超 300%，或 Waiting 值持续低于 Active 的 70%（可能说明连接未正常进入 idle 状态，存在异常释放或协议未走完）。
辅助验证与排除干扰
为确认波动确实来自 WebSocket 而非其他 HTTP 流量，建议结合以下手段交叉判断：
- 检查 Nginx access log 中
Upgrade: websocket和Connection: upgrade请求的数量趋势； - 使用
ss -tnp | grep :<your_ws_port> | wc -l</your_ws_port>对比系统级连接数，验证 stub_status 统计是否合理； - 若使用 Nchan 等 WebSocket 扩展模块，可同时采集其
/nchan_stub_status数据，对比通道订阅数与 Active connections 是否量级匹配。
