stub_status模块不提供“handling”指标，其handled值（已成功处理的连接数）是关键参考，需结合accepts差值、Active connections中Writing状态及requests/handled比值变化来动态识别静态服务瓶颈。
stub_status 模块本身不提供 “handling” 这一指标——它返回的是 accepts、handled 和 requests 三组累计计数，其中 handled（已成功处理的连接数）才是关键参考值，常被误称为 “handling”。真正能预判静态服务处理瓶颈的，是 handled 与其他指标的动态关系，而非孤立数值。
看 handled 与 accepts 的差值是否持续扩大
静态服务通常连接轻量、处理迅速，handled 应始终非常接近 accepts（即 handled ≈ accepts）。若观察到：
- accepts 持续增长，但 handled 增速明显滞后
- 差值（accepts − handled）在数分钟内稳步扩大（如从 5 增至 50+）
这说明有大量新连接被接受，却未能完成处理流程。常见原因包括：
– worker_connections 接近上限，新连接排队或被丢弃
– 内核连接队列（listen backlog）溢出，导致 accept() 失败但未计入 handled
– 静态文件磁盘 I/O 延迟高（如 HDD 随机读、ext4 journal 压力大），阻塞了连接释放
结合 Active connections 与 Writing 状态判断响应阻塞
静态资源服务的理想状态是：Active connections 中 Waiting 占比高，Writing 短暂且低。若出现：
- Writing 数值持续 ≥ 10（远高于日常均值）
- Active connections 居高不下，但 Waiting 明显偏低
- 同时 requests 增速放缓，甚至停滞
表明 Nginx 正在长时间向客户端发送响应——这往往不是网络带宽问题，而是后端存储响应慢：大文件未启用 sendfile、零拷贝失效；或启用了 gzip_static 但压缩文件缺失，触发运行时压缩阻塞 worker。
对比 handled 增速与 requests 增速的背离
对纯静态服务，一个 keepalive 连接常承载多个 requests（如 HTML + CSS + JS + 图片）。正常情况下 requests 增速应显著高于 handled。若发现：
- requests / handled 比值从平时的 8–15 陡降至 1.2–2.0
- Waiting 数值同步大幅下降
说明客户端无法复用连接，被迫频繁建连——根源常是客户端异常断连、中间代理（如某些 CDN 节点）主动关闭空闲连接，或 Nginx 的 keepalive_timeout 设置过短（如 ≤ 5s），导致连接刚空闲就被回收。此时 handled 被迫高频递增，掩盖了真实吞吐能力下降。
用时间窗口变化率替代绝对值做趋势预警
handled 是累计值，单次采样无意义。建议每 30 秒采集一次，计算每分钟 handled 增量 ΔH：
- ΔH 突然下降 40% 以上，且持续 2 个周期 → 检查磁盘 I/O wait 或 worker 进程卡顿（用 strace -p $(pidof nginx) -e trace=sendfile,writev）
- ΔH 波动剧烈（峰谷差 > 均值 3 倍），而系统负载平稳 → 关注 upstream 或 proxy_buffer 相关配置是否引发隐式阻塞
注意：多 worker 场景下，stub_status 默认只暴露当前 worker 数据。务必确认 nginx -T 输出中是否含 accept_mutex off；否则 ΔH 波动可能只是负载不均，非真实瓶颈。
