stub_status模块仅提供全局Reading/Writing连接数，不支持按Worker进程细分；其数据来自共享内存计数器，需结合debug日志、ss/netstat或OpenResty+Lua等方案实现per-worker状态分析。
Nginx 的 stub_status 模块本身不提供每个 Worker 进程的 Reading/Writing 状态细分，它只返回全局汇总指标。要分析“当前所有 Worker 进程各自的 Reading/Writing 状态”，需结合其他机制——stub_status 是入口，但不是终点。
stub_status 输出的实际含义
stub_status（通常配置在 /nginx_status）返回三行文本，例如：
Active connections: 124 server accepts handled requests 15623 15623 48752 Reading: 3 Writing: 6 Waiting: 115
其中：
- Reading：Nginx 正在从客户端读取请求头（或请求体）的连接数；
- Writing：Nginx 已读完请求、正在向客户端发送响应的连接数；
- Waiting：已处理完请求、保持长连接等待新请求的空闲连接数（即 keep-alive 状态）。
⚠️ 注意：这三个值是**全站所有 Worker 进程共享的总和**，不按 Worker 拆分。
为什么不能直接从 stub_status 获取 per-worker 状态
stub_status 基于 Nginx 共享内存（shared memory zone）中的全局计数器，由所有 Worker 进程原子更新。它设计目标是轻量、低开销的监控，不记录进程级上下文。Nginx 官方未暴露 per-worker 的 socket 状态快照接口。
可行的替代方案：定位高 Reading/Writing 的 Worker
若目标是排查某个 Worker 是否异常卡在 Reading 或 Writing，可组合以下方法：
-
启用 error_log debug 级别 + connection ID 追踪：在临时调试时开启
error_log /path/to/error.log debug;，配合$connection和$connection_requests变量，结合日志时间戳与连接生命周期，反推某连接在哪个 Worker 上长期处于 Reading（如大文件上传卡住）或 Writing（如后端响应慢、缓冲区满）； -
用 ss 或 netstat 结合 worker 进程 PID 绑定分析：若启用了
worker_cpu_affinity或bind，不同 Worker 监听不同端口/地址，可用ss -tnp | grep :$port查看各端口连接状态（SYN_RECV、ESTAB 等），再映射到对应 Worker； -
通过 OpenResty + Lua 扩展实时采集：在
init_worker_by_lua_block中注册定时器，用ngx.worker.pid()区分进程，配合ngx.status()（OpenResty 提供）或自定义计数器，在每个 Worker 内部统计其处理中的 Reading/Writing 连接数，并通过 shared dict 暴露为 HTTP 接口。
快速判断是否真有 Worker 卡住的小技巧
虽然看不到每个 Worker 的 Reading/Writing 数，但可通过间接信号预警：
- 持续观察
stub_status中Reading值长期 >10 且不下降 → 可能存在未完成的 POST 请求（如上传中断、客户端丢包）； -
Writing显著升高 +upstream_response_time日志中大量超时 → 某个 Worker 正阻塞在慢后端上； - 对比
ps aux | grep nginx中各 worker 进程的%CPU和TIME+，若某进程 CPU 持续 90%+ 且 TIME 增长极快，再结合其处理的请求特征（如固定 URL），可定位问题 Worker。
