$upstream_connect_time单位是秒（浮点），非毫秒，直接当毫秒用会导致失真；它仅统计TCP建连耗时，不含DNS、TLS、连接池等待等，需结合$upstream_header_time等变量综合分析。
nginx 中 $upstream_connect_time 真实单位是秒，不是毫秒
直接用 $upstream_connect_time 做毫秒级分析会严重失真——它默认以秒为单位，精度仅到毫秒但实际值是浮点秒（如 0.003 表示 3ms），若未做转换就当整数毫秒处理，会导致所有耗时被截断为 0 或误判数量级。
常见错误现象：日志里大量出现 upstream_connect_time=0.000，但实际建连明显有延迟；或监控图表中 connect 耗时始终扁平、无波动。
- 必须在 log_format 中配合
$upstream_connect_time使用log_format ... $upstream_connect_time，不能只靠 access_log 默认格式 - 若需毫秒整数输出，推荐用
round($upstream_connect_time * 1000)（需 nginx ≥ 1.19.7，且开启--with-http_realip_module不影响） - 低版本 nginx（如 1.16）不支持内置 round，可用
map+ 正则提取小数点后三位再拼接，但更稳妥的做法是应用层解析浮点秒
单独看 $upstream_connect_time 容易误判真实瓶颈
$upstream_connect_time 只覆盖 TCP 连接建立阶段（SYN → SYN-ACK → ACK），不含 TLS 握手、DNS 解析、连接池等待等——而这些在 HTTPS 网关或高并发场景下常占主导。
使用场景举例：某网关升级后 $upstream_connect_time 平均从 2ms 升至 8ms，第一反应是后端节点网络变差，结果发现是启用了 mutual TLS，TLS 握手耗时新增 15ms，$upstream_connect_time 根本不统计这部分。
- 要定位完整链路，必须同时采集：
$upstream_header_time（含 connect + TLS + request send + response header recv）、$request_time（全周期）、$upstream_response_time（不含 connect） - DNS 解析耗时需额外开启
resolver并配合$upstream_addr中的 IP 判断是否命中缓存；若 upstream 用域名且未配resolver，DNS 阻塞会卡在 connect 阶段，但$upstream_connect_time无法区分是网络慢还是 DNS 慢 - 连接池等待时间完全不可见——若 upstream 配置了
keepalive 32但并发超限，新请求会在 upstream queue 中等待，这部分计入$request_time但不计入$upstream_connect_time
在 access_log 中安全输出 $upstream_connect_time 的写法
直接写 log_format main '$upstream_connect_time'; 会导致空值打成短横线 -，干扰数值解析；且未连接上游（如 503 错误）时该变量为空，日志格式错位可能破坏下游日志系统切分逻辑。
正确做法是用 map 提供默认值，并统一单位：
map $upstream_connect_time $upstream_connect_ms {
"" "0";
default "$upstream_connect_time";
}
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" '
'$upstream_connect_ms';
注意：$upstream_connect_ms 仍是浮点秒，只是空值转 0；如需真正毫秒整数，应由日志收集端（如 filebeat、fluentd）做 float * 1000 转换，避免 nginx 层计算开销。
对比 upstream 多个节点时，$upstream_connect_time 的取值逻辑
当 upstream 块含多个 server 且启用健康检查或 ip_hash，$upstream_connect_time 记录的是**最终成功建立连接的那个节点**的耗时，不是所有尝试节点的平均或最大值。这意味着：单次请求的日志里该值永远只有一个数字，无法反映重试过程中的失败连接耗时。
容易踩的坑：看到某次请求 $upstream_connect_time=0.120（120ms），就认为“这次连得慢”，但实际可能是前两次连接超时（各 3s），第三次才成功——而这 3s 重试耗时全被算进 $request_time，$upstream_connect_time 只记最后那次成功的 120ms。
- 要观测重试行为，必须开启
upstream_log_module（第三方模块）或使用 nginx plus 的$upstream_tries变量 - 开源版 nginx 可通过
error_log notice配合proxy_next_upstream_tries查看重试次数，但无法关联到具体哪次 connect 耗时 - 如果 upstream 使用
least_conn或hash $request_uri，节点选择逻辑复杂，$upstream_connect_time的分布可能掩盖真实网络不均衡问题——建议配合$upstream_addr拆解 per-node 耗时直方图
真正有效的链路分析，从来不是盯着单个变量放大镜式解读；$upstream_connect_time 只是一块拼图，漏掉 resolver 配置、TLS 开关状态、连接池水位或重试策略，结论就大概率跑偏。
