stub_status模块仅提供全局连接状态，无法区分各worker进程的reading/writing数值；需结合ss命令分析socket队列、vts模块或日志采样实现worker级监控。
Nginx 的 stub_status 模块能提供轻量级的实时连接状态，但它本身**不区分 Worker 进程**，也不直接暴露每个 Worker 的 Reading/Writing 状态。要实现“按 Worker 进程粒度监控 Reading/Writing”，需结合其他机制补足限制。
stub_status 的实际输出内容与局限
stub_status（通常配置在 /status 或类似路径）返回三行文本：
- Active connections: 当前所有 Worker 共享的活跃连接总数（即处于 reading/writing/waiting 状态的连接总和）
- server accepts handled requests：三个累加值，反映整体吞吐
- Reading: x Writing: y Waiting: z：这三个数字是**全部 Worker 进程当前状态的汇总**，不是单个 Worker 的快照
关键点：Nginx 主进程不向 stub_status 暴露各 Worker 的独立状态；Worker 进程间也不共享连接状态计数器。因此，仅靠 stub_status 无法直接获取“Worker 0 Reading=2, Worker 1 Reading=5”这类数据。
替代方案：通过 nginx -T + /proc + ss 实时估算 Worker 级状态
虽然不能精确读取每个 Worker 的 Reading/Writing 计数，但可通过以下组合方式**近似分析各 Worker 的 I/O 活跃度**：
-
定位 Worker 进程 PID：运行
ps -eo pid,comm,args | grep 'nginx: worker'获取所有 worker PID -
检查每个 Worker 的 socket 连接状态：对每个 PID 执行
ss -tnp | grep "pid=$PID" | awk '{print $1}' | sort | uniq -c，统计其 ESTAB 连接中处于recv-q（reading）或send-q（writing）非零的连接数 - 关联 stub_status 总 Reading/Writing：将各 Worker 的非零队列连接数加总，应与 stub_status 中 Reading + Writing 值大致匹配（存在短暂延迟和统计窗口差异）
注意：此方法依赖 Linux socket 队列深度（recv-q/send-q），并非 Nginx 内部状态，但实践中能有效反映 Worker 是否卡在读请求头、写响应体或 SSL 握手等环节。
增强可观测性：启用 nginx 的 status API（需编译 --with-http_stub_status_module + --with-http_realip_module）
若使用 OpenResty 或较新 Nginx（≥1.19.6），可考虑：
– 启用 ngx_http_api_module（OpenResty 自带）或第三方模块如 nginx-module-vts（Virtual Host Traffic Status）
– vts 可按 upstream、server、甚至 worker 分组展示 active connection、request rate、response time，并支持 JSON 输出
– 它通过共享内存收集各 Worker 上报的状态，比 proc/ss 更稳定、更接近真实 Reading/Writing 语义
日志 + 动态采样辅助判断高 Reading/Writing 场景
当发现 stub_status 中 Reading 或 Writing 持续偏高时，可快速排查原因：
-
Reading 高常见于：客户端上传大文件未限速、HTTP/2 流控异常、TLS 握手慢、前端代理未正确设置
proxy_buffering off - Writing 高常见于：后端响应慢且 Nginx 缓冲区满、客户端下载速率低（如移动网络）、启用 gzip 但 CPU 不足导致压缩阻塞
-
快速验证：临时开启
log_format debug '$connection $connection_requests $status $body_bytes_sent $request_time $upstream_response_time'；access_log /var/log/nginx/debug.log debug；，观察高 request_time 且 status=200 的请求是否集中在某类 URI 或 client IP
配合 nginx -s reload 后观察 stub_status 数值回落速度，也能反推是否为瞬时积压还是持续瓶颈。
不复杂但容易忽略：stub_status 是全局视图入口，真正定位到 Worker 级 I/O 行为，得靠系统层观测 + 模块扩展 + 日志交叉验证。
