$upstream_connect_time仅记录nginx与upstream完成tcp三次握手耗时（毫秒级），不含ssl、dns等；需结合$upstream_addr、$upstream_response_time等变量交叉分析，并排除keepalive复用、dns解析、本地端口耗尽等干扰。
要通过 $upstream_connect_time 精准排查反向代理网络层连接延迟，关键在于理解它的真实含义、采集上下文、结合其他变量交叉验证，并排除常见干扰因素。
明确 $upstream_connect_time 的作用边界
$upstream_connect_time 记录的是 Nginx 与 upstream 服务器完成 TCP 三次握手所耗时间（单位：秒，精度为毫秒），不包含 SSL 握手、DNS 解析、请求发送或响应接收阶段。它只在成功建立连接后才有值；若连接失败（如超时、拒绝、无可用后端），该变量为空或为“-”。因此，它反映的是纯网络链路 + 目标服务 TCP 栈响应能力，而非整体后端性能。
必须搭配采集的关联变量
单看 $upstream_connect_time 容易误判，需同步记录以下变量：
-
$upstream_addr：确认实际连接的目标 IP 和端口（尤其当使用动态 upstream 或 DNS 解析时） -
$upstream_response_time：区分是连接慢（connect_time 高但 response_time 接近 connect_time），还是处理慢（response_time 显著大于 connect_time） -
$status和$upstream_status：过滤掉连接失败（如 502/504）或上游返回非 2xx 的请求，避免将失败重试计入延迟统计 -
$request_time：对比客户端视角总耗时，判断连接延迟是否构成主要瓶颈 - （可选）
$upstream_http_x_request_id或自定义 trace_id：用于跨系统追踪同一请求在 upstream 侧的日志
在日志中结构化记录并做分位分析
在 log_format 中显式输出关键字段，例如：
然后用日志分析工具（如 awk / Loki / Grafana + Promtail）按 $upstream_addr 分组，计算 P90/P95 的 $upstream_connect_time。若某 IP 的 P95 connect_time 持续 >100ms，而其他节点正常，则大概率是该机器所在网络区域存在路由问题、防火墙策略限制或目标服务 TCP backlog 拥塞。
主动验证与隔离干扰项
发现异常 connect_time 后，不能直接归因为“网络差”，需逐项排除：
- 检查 Nginx 是否启用了
keepalive：若开启且复用连接，$upstream_connect_time多为 0 或极小值；此时高 connect_time 往往出现在新连接建立场景（如长连接过期、负载突增） - 确认 upstream 配置是否含
resolve或变量域名：DNS 解析延迟不计入 connect_time，但会导致首次建连前卡顿，需单独测dig或nslookup - 在 Nginx 本机执行
curl -w "@format.txt" -o /dev/null -s http://upstream_ip:port/health，用相同 format.txt 输出 time_connect，比对是否与 Nginx 日志一致 —— 可确认是否 Nginx 自身问题（如 socket 创建慢、本地端口耗尽） - 检查 upstream 主机的
ss -s和netstat -s | grep -i "connection.*refused\|failed"，确认是否存在 SYN queue overflow 或 connection drops
