正确配置 $upstream_response_time 需避免引号包裹、理解“-”含义及多值分隔逻辑，并配合 $upstream_addr、$upstream_status、$request_id 等字段实现可归因的毫秒级性能诊断。
直接在 log_format 中加入 $upstream_response_time 就能记录后端响应耗时，但要真正用于性能诊断，必须确保它输出有效、可解析、带上下文的毫秒级数据——不是简单加个变量就完事。
正确写入变量，避免常见陷阱
该变量默认单位是秒，精度为毫秒（如 0.042 表示 42ms），但极易因配置错误失效：
- 不要用引号包裹变量，例如
'"$upstream_response_time"'会输出字面字符串"0.042"，导致日志解析失败；应写成$upstream_response_time - 值为
-表示未进入 upstream 流程（如 404、rewrite 跳转、proxy_pass 未命中），不是后端慢，而是根本没发请求 - 若启用重试（
proxy_next_upstream），会以逗号分隔多个值，如0.003,0.002,1.247，最后一段才是毛刺所在
搭配关键字段，让耗时可归因
单独一个数字无法定位问题。必须和以下字段组合使用：
-
$upstream_addr：显示真实转发到的IP:Port（如10.20.30.40:8080），快速锁定异常节点 -
$upstream_status：对应每次 upstream 的状态码（如200、502），区分是业务慢还是连接失败 -
$request_id或$http_x_request_id：提供跨服务链路追踪能力，确认是否同一请求多次变慢 -
$host和$uri：辅助判断是否特定域名或路径触发性能退化
推荐可用的日志格式模板
在 http{} 块中定义，兼顾可读性与机器解析友好：
'$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'$upstream_addr $upstream_response_time $upstream_status '
'$request_time $host $uri $request_id';
启用方式：access_log /var/log/nginx/perf.log perf_log;，放在 server 或具体 location 块内。
验证与初步分析要点
重启 Nginx 后，用 curl 触发一次代理请求，再检查日志末尾字段：
- 看到类似
10.1.2.3:8080 0.123 200 0.135 example.com /api/user abc123...，说明配置生效 - 若
$upstream_response_time明显大于$request_time，说明 Nginx 层处理极快，瓶颈在后端或网络 - 若多个
$upstream_response_time值中仅某一段突增（如0.004,0.003,1.289），大概率是单次 GC、慢 SQL 或锁竞争所致
