$connection_requests仅反映单连接生命周期内累计请求数，非复用率指标；需结合时间戳、连接数及后端池指标综合计算，避免将高频短轮询或长空闲误判为高效复用。
直接看 $connection_requests 变量本身并不能准确反映单个 TCP 连接的请求复用率——它只是 Nginx 等服务器暴露的一个累计计数器，记录该连接**生命周期内处理过的总请求数**，不带时间维度、不区分连接状态、也不提供连接粒度的原始数据。要真正分析复用率，需结合上下文指标和采集方式。
理解 $connection_requests 的本质与局限
这个变量常见于 Nginx 的 stub_status 模块或 OpenResty 的 Lua 环境中，例如：
- 在
log_format中可写成$connection_requests记入 access 日志； - 在 stub_status 页面（如
/nginx_status）中显示为 “Reading: x Writing: y Waiting: z” 后的 “requests: N” 总值； - 它只对当前活跃连接有效，连接关闭后该值即消失，无法回溯。
⚠️ 关键限制：它不告诉你“这个连接活了多久”“是否空闲过久”“是否被多个客户端轮用”，更无法区分是 HTTP/1.1 Keep-Alive 复用还是 HTTP/2 多路复用。单看一个值，比如 $connection_requests = 42，你只知道这连接处理过 42 次请求，但不知道是 1 秒内密集发出，还是 5 分钟内零散发生——而这直接影响复用效率判断。
真正有效的复用率计算方法
复用率不是单一数字，而是“单位连接承载的有效请求数”与“理论最大承载能力”的比值。推荐以下两种实操路径：
-
按连接生命周期统计（推荐）：在 access log 中同时记录
$connection_requests、$request_time、$time_iso8601和$server_addr。用日志分析工具（如 awk + sort 或 Loki + LogQL）提取每个连接的首次和末次请求时间戳，再按$remote_addr:$remote_port → $server_addr:$server_port聚合，计算：复用率 = Σ(connection_requests) / 实际建立的 TCP 连接数（后者可通过抓包或 netstat 统计）； -
按服务端连接池视角统计（更准）：若使用 Kitex、gRPC 或自研连接池，直接读取池内指标，例如：
– 当前活跃连接数
– 总已处理请求数（全局）
– 平均每连接请求数 = 总请求数 ÷ 活跃连接峰值
该值 > 50 通常表示复用良好，
辅助验证：用 Wireshark 或 ss 定位低效连接
仅靠日志易误判。建议同步做网络层验证：
- 用
ss -i查看连接的retrans、rtt、qsize，高重传或大 rtt 的连接即使$connection_requests高，也可能是病态复用； - Wireshark 抓包过滤
tcp.stream eq X && http，观察同一 stream 内请求间隔是否稳定、有无长时间空闲（>30s），空闲期长却仍不释放，说明复用策略保守或配置不当； - 对比
$connection_requests和$upstream_header_time：若前者很高但后者波动剧烈，可能后端连接池未复用，只是前端在复用——此时真实复用率被高估。
避免常见误读陷阱
以下情况会让 $connection_requests 看似很高，但不代表健康复用：
- 客户端使用短轮询（如每 2s 发一次 GET），导致单连接持续发送大量低价值心跳请求；
- HTTP/1.1 下设置了过长的
keepalive_timeout（如 300s），连接空闲 4 分钟才关闭，期间只处理 1 个请求； - 后端服务返回
Connection: close，强制断开，前端又立即重建——此时$connection_requests始终为 1，但连接频次极高。
真正有意义的复用，是连接在活跃期内承载多业务请求、空闲时间可控、且无异常中断。$connection_requests 是起点，不是终点。
