平均复用数=总HTTP请求数÷活跃连接数均值，稳定在10–50+说明Keep-Alive有效；长期低于2即“一请求一连接”；需结合$connection与$connection_requests趋势分析，并确保proxy_http_version 1.1等配置生效。

直接看 $connection_requests 的绝对值没有意义，关键要结合 $connection 和请求总量，算出平均复用次数，才能真实反映长连接是否被有效利用。

计算单连接平均处理请求数

这个平均值是判断复用效率最直观的指标。公式为：
平均复用数 = 总 HTTP 请求量 ÷ 当前活跃连接数（$connection）的长期均值
更稳妥的做法是用一段时间内（如 5 分钟）的累计请求数除以该时段 $connection 的平均值。

• 若结果稳定在 10–50+，说明 Keep-Alive 正常生效，后端也配合良好
• 长期低于 2，基本等于“一请求一连接”，复用完全失效
• 突然从 30 骤降到 3，可能某台后端开始返回 Connection: close 或超时异常

配合 $connection 看趋势组合

两个变量必须一起观察，孤立数值容易误判：

• 高 $connection + 低平均 $connection_requests：连接频繁新建又快速关闭，常见于后端不支持 Keep-Alive、Nginx 与后端 keepalive_timeout 不匹配、或 WAF/网关强制断连
• 低 $connection + 高平均 $connection_requests：连接复用充分，资源占用稳，延迟波动小
• $connection 突增但平均 $connection_requests 持续走低：可能是后端响应变慢，连接堆积未释放；也可能是连接泄漏，需查日志中 upstream_addr 是否集中某节点

在日志中记录并定期统计

把 $connection_requests 写入 access_log，便于按 upstream 或时间窗口聚合分析：

• 在 http 块中定义格式：log_format conn_stat '$remote_addr - $upstream_addr [$time_local] "$request" $status $body_bytes_sent "$http_user_agent" conn_req=$connection_requests conn=$connection';
• 用 awk 快速统计 1 小时内平均值：awk '{sum += $11; cnt++} END {print "avg:", sum/cnt}' /var/log/nginx/access.log
• 配合 $upstream_response_time 和 $upstream_addr，可定位是哪个后端节点拖累了整体复用率

注意变量作用域和采集前提

$connection_requests 是 Nginx 在连接关闭时才最终确定的计数，只对已关闭的连接有效。它不会实时更新正在使用的连接当前处理了多少请求。

• 它只在 upstream 场景下有意义，且依赖 proxy_http_version 1.1 和 proxy_set_header Connection '' 配置生效
• 如果后端返回了 Connection: close，该连接生命周期内只处理 1 个请求，$connection_requests 就是 1
• 不要把它和客户端到 Nginx 的 keepalive_requests 混淆——后者控制的是前端连接，与此无关