$request_time 是 Nginx 记录请求处理全流程内部耗时的变量（单位秒，精度毫秒），从请求头读完到响应写入发送缓冲区为止，不包含 TCP/TLS 握手、慢速上传、网络传输及浏览器渲染等客户端侧延迟。
$request_time 是 Nginx 内置的变量，用于记录一次 HTTP 请求从接收到响应发送完毕所经历的**总时间（单位：秒，精度为毫秒）**。它不是从客户端发包开始算，而是从 Nginx 完整读取完请求头（即请求已就绪可处理）起，到 Nginx 将最后一批响应数据写入系统发送缓冲区（send buffer）并返回成功为止。
为什么 $request_time 不等于“客户端感知的总延迟”？
它不包含以下三类耗时：
- TCP 连接建立时间（如三次握手、TLS 握手）
- 请求体（request body）接收过程中的慢速上传（例如大文件分块上传，Nginx 默认会边收边处理，但 $request_time 从 header 收完才开始计）
- 响应数据在内核 socket 缓冲区排队、经网络传输到客户端、浏览器解析渲染的时间
换句话说，$request_time 反映的是 Nginx **自身工作流的内部耗时**，是服务端性能分析的关键指标，而非端到端用户体验指标。
如何在日志中正确使用 $request_time
需在 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';
- $request_time 输出为浮点数（如 0.023 表示 23 毫秒），默认保留三位小数；可通过 log_format 配合 $request_time 的修饰符（如 $request_time_ms 获取整数毫秒值）调整精度
- 注意：该变量仅在请求完成（包括错误终止）后才写入日志，不会出现在访问中途断连未完成的日志行中
$request_time 和 $upstream_response_time 的核心区别
两者常一起出现，但职责不同：
- $request_time：Nginx 全流程耗时（含读请求头、执行 location 匹配、变量展开、rewrite、access 日志、proxy_pass 转发、等待 upstream 响应、组织响应头/体、写响应等）
- $upstream_response_time：仅统计 Nginx 向 upstream（如后端 PHP/FastCGI、Java 服务）发起请求后，到收到第一个字节响应之间的时间（多个 upstream 可用逗号分隔，如 0.012, 0.008）
- 若 $request_time 显著大于 $upstream_response_time，说明瓶颈可能在 Nginx 本机（如 rewrite 规则复杂、大量 if 判断、日志写入慢、SSL 处理开销高、或 proxy_buffer 配置不合理导致阻塞）
调试高 $request_time 的实用建议
当发现某类请求 $request_time 普遍偏高，可按如下顺序排查：
- 对比同请求的 $upstream_response_time：若二者接近，问题大概率在后端服务；若 $request_time 远高于 upstream 耗时，聚焦 Nginx 配置与环境
- 检查是否启用了耗时模块：如 realip（IP 伪造校验）、geoip2（地理库查询）、lua 脚本（尤其是阻塞式调用）、ssl_verify_client（双向证书验证）
- 确认日志写入方式：避免同步写磁盘（access_log /path/log main flush=1s 可缓解）
- 观察是否存在大量 499（客户端主动断连）状态码：此时 $request_time 仍会记录，但不代表服务端处理慢，而是用户侧行为
