$request_time 与 $upstream_response_time 的差值可定位性能瓶颈：前者为请求总耗时，后者为上游响应耗时；若差值大则问题在 Nginx 侧（如 SSL、rewrite），若接近则瓶颈在上游服务。
在 Nginx 中，$request_time 和 $upstream_response_time 是两个关键的性能指标变量，它们反映不同阶段的耗时，对比它们能快速定位性能瓶颈是在 Nginx 本身（如 SSL 握手、请求解析、响应组装）还是上游服务（如后端应用、数据库）。
理解两者的含义与统计范围
$request_time：从客户端建立连接开始，到 Nginx 完全发送响应给客户端结束的总耗时（单位：秒，精度为毫秒）。它包含：
- TCP 连接建立（含 TLS 握手）
- 请求头/体接收时间
- upstream 通信时间（含等待和传输）
- 响应头/体发送时间
- 任何 Nginx 模块处理时间（如 rewrite、access 控制等）
$upstream_response_time：Nginx 与 upstream（如 proxy_pass 指向的服务）之间完成一次完整请求-响应交互所用的时间。它仅统计：
- 向 upstream 发起请求并等待首字节返回的时间（即“后端处理+网络往返”）
- 若配置了多个 upstream server 或使用了 proxy_next_upstream，该变量会记录每次尝试的时间，用逗号分隔（例如 "0.024, 0.018"）
在日志中同时记录并对比
在 log_format 中将两者一并输出，便于后续分析：
log_format main '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'$request_time $upstream_response_time '
'"$http_referer" "$http_user_agent"';启用后，日志行类似：
192.168.1.100 - - [10/Jul/2024:14:22:35 +0800] "GET /api/user HTTP/1.1" 200 124 0.156 0.122
此时可直观看出：
- 总耗时 0.156s，上游耗时 0.122s → Nginx 自身开销约 0.034s（合理）
- 若 $request_time 显著大于 $upstream_response_time（如 2.3s vs 0.015s），说明瓶颈在 Nginx 端（如大文件上传、SSL 开销、大量 rewrite 规则、磁盘 I/O 等）
- 若两者接近（如 0.087s vs 0.085s），说明上游是主要延迟来源
注意多 upstream 或重试场景下的解读
当发生 upstream 重试时，$upstream_response_time 会记录所有尝试的耗时（逗号分隔），而 $request_time 是总耗时。例如：
"GET /search HTTP/1.1" 200 342 1.428 "0.312, 1.105"
表示：
- 第一次 upstream 调用耗时 0.312s（失败或超时）
- 第二次调用耗时 1.105s（成功）
- 总请求耗时 1.428s（含两次连接、等待、可能的重试间隔等）
- 两者差值（1.428 − (0.312 + 1.105) = 0.011s）大致为 Nginx 重试调度及协议开销
结合其他变量做交叉验证
单看这两个变量还不够，建议搭配以下变量辅助判断：
- $ssl_handshake_time（需开启 ssl_preread on 或使用 OpenResty）→ 判断 TLS 是否拖慢首字节
- $time_iso8601 + $msec → 精确对齐日志时间戳，排查系统负载波动
- $upstream_addr → 确认是否某台 upstream 实例异常拖慢整体
- $upstream_status → 区分是 200 还是 5xx/4xx 导致的长耗时（某些错误路径可能绕过缓存或触发降级逻辑）
