stub_status模块仅提供全局连接与请求统计，不支持按worker进程粒度监控；需结合lsof统计ESTABLISHED连接、access_log中$pid字段分析QPS，辅以CPU/RSS监控识别负载倾斜。
Nginx 的 stub_status 模块本身不提供按 worker 进程粒度的连接与吞吐统计，它只暴露全局的汇总指标（如总活跃连接、已接受/处理/请求总数）。若需分析各个 worker 的活跃连接与处理吞吐，需结合操作系统级观测手段和 Nginx 内部机制，而非依赖 stub_status 单独实现。
理解 stub_status 的局限性
stub_status 输出形如：
Active connections: 124<br>server accepts handled requests<br>15678 15678 23456<br>Reading: 3 Writing: 8 Waiting: 113
这些是全 server 级别累加值，由 master 进程聚合所有 worker 的共享计数器（如 ngx_stat_accepted）生成。Nginx 默认不为每个 worker 维护独立可导出的运行时状态接口。
通过进程级网络连接推断各 worker 的活跃连接
每个 worker 进程绑定到监听 socket 后，实际建立的 TCP 连接会归属到对应 worker 的文件描述符中。可通过以下方式间接识别：
- 用
ps aux | grep nginx查出所有 worker 进程 PID - 对每个 PID 执行
lsof -p $PID -iTCP -sTCP:ESTABLISHED | wc -l，统计其 ESTABLISHED 状态连接数（近似活跃连接） - 注意：该方法在高并发下有短暂延迟，且无法区分“正在读写”还是“空闲等待”，但能反映连接负载分布是否均衡
估算各 worker 的请求处理吞吐（QPS）
Nginx 不直接暴露 per-worker 的 request/sec，但可通过时间窗口内日志 + 进程 ID 实现粗略估算：
- 启用
$pid变量记录到 access_log（如log_format detailed '$pid $remote_addr ... $request_time';） - 用
awk '{print $1}' access.log | sort | uniq -c | sort -nr统计各 PID 在日志时间段内的请求数 - 除以采样时长，即得各 worker 平均 QPS；配合
request_time还可分析响应延迟分布 - 注意：需确保 log_format 中包含
$pid，且日志缓冲未开启（buffer=... flush=...可能导致延迟）
辅助验证：检查 worker 负载是否明显倾斜
即使无法实时获取吞吐，也可通过系统指标快速发现异常 worker：
- 监控各 worker 的 CPU 使用率：
top -p $(pgrep nginx | tail -n +2 | tr '\n' ',' | sed 's/,$//') - 观察 RSS 内存占用差异，过大的偏差可能暗示连接堆积或内存泄漏
- 检查是否有 worker 长期处于 idle 状态（如持续 0 连接+0 日志），可能是被意外阻塞或未正确加入事件循环
