waiting 数即为 websocket 活跃连接数：通过 stub_status 获取 waiting 值（如 waiting: 41），该值代表空闲但存活的长连接，结合 netstat -antp | grep 'nginx: worker' | grep established | wc -l 验证，二者应高度接近。
要查看 Nginx 作为 WebSocket 代理时的当前活跃连接数，核心是区分“TCP 连接总数”和“真正用于 WebSocket 的长连接”。Nginx 本身不区分协议类型统计连接，但 WebSocket 连接在建立后会长期处于 Waiting 状态（即 keep-alive 空闲态），因此需结合 stub_status 和系统连接状态交叉判断。
用 stub_status 查看 Waiting 连接数（最直接反映 WebSocket 活跃连接）
Waiting 是关键指标：它代表已处理完请求、TCP 连接仍保持打开、正等待下一次数据帧（如 WebSocket ping/pong 或业务消息）的空闲连接。WebSocket 握手成功后，绝大多数时间就落在这个状态。
- 确保已启用
http_stub_status_module（运行nginx -V 2>&1 | grep -o with-http_stub_status_module验证） - 在 server 块中配置：
location /nginx-status {
stub_status on;
allow 127.0.0.1;
deny all;
} - 重载配置：
nginx -s reload - 访问
curl -s http://127.0.0.1/nginx-status，输出类似：Active connections: 42<br>server accepts handled requests<br>12345 12345 67890<br>Reading: 0 Writing: 1 Waiting: 41
其中 Waiting: 41 就是当前空闲但存活的长连接数，对 WebSocket 场景而言，基本等同于活跃连接数
用 netstat 精确过滤 WebSocket 相关 worker 连接
因为 WebSocket 连接是长生命周期 TCP 连接，且通常由 worker 进程维持，可用 netstat 统计 ESTABLISHED 状态中归属 nginx worker 的连接：
- 只统计 worker 进程持有的活跃 TCP 连接：
netstat -antp | grep 'nginx: worker' | grep ESTABLISHED | wc -l - 若需排除短连接干扰（比如健康检查或普通 HTTP 请求），可进一步限定端口或目标 IP（如反向代理到后端 WebSocket 服务的连接）
- 注意：该数值包含所有 ESTABLISHED 连接，不严格等于 WebSocket 数，但生产环境若 WebSocket 是主要长连接类型，该值与
Waiting应高度接近
配合日志与 upstream keepalive 验证连接复用情况
WebSocket 代理常搭配 upstream keepalive 使用，避免频繁建连。可通过以下方式辅助确认连接是否真正复用：
- 检查 upstream 配置中是否启用
keepalive N（如keepalive 32），并确认后端服务支持连接复用 - 开启 Nginx error_log 的 debug 级别（临时），搜索
upstream connection关键字，观察连接复用日志（如using keepalive connection） - 对比
stub_status中accepts与handled差值：若长期相等，说明无连接被丢弃；若requests远大于handled，说明大量请求复用同一连接——这是 WebSocket 的典型特征
补充：Prometheus 监控更适配长期观测
若需持续追踪 WebSocket 连接趋势（如突增、泄漏），建议接入 Prometheus：
- 使用
nginx-lua-prometheus（推荐）或nginx-prometheus-exporter抓取stub_status - 重点关注指标：
nginx_connections_waiting（对应 Waiting）、nginx_connections_active、以及自定义的 upstream 连接池指标（如nginx_upstream_keepalive） - 设置告警：Waiting 持续高于阈值（如 > 500）且
proxy_read_timeout设置过长时，可能预示连接堆积
