要定位集群瓶颈，需在日志中同时记录$upstream_connect_time、$upstream_addr和$upstream_status并严格一一对应，配合$upstream_cache_status过滤回源请求、$http_x_request_id支持链路追踪，结合命名upstream块与定制log_format实现可归因、可筛选、可分层分析。

要捕获 upstream_connect_time 来定位集群瓶颈，核心不是单纯记录这个值，而是让它在日志中“可归因、可筛选、可分层”。

必须同时记录上游地址和状态
$upstream_connect_time 单独存在没有意义。它只在真正发起 upstream 请求时有值（MISS/EXPIRED/BYPASS 等回源场景），且数值与 $upstream_addr、$upstream_status 严格一一对应。多台后端时，三者均以逗号分隔，顺序一致：
10.0.1.3:80,10.0.1.4:80
0.002,0.047
200,502
这样你才能知道：是哪台机器连了多久、是否失败、有没有被重试拉高耗时。

定义带上下文的 log_format
在 http 块中添加：

log_format upstream_diag '$remote_addr - $remote_user [$time_local] '
                          '"$request" $status $body_bytes_sent '
                          '$upstream_addr $upstream_status $upstream_connect_time '
                          '$upstream_header_time $upstream_response_time '
                          '$upstream_cache_status $http_x_request_id';

• 不要省略 $upstream_cache_status：过滤出真正回源的请求（如 MISS、EXPIRED、BYPASS），排除 HIT/STALE 的干扰
• 保留 $http_x_request_id：便于跨服务追踪单次慢连接是否引发后续异常

在 location 中启用并确保 upstream 生效

location /api/ {
    proxy_pass http://backend_cluster;
    access_log /var/log/nginx/upstream_diag.log upstream_diag;
}

注意：

Livestream Script Generator

直播带货脚本：话术、节奏、互动、促单。适用于主播、电商运营、MCN机构。

下载

• 必须使用命名 upstream 块（如 upstream backend_cluster { server ...; }），直写 IP 可能导致部分版本中变量为空
• 若日志里 $upstream_connect_time 大量为 - 或空，先检查 error.log 是否有 no live upstreams、Connection refused、resolver timeout

用日志快速识别三类典型集群瓶颈

• 节点级失衡：某 IP（如 10.0.1.7:80）的 $upstream_connect_time P95 持续 >80ms，而其他节点稳定在 2–5ms → 登该节点查 ss -s、netstat -s | grep -i "syn"、iptables -L -t raw
• 连接池枯竭：大量请求 $upstream_connect_time 接近 0.000 或 0.001，但 $upstream_header_time 显著偏高 → 检查 upstream keepalive 设置是否过小，或后端 accept 队列溢出（ss -lnt | grep :8080 看 ListenOverflows）
• 偶发毛刺集中爆发：某分钟内 >200ms 的连接集中在同一 upstream_addr，且 $upstream_header_time − $upstream_connect_time 很小 → 大概率是 TLS 握手卡顿或证书协商异常，而非网络延迟

不复杂但容易忽略