stub_status模块仅统计Nginx总体连接状态，无法直接识别静态资源请求；但可通过Writing状态近似反映大静态文件传输，并结合自定义静态资源日志与tail+awk实时聚合实现间接观测。
stub_status 模块本身不区分请求类型，它只统计 Nginx 当前工作进程的总体连接状态（活跃、空闲、总接受/处理/请求数），无法直接识别“静态资源请求”。但你可以通过合理配置 + 外部关联手段，间接实现对静态资源相关并发连接的可观测性。
理解 stub_status 的实际输出含义
启用后访问 /nginx-status（需配置 location）返回类似：
Active connections: 124 server accepts handled requests 287654 287654 456789 Reading: 3 Writing: 8 Waiting: 113
其中关键字段：
- Active connections：当前所有 TCP 连接数（包括 keepalive 空闲连接）
- Reading：正在读取请求头的连接数（通常极短，可忽略）
- Writing：正在向客户端发送响应的连接数（静态文件传输阶段主要体现于此）
- Waiting：keepalive 空闲连接，等待新请求
注意：Writing 状态最接近“正在传输静态资源”——尤其当你的静态资源较大（如 JS/CSS/图片）、启用了 gzip 或 sendfile，Nginx 会在 Writing 状态持续一段时间。
精准聚焦静态资源并发：靠日志 + 实时聚合
stub_status 无法过滤 URI，必须结合 access_log 和外部工具。推荐轻量方案：
- 为静态资源 location 单独定义 log_format，标记类型，例如：
log_format static '$time_iso8601 $status $body_bytes_sent $request_time';
location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff2?)$ {
access_log /var/log/nginx/static-access.log static;
expires 1y;
}
- 用
tail -f+awk实时统计当前活跃静态请求数（基于时间窗口）：
# 统计最近 1 秒内未结束的静态请求（需 log 中含 $request_time）
tail -f /var/log/nginx/static-access.log | \
awk -v now=$(date +%s.%N) '{elapsed = now - $1; if (elapsed < 1.0 && $2 == "200") print}' | \
wc -l
更稳定做法是用 goaccess 或 lnav 做流式分析，或接入 Prometheus + nginx-vts-exporter（它可按 location 分组暴露 metrics）。
通过 upstream + stub_status 间接隔离静态服务
若静态资源由独立 server 或 upstream 提供（如 CDN 回源、静态文件服务器集群），可在该 upstream 的 proxy_pass 后端启用 stub_status，并只监控那个 server 的状态：
- 在静态资源专用 server 块中启用 stub_status
- 用
curl http://static-backend/nginx-status单独采集 - 此时 Active connections / Writing 就基本反映静态资源层的真实并发压力
这种方式物理隔离了关注域，比单机 Nginx 内混杂动静态请求更清晰。
避免常见误解
- stub_status 不提供每个请求的 URI、大小、状态码细节 —— 它是连接级概览，不是请求级追踪
- “并发静态请求数” ≠ “Active connections”，因为后者包含 HTML、API、keepalive 空闲连接等
- 高 Waiting 值说明客户端复用连接多，未必代表压力大；高 Writing 且持续上升才提示静态响应变慢或带宽打满
- 务必确认 Nginx 编译时已包含
--with-http_stub_status_module（主流发行版默认开启）
