直接在 nginx 日志中记录 $upstream_response_time 可精准获取后端真实处理耗时，用于定位慢接口；该变量仅在 proxy_pass 等反向代理生效且后端返回响应后有效，多级重试时以逗号分隔各次耗时，并需结合 $upstream_addr 与 $upstream_status 判断最终成功请求。
直接在 Nginx 日志中记录 $upstream_response_time，就能看到每个请求后端服务的真实处理耗时，这是定位慢接口、分析上游性能最直接的方式。
确认 upstream 配置并启用该变量
这个变量只在使用 proxy_pass、fastcgi_pass 等反向代理指令，并且后端真正返回响应后才有效。如果请求没走到 upstream（比如 404、301 或被限流拦截），该值为空或为“-”。
- 确保你配置了
upstream块或直接用了proxy_pass http://... - 检查日志格式里是否已包含该变量，例如：
log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $upstream_response_time'; - 注意：一个请求可能经过多个 upstream（如重试），
$upstream_response_time会以逗号分隔，如0.002, 0.005，表示第一次失败、第二次成功，耗时分别为 2ms 和 5ms
区分单次与多次 upstream 调用
当开启 proxy_next_upstream 或发生重试时，$upstream_response_time 会记录所有尝试的耗时。你需要结合 $upstream_addr 和 $upstream_status 判断哪一次是最终成功的。
-
$upstream_addr显示实际通信的后端地址（含端口），可用来匹配对应耗时 -
$upstream_status对应每个耗时，也是逗号分隔，如502, 200表示第一次 502、第二次 200 - 若只关心最终成功那次，可用 Logstash、Fluentd 或脚本提取最后一个非空且对应 200 的值
用日志做基础耗时统计
不依赖额外监控系统，仅靠日志 + 命令行就能快速看出趋势：
- 查 P95 耗时（单位秒）：
awk '$NF ~ /^[0-9.]+$/ {print $NF}' access.log | sort -n | awk 'NR==int(NR*0.95)' | head -1 - 统计各耗时区间请求数：
awk '$NF ~ /^[0-9.]+$/ {t=$NF*1000; if(t - 找出最慢的 10 个请求：
awk '$NF ~ /^[0-9.]+$/ {print $NF, $0}' access.log | sort -nr | head -10
配合其他变量交叉分析更准
单独看 $upstream_response_time 只能知道后端花了多久，要归因还得关联上下文：
- 搭配
$request_time：后者是整个请求从读取到响应完成的总时间，减去$upstream_response_time就是 Nginx 自身处理（如 SSL 解密、header 解析、磁盘缓存等）开销 - 搭配
$upstream_connect_time：能看出建连是否慢（尤其在高延迟网络或连接池不足时） - 搭配
$status和$upstream_status：快速识别是不是某类状态码（如 504）集中出现在高耗时请求中
不复杂但容易忽略——只要 upstream 存在且响应正常，$upstream_response_time 就是后端真实耗时的可靠来源，关键在于日志格式写对、理解多值含义、再结合几个变量一起看。
