如何利用 $upstream_connect_time 变量区分网关建连耗时与业务逻辑执行耗时

$upstream_connect_time是Nginx 1.9.1+内置变量，记录Nginx与上游服务器建立TCP连接耗时（单位：秒，毫秒精度），不包含SSL握手、请求发送、响应接收及业务处理，仅反映网络层建连瓶颈，成功建连后赋值，非upstream请求或失败时为空或“-”。 $upstream_connect_time 是 Nginx 内置变量，记录的是 Nginx 与上游服务器（如后端服务）建立 TCP 连接所花费的时间（单位：秒，精度为毫秒，格式如 或 ），**不包含 SSL 握手、请求发送、响应接收、业务处理等环节**。它只反映“连上用了多久”，是诊断网络层或上游服务连接瓶颈的关键指标。 明确 $u ps tream_connect_time 的作用边界 该变量仅在成功建立连接后才有值（失败时为空或 -1）；若使用 keepalive 连接池，它通常为 0 或极小值（复用已有连接）；它**完全不反映业务耗时**——业务逻辑执行、数据库查询、缓存读写、序列化等都在 upstream 响应返回后才发生，而这些属于 $request_time 减去 $upstream_header_time 和网络传输时间后的剩余部分。 结合多个时间变量做分段归因 单靠 $upstream_connect_time 无法定位全链路瓶颈，需搭配其他变量交叉分析： $upstream_connect_time ：建连耗时 → 判断网络延迟、上游负载均衡器/防火墙策略、上游服务 accept 队列积压 $upstream_header_time ：从发起请求到收到上游响应首字节的时间 → ≈ 建连 + SSL 握手 + 请求发送 + 后端业务处理 + 响应头生成 $upstream_response_time ：从发起请求到收到完整响应的时间 → ≈ header_time + 响应体传输耗时 $request_time ：Nginx 接收客户端请求到发出完整响应的总耗时 → 包含客户端网络延迟、Nginx 自身处理、upstream 全链路、Nginx 发送响应给客户端等 例如：若 且反复出现，而 ，说明后端几乎没做业务处理（可能快速返回 5xx 或空响应）；若 但 ，则问题大概率在后端业务逻辑或依赖服务。 稿定在线PS PS软件网页版 下载 在日志中结构化输出便于分析 在 Nginx 日志 format 中显式记录关键时间字段，例如： log_format upstream_times'$remote_addr - $remote_user [$time_local] "$request" ''"$status" $body_bytes_sent "$http_referer" ''"$http_user_agent" "$http_x_forwarded_for" ''"$request_time" "$upstream_connect_time" "$upstream_header_time" "$upstream_response_time"'; 配合 ELK 或 Loki 收集后，可按 聚合告警，或对比 connect_time 与 header_time 的差值分布，识别“连接慢但处理快”或“连接快但处理卡顿”的典型模式。 注意代理场景下的变量有效性 该变量仅对实际转发到 upstream 的请求有效（即命中 proxy_pass）。若请求被 Nginx 本地拦截（如 return 403、rewrite、try_files 找到静态文件），$upstream_connect_time 为空；使用 proxy_cache 且命中缓存时，该变量也为 0 或空（无 upstream 调用）。务必确认 access log 条目对应的是真实 upstream 转发请求，避免误判。