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 是否量级匹配。