$request_time 是客户端感知的全链路耗时，涵盖请求接收、Nginx 处理、转发后端、等待响应及发送响应全过程；$upstream_response_time 仅统计 Nginx 与后端交互时间，不含客户端网络、Nginx 解析等开销。
$request_time 是用户侧感知的完整耗时，从客户端发来第一个字节开始，到 Nginx 把最后一个响应字节发给客户端结束。它覆盖整个链路：接收请求 → Nginx 自身处理（如解析头、匹配 location、gzip 压缩）→ 转发给后端 → 等待后端响应 → 发送响应给客户端。
upstream_response_time 只算后端那一段
$upstream_response_time 仅记录 Nginx 与后端服务之间的交互时间：从 Nginx 向 upstream（如 PHP-FPM、Java 应用）发起连接（或复用连接）开始，到收完后端返回的全部响应数据为止。它不包含客户端上传时间、Nginx 解析开销、SSL 握手、响应体发送延迟等环节。
两者数值关系不是简单大小比较
- 正常情况下 $request_time ≥ $upstream_response_time，但差值意义明确：大差值常说明客户端网络差、上传/下载大文件、Nginx 开启了 sub_filter 或 proxy_buffering off 等高开销配置
- 当两者接近且同时偏高（比如都 >800ms），问题大概率在后端内部：数据库慢查、同步阻塞、GC 暂停、线程池打满等
- 偶尔出现 $upstream_response_time > $request_time（如 0.004s vs 0.002s），是因两者使用不同精度时钟：前者基于 CLOCK_MONOTONIC_COARSE（约 4ms 粒度），后者用更高精度时钟；这不是错误，属低精度计时器固有抖动，分析时应忽略毫秒级倒挂，聚焦 >100ms 的请求
日志里必须正确配置才能拿到有效值
- 要记录 $upstream_response_time，Nginx 配置中必须实际使用了 upstream（如 proxy_pass 或 fastcgi_pass），否则该字段显示为 “-”
- log_format 中需显式加入这两个变量，例如：log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $request_time $upstream_response_time';
- 确保对应 server 或 location 块启用了 access_log 并指定该格式
