关键在于区分客户端到Nginx和Nginx到后端的长连接：Waiting数反映客户端keepalive空闲状态，理想占比超90%；upstream连接池需通过error日志、handled/accepts差值及$upstream_connect_time间接判断；推荐nginx-vts或Prometheus采集keepalive复用率等细粒度指标。
监控 Nginx 长连接的利用率与空闲情况，关键在于区分两个层面：客户端到 Nginx 的长连接（upstream keepalive）和 Nginx 到后端服务的长连接复用（upstream keepalive）。二者指标不同、采集方式不同，但都直接影响资源占用与请求延迟。
看懂 stub_status 中的 Waiting 连接数
启用 ngx_http_stub_status_module 后，访问 /nginx_status 可见类似输出：
Active connections: 128<br>server accepts handled requests<br> 1562 1562 4230<br>Reading: 2 Writing: 5 Waiting: 121
Waiting 是判断客户端长连接空闲程度的核心指标：
- 它等于
Active connections − (Reading + Writing) - 数值高 ≠ 异常，而是说明大量连接处于 keepalive 空闲等待状态
- 若
Waiting持续占Active的 90% 以上，且keepalive_timeout设置合理（如 60–75s），说明客户端复用良好 - 若
Waiting极低（如长期为 0–5），可能因客户端主动断连、超时过短或未开启 keepalive 导致连接无法复用
检查 upstream keepalive 连接池使用率
Nginx 到后端的长连接由 upstream 块中的 keepalive N 控制，但该模块本身不暴露实时连接池占用数。需结合日志与间接指标判断：
- 观察
error.log中是否频繁出现"upstream connection is busy"或"no live upstreams"，这是连接池耗尽的明确信号 - 对比
stub_status中handled与accepts差值：若差值持续增大（如 handled = accepts − 1000+），说明部分连接被丢弃，可能因后端连接池满或健康检查失败 - 启用
log_format记录$upstream_connect_time和$upstream_header_time，若前者突增或大量为 “-”，说明 Nginx 正在反复建连，复用失效
用 nginx-vts 或 Prometheus 补足细粒度指标
stub_status 仅提供全局汇总，要精准评估长连接利用率，推荐以下增强方案：
-
nginx-vts-module：编译安装后，可查看每个 upstream 的
active、max_fails、slow_start及keepalive当前占用数（如keepalive: 28/32） -
Prometheus + nginx-prometheus-exporter：采集
nginx_upstream_keepalive_connections（当前空闲连接数）、nginx_upstream_requests_total（按复用/新建分类）、nginx_upstream_response_time_seconds_count（区分首次建连 vs 复用响应） - 重点关注比率：
rate(nginx_upstream_requests_total{state="reused"}[5m]) / rate(nginx_upstream_requests_total[5m])，理想值应 ≥ 85%
配置合理性交叉验证要点
单看指标不够，必须结合配置反推是否合理：
-
keepalive_timeout应略大于客户端平均请求间隔；若客户端每 10s 发一次请求，设为 15–20s 更稳妥 -
upstream.keepalive N建议设为后端单实例最大空闲连接数 × 1.2，避免因瞬时高峰挤占连接 -
worker_connections必须 ≥keepalive_requests × 并发连接数，否则 worker 会提前关闭空闲 keepalive 连接 - 检查系统级限制：
ulimit -n和net.core.somaxconn是否支撑预估连接峰值
