Nginx原生stub_status不支持按Worker进程粒度暴露状态，仅提供实例级聚合统计；需通过vts模块、多实例或系统工具间接实现，其中nginx-module-vts为生产推荐方案。
Nginx 的 stub_status 模块本身不支持按 Worker 进程粒度暴露状态，它只提供整个 Nginx 实例的聚合统计（如总接受连接数、处理中连接数等），且默认是全局共享的。要获取“每个 Worker 进程”的实时处理状态分布，需借助外部机制间接实现——核心思路是：让每个 Worker 绑定独立端口或路径，并启用各自的 stub_status，再通过进程隔离方式暴露指标。
前提：启用 stub_status 并确认模块已编译
确保 Nginx 编译时包含 --with-http_stub_status_module（主流发行版包通常已启用）。可通过以下命令验证：
nginx -V 2>&1 | grep -o with-http_stub_status_module
若无输出，需重新编译或更换支持该模块的版本。
方案一：为每个 Worker 分配独立监听端口（推荐）
利用 worker_processes auto 或显式指定数量后，通过环境变量 + Lua/OpenResty 或 systemd socket 激活等方式区分端口。但更实用、无需额外依赖的方式是：使用 stream 模块反向代理到不同本地端口，配合每个 Worker 启动时读取自身 PID/序号并监听唯一端口——这需定制启动脚本。更轻量的做法是：
- 手动设置固定 worker 数（如
worker_processes 4） - 在配置中用
pid /var/run/nginx.pid;记录主进程 ID - 配合
nginx -t和信号控制，用脚本为每个 worker 启动一个独立的最小 Nginx 实例（仅含 stub_status），监听如127.0.0.1:8081～:8084
⚠️ 注意：Nginx 官方不支持单实例内多个 stub_status 端点；多实例方案虽可行，但运维成本高，适合调试或小规模部署。
方案二：用 nginx-module-vts + Prometheus（生产推荐）
nginx-module-vts（Virtual Host Traffic Status）可提供 per-worker、per-server、per-upstream 的详细指标，包括当前活跃连接、请求速率、响应时间等，并原生支持 JSON 输出和 Prometheus 格式导出。
- 编译时添加
--add-module=/path/to/nginx-module-vts - 配置示例：
vhost_traffic_status_zone; server { location /status { vhost_traffic_status_display; vhost_traffic_status_display_format html; } location /status/format/json { vhost_traffic_status_display; vhost_traffic_status_display_format json; } } - 访问
/status/format/json可看到"workers"字段，列出每个 worker 的 PID、活跃连接、请求计数等实时数据
方案三：结合系统工具采集进程级连接状态
虽然不是 Nginx 原生 stub_status，但可真实反映各 worker 的负载分布：
- 每个 Nginx worker 是独立进程，PID 可从
ps aux | grep 'nginx: worker'获取 - 用
ss -tnp | grep :80 | awk '{print $7}' | sort | uniq -c | sort -nr查看各 worker 绑定的 socket 连接数 - 配合
/proc/[pid]/fd/统计文件描述符使用量，间接反映处理压力
此法无需改配置，适合快速诊断，但非 HTTP 接口，不能直接集成监控系统。
真正意义上的“每个 Worker 的 stub_status”在标准 Nginx 中不存在，必须通过扩展模块、多实例或系统层采集来逼近目标。vts 模块是最平衡的选择：零侵入、指标全、易集成、社区维护活跃。
