长连接的核心价值在于减少重复建连开销，体现为$upstream_response_time降低及$request_time与之差值收窄；需配置upstream keepalive、proxy_http_version 1.1和Connection头；通过$upstream_connect_time趋近于0验证复用效果。
直接看两者的差值变化趋势，比单看绝对值更有意义。长连接的核心价值不是让某次请求变快，而是减少重复建连开销，这种收益会稳定反映在 $upstream_response_time 的降低和 $request_time 与之差值的收窄上。
先确认长连接是否真正生效
检查 Nginx 配置中 upstream 块是否启用 keepalive，例如：
upstream backend {
server 127.0.0.1:8000;
keepalive 32;
}
同时确保 proxy_http_version 设为 1.1，并显式开启 Connection 头传递：
proxy_http_version 1.1;
proxy_set_header Connection '';
若未配置或客户端不支持 HTTP/1.1，$upstream_response_time 实际仍包含大量 TCP 握手和 TLS 协商耗时，此时分析无参考价值。
观察 $upstream_response_time 的分布变化
启用长连接后，同一 upstream server 的多次请求，其 $upstream_response_time 应呈现更集中的低值分布：
- 建连阶段（首次请求）的 $upstream_response_time 通常偏高，含 TCP+TLS 时间；
- 后续复用连接的请求，该值应明显下降且波动小，集中在应用处理本身耗时附近；
- 若大量请求的 $upstream_response_time 仍分散在 50ms–300ms 区间，说明连接复用率低或 keepalive 超时过短。
对比 $request_time − $upstream_response_time 的稳定性
这个差值主要反映 Nginx 自身处理时间（读请求体、发响应体、缓冲等）及客户端网络延迟。长连接本身不直接影响它，但能间接提升其稳定性：
- 未启用长连接时，该差值常伴随大幅跳变——因为每次建连失败重试、慢启动、SSL 重协商都会干扰 Nginx 的 I/O 调度；
- 启用后若该差值标准差显著缩小（例如从 ±120ms 降至 ±25ms），说明 Nginx 不再频繁被底层连接管理打断，I/O 更可预测；
- 特别注意 POST 大包场景：长连接下 $request_time 不再因反复建连而叠加额外延迟，差值更能真实反映上传/下载瓶颈。
结合 $upstream_connect_time 辅助验证
$upstream_connect_time 记录的是每次与上游建立 TCP 连接的实际耗时。它是判断长连接是否起效的“金标准”：
- 首请求该值可能为 5–50ms（取决于网络 RTT）；
- 后续请求若稳定趋近于 0.000 或 0.001，说明成功复用了连接；
- 若该值频繁出现非零值（尤其 >10ms），即使配置了 keepalive，也可能是 upstream server 主动断连、Nginx 端 idle 超时太短，或负载不均导致连接被分发到新节点。
