Nginx stub_status不直接提供active/handled比例，需自行计算；该比值因量纲不同无绝对意义，实用指标包括requests/handled（keepalive效率）、active/(handled/uptime)（负载倍数）及状态分布分析。
通过 Nginx 的 stub_status 模块，可以实时获取当前活跃连接数（active connections）与已处理请求数（handled requests）的比例，辅助判断服务负载趋势和连接复用效率。这个比例本身不直接暴露在 stub_status 输出中，需结合其原始指标自行计算。
理解 stub_status 输出的关键字段
启用 stub_status 后（如配置 location /nginx-status { stub_status; }），访问该端点会返回三行文本，例如：
server accepts handled requests
15682 15682 42397
Reading: 3 Writing: 8 Waiting: 113
其中：
- Active connections：当前所有处于活跃状态的 TCP 连接数（包括 Reading、Writing、Waiting 状态）
- accepts：Nginx 自启动以来接受的总连接数
- handled：成功处理（未因资源不足被丢弃）的连接数，通常与 accepts 相等，除非发生 accept queue 溢出
- requests：总共处理的 HTTP 请求次数（一个连接可承载多个请求）
计算 active connections 与 handles 的比例
注意：“handles” 并非 stub_status 的标准术语，通常指 handled 字段（即成功处理的连接数）。但需明确：active connections 是瞬时值，handled 是累计值，二者量纲不同，直接比值无绝对意义。真正有参考价值的是：
- active / (handled / uptime)：估算当前活跃连接数相对于平均连接处理速率的倍数（需配合运行时长）
- requests / handled：平均每个连接处理的请求数（反映 keepalive 效率）
- active / (requests / handled)：粗略反推“正在被服务的连接中，平均承载多少请求”，间接体现连接利用率
若你实际想监控的是 活跃连接数随 handled 增长的变化斜率（即单位新增 handled 对应多少 active），建议用 Prometheus + nginx-exporter，或定时采集并做差分计算。
用脚本实现轻量级比例跟踪
例如用 curl + awk 实时计算 active / handled（仅作趋势观察，数值会随 handled 增大而自然衰减）：
NR==1 { active = $3 }
NR==3 { handled = $2 }
END { if(handled>0) printf "Ratio (active/handled): %.4f\n", active/handled }'
更实用的做法是每 10 秒采集一次，记录 active 和 handled 的增量：
- 第一次采样得
active1, handled1 - 10 秒后得
active2, handled2 - 计算
(handled2 - handled1) / 10（平均每秒新建连接处理数） - 再对比
active2是否持续高于该速率的 5–10 倍——若远高于，说明大量连接长期空闲（Waiting 多），可能 keepalive_timeout 过长或客户端异常挂起
结合 Waiting/Reading/Writing 判断真实压力
单纯看 active 与 handled 比例容易误判。关键看状态分布：
- Waiting 高 + active 高：连接复用充分，但大部分处于 keepalive 等待状态，未必代表压力大
- Reading/Writing 高 + active 高：连接正密集收发数据，更可能接近性能瓶颈
-
handled 远小于 accepts：出现连接拒绝，需检查
worker_connections或系统级 file descriptor 限制
因此，建议将 active connections 与 Waiting、handled 三者同时绘图，观察它们的联动关系，而非只盯一个比值。
