$requested_time需与上游时间字段组合分析才能定位瓶颈，必须搭配$upstream_connect_time、$upstream_header_time、$upstream_response_time，并补充$request_id、$upstream_addr等字段实现全链路可追溯。
直接在 log_format 中记录 $request_time 并不足以定位瓶颈，关键是要让它和上游耗时、网络层耗时、状态码等字段组合使用，形成可比对的时间链条。毫秒级精度必须显式启用，且需结合上下文字段交叉判断。
确保 $request_time 输出毫秒精度
Nginx 默认输出 $request_time 是秒单位，小数点后三位（如 0.123），实际已含毫秒信息，但易被日志解析工具截断或误读。无需额外模块，只需确认：
- Nginx 版本 ≥ 1.9.1（主流发行版均满足）
- 日志格式中不加额外格式化（如
int($request_time*1000)会丢失小数，不可取） - 写入日志时保持原样，例如：
$request_time→ 记录为0.123，即 123ms
必须搭配的上游时间变量
$request_time 单独存在没有诊断价值。它必须与以下三个 upstream 时间字段并列记录，才能拆解延迟归属：
-
$upstream_connect_time：TCP 连接建立耗时（含 SSL 握手） -
$upstream_header_time：从连接完成到收到响应首行的时间（含请求发送 + 后端处理 + 响应头返回） -
$upstream_response_time：从连接完成到收完全部响应体的时间（即后端完整处理+传输耗时）
典型配置示例：
log_format full_trace'[$time_local] $remote_addr "$request" '
'$status $body_bytes_sent '
'$request_time $upstream_connect_time $upstream_header_time $upstream_response_time '
'$upstream_addr $upstream_status $http_x_request_id';
用差值快速圈定瓶颈环节
通过字段间差值，可即时判断延迟发生在哪一层：
-
网络连接层瓶颈：若
$upstream_connect_time > 50ms且反复出现 → 检查后端实例网络、防火墙、DNS 或端口连通性 -
TLS/转发层瓶颈：若
$upstream_header_time − $upstream_connect_time > 200ms→ 关注 Nginx SSL 配置、proxy_buffering、大 body 解析开销 -
后端业务层瓶颈：若
$upstream_response_time − $upstream_header_time显著（如 > 300ms）→ 表明响应体较大或后端流式生成慢；若$upstream_header_time本身高且$upstream_response_time ≈ $upstream_header_time→ 后端逻辑处理慢（如 DB 查询、同步调用） -
客户端或链路层瓶颈：若
$request_time − $upstream_response_time > 300ms→ 排查客户端弱网、Nginx gzip/sub_filter 耗时、或 proxy_buffering off 导致阻塞
增强可追溯性的必备字段
仅有时序字段仍难归因到具体服务或请求。建议在 log_format 中补充：
-
$http_x_request_id或$request_id：串联跨服务日志，定位单次全链路耗时 -
$upstream_addr：明确是哪台后端实例响应慢（如10.0.1.22:8080） -
$upstream_status：区分是 200 下的真实慢，还是 504/502 等超时错误（此时$upstream_response_time可能接近 timeout 值，不反映真实性能） -
$http_user_agent和$http_referer：辅助识别是否特定终端或来源触发慢请求
