$upstream_connect_time是评估代理链路网络质量最干净的方式，仅反映tcp建连耗时（syn→syn-ack→ack），剥离后端处理、tls握手、dns解析等干扰；其值仅在三次握手成功后有效，失败时为“-”或空，大量0.000通常表示连接未成功而非飞快，需结合error.log排查connect()失败、connection refused等错误，并通过与$upstream_header_time对比差值定位纯网络层瓶颈或tls/业务逻辑问题。
直接看 $upstream_connect_time 是评估代理链路网络质量最干净的方式——它只反映 TCP 连接建立耗时（SYN → SYN-ACK → ACK），剥离了后端处理、TLS 握手、DNS 解析等干扰项，专盯“连得上不、连得快不”。
确认变量值是否真实有效
该变量仅在成功完成 TCP 三次握手后才有数值，失败或未建连时显示为 - 或空。若日志中大量出现 0.000，不代表建连飞快，很可能是连接根本没成功（如 DNS 失败、目标端口未监听、防火墙拦截）。需同步检查 error.log 中是否有：
- connect() failed、Connection refused、Operation timed out
- no live upstreams（上游全不可用）
- resolver timeout（若 upstream 使用域名且配置了 resolver）
识别典型网络异常模式
结合数值分布和时间特征，可快速归类问题根源：
- 持续偏高（P95 > 100ms）：大概率是宿主机网络栈瓶颈，比如 net.ipv4.tcp_tw_reuse 未启用、SYN 队列溢出（ss -lnt | grep :port 查 ListenOverflows）、iptables ACCEPT 链路延迟、或目标端口被 rate-limit 限速
- 偶发 60s 超时：不是网络慢，而是连接卡死。重点查源站进程是否僵死、SLB 健康检查失准导致流量打到故障节点、或 DNS 解析失败（尤其 upstream 用域名但未配 resolver 或缓存过期）
- 仅特定 upstream_addr 异常：说明问题局限在某个后端实例，不是全局链路问题。立刻登录该节点，查 CPU/内存/连接数、netstat -s 看是否有 drop、iptables -L -t raw 看有无早期丢包规则
必须搭配 $upstream_header_time 对比分析
单看 $upstream_connect_time 容易误判。真正关键的是两者差值：
- $upstream_connect_time ≈ $upstream_header_time（例如 0.023 vs 0.025）→ 后端响应极快，问题纯属网络层或连接池（如 keepalive 不足导致频繁重建连接）
- $upstream_header_time 远大于 $upstream_connect_time（例如 0.002 vs 0.310）→ TLS 握手、请求发送、或后端业务逻辑拖慢了整体，此时应排查证书协商、HTTP/2 设置、慢 SQL、同步调用阻塞等
- $upstream_connect_time 为 -，但 $upstream_header_time 有值：不可能，因为 header_time 依赖 connect_time 已完成；若出现，说明日志字段错位或变量引用错误
注意单位与精度陷阱
$upstream_connect_time 单位是秒（浮点），不是毫秒。0.012 表示 12ms，不是 0.012ms。低版本 Nginx（如 1.16）不支持 round()，若需整数毫秒输出，建议在日志采集侧（如 Logstash）做 float 转换，而非在 log_format 中硬截断。避免把 0.0007 当成 0ms 忽略——它代表 0.7ms，对高频短连接场景可能暴露真实抖动。
