应使用 $request_time 变量记录完整请求耗时，它涵盖从接收首字节到发送末字节的全过程（含网络、处理、上游等待等），需在 log_format 中配置并 reload 生效；注意区分 $upstream_response_time 等变量以定位瓶颈。
要在 Nginx 中记录请求处理完成后的响应时长，核心是正确使用 $request_time 变量——它表示从接收到客户端第一个字节开始，到把最后一个响应字节发送给客户端为止的总耗时（单位：秒，精度为毫秒），涵盖网络传输、Nginx 内部处理、上游等待与响应返回全过程。
确认日志格式中已启用 $request_time
编辑 nginx.conf 文件，在 http 块内检查或定义 log_format，确保包含该变量：
- 典型配置示例：
log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $request_time';
- 若使用自定义格式名（如
mylog），需同步更新access_log指令中的格式引用 - 修改后必须执行
nginx -t && nginx -s reload生效
区分 $request_time 和 $upstream_response_time
两者常被混淆，但用途不同：
- $request_time：整条请求链路耗时，含客户端上传时间、Nginx 排队、DNS/SSL 开销、上游响应、Nginx 发送响应等
- $upstream_response_time：仅限 proxy_pass / fastcgi_pass 等代理场景，指 Nginx 向后端发请求到收到响应头的时间（不包括上传和发送阶段）
- 对比二者可快速判断瓶颈：若 $request_time 显著大于 $upstream_response_time，问题可能在客户端网络或 Nginx 自身；若二者接近，瓶颈大概率在后端服务
注意超时与异常情况下的取值
以下情形会导致 $request_time 仍有效，但需结合状态码综合分析：
- 客户端主动断连（如用户关闭页面）：$request_time 记录实际耗时，但响应状态码可能是 499
- Nginx 超时中断（如
proxy_read_timeout触发）：$request_time 包含等待超时的全部时间，状态码通常为 504 - 后端返回错误（如 502/503）：$request_time 正常记录，可用于分析失败请求的真实耗时分布
配合其他变量提升排查效率
单看 $request_time 不足以定位根因，建议组合记录：
-
$upstream_response_time：判断后端是否拖慢整体响应 -
$upstream_connect_time：排查连接建立阶段延迟（DNS、TCP 握手、TLS 协商） -
$msec：记录日志写入的精确时间戳（秒级+毫秒），便于对齐上下游日志 -
$status和$upstream_status：区分是 Nginx 层错误还是后端返回错误
