$upstream_connect_time是Nginx 1.9.1+内置变量，记录Nginx与上游服务器建立TCP连接耗时（单位：秒，毫秒精度），不包含SSL握手、请求发送、响应接收及业务处理，仅反映网络层建连瓶颈，成功建连后赋值，非upstream请求或失败时为空或“-”。
$upstream_connect_time 是 Nginx 内置变量，记录的是 Nginx 与上游服务器（如后端服务）建立 TCP 连接所花费的时间（单位：秒，精度为毫秒，格式如 0.002 或 0.125），**不包含 SSL 握手、请求发送、响应接收、业务处理等环节**。它只反映“连上用了多久”，是诊断网络层或上游服务连接瓶颈的关键指标。
明确 $upstream_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 发送响应给客户端等
例如：若 $upstream_connect_time=0.321 且反复出现，而 $upstream_header_time=0.325，说明后端几乎没做业务处理（可能快速返回 5xx 或空响应）；若 $upstream_connect_time=0.001 但 $upstream_header_time=2.8，则问题大概率在后端业务逻辑或依赖服务。
在日志中结构化输出便于分析
在 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 收集后，可按 upstream_connect_time > 0.1 聚合告警，或对比 connect_time 与 header_time 的差值分布，识别“连接慢但处理快”或“连接快但处理卡顿”的典型模式。
注意代理场景下的变量有效性
该变量仅对实际转发到 upstream 的请求有效（即命中 proxy_pass）。若请求被 Nginx 本地拦截（如 return 403、rewrite、try_files 找到静态文件），$upstream_connect_time 为空；使用 proxy_cache 且命中缓存时，该变量也为 0 或空（无 upstream 调用）。务必确认 access log 条目对应的是真实 upstream 转发请求，避免误判。
