$request_time 是 Nginx 端到端请求耗时指标，涵盖上传、后端处理及响应发送全过程；需结合 $upstream_response_time 归因分析，并联动状态码、方法、UA 等字段定位根因。
$request_time 是 Nginx 日志中反映请求端到端耗时的核心指标，它从接收客户端第一个字节开始计时，到发送完响应最后一个字节结束。这个时间覆盖了网络传输、Nginx 自身处理、后端服务响应及响应返回全过程，是判断“用户到底等了多久”的最直接依据。
理解 $request_time 的真实构成
它不是单纯的后端处理时间，而是三段耗时之和：
- 客户端上传数据到 Nginx 的时间（如大文件 POST、弱网上传）
- Nginx 转发请求 + 等待后端响应 + 接收响应数据的时间（这部分与 $upstream_response_time 高度相关）
- Nginx 将响应内容压缩（如 gzip）、过滤（如 sub_filter）、缓冲或流式发送给客户端的时间
用日志快速识别延迟分布特征
在 access.log 中启用 log_format 记录该字段，例如：
之后可执行以下分析：
- 查最慢的 10 个请求：
awk '{print $NF, $0}' access.log | sort -k1nr | head -10（假设 $request_time 是最后一列） - 统计超 1 秒的请求数并按接口聚合：
awk '$NF > 1 {print $(NF-5)}' access.log | sort | uniq -c | sort -nr（需根据实际字段位置调整） - 做分桶统计看长尾：用脚本将 $request_time 划分为 0–100ms、100–500ms、500–1000ms、1s+ 四档，观察 P95/P99 是否被少量高延迟请求显著拉高
结合 $upstream_response_time 做归因判断
单看 $request_time 只能知道“慢”，必须对比 $upstream_response_time 才能定位“谁慢”：
- 两者都高（如 request_time=2.3s，upstream_time=2.2s）→ 延迟主要在后端服务，应查数据库、远程调用或业务逻辑
- $request_time 高但 $upstream_response_time 很低（如 1.8s vs 0.02s）→ 问题出在 Nginx 或客户端侧：可能是大响应体未启用 proxy_buffering、启用了耗 CPU 的模块（gzip/sub_filter）、或客户端下载慢/中断重传
- $upstream_response_time 为 “-” 或极小值（如 0.000），但 $request_time 很高 → 请求根本没发出去，常见于 upstream 连接失败、DNS 解析超时、或后端不可达
关联其他字段缩小问题范围
延迟背后常隐藏具体场景，需联动分析：
- 若高 $request_time 多出现在特定状态码下：5xx + 高 upstream_time → 后端崩溃或超时；206（分片下载）+ 高 request_time → 客户端断点续传行为
- 若集中在某类请求方法或路径：POST /upload + 高 request_time → 检查上传大小限制、client_max_body_size、读取超时
- 若只发生在特定客户端 User-Agent 或 Referer → 可能是爬虫、旧版浏览器或异常工具导致连接不稳定
