核心是启用$request_time和$upstream_response_time变量，通过自定义log_format输出可解析数值，放在日志末尾便于提取；两者差值可定位瓶颈：均大则后端问题，$request_time显著更大则nginx或客户端问题，后者为空则静态处理或模块性能问题。
要在 Nginx 访问日志中记录请求耗时用于性能分析，核心是启用 $request_time 变量并合理搭配 $upstream_response_time，通过自定义日志格式输出可解析、可对比的数值字段。
配置带耗时的日志格式
在 http 块中定义一个新格式（不要覆盖默认 combined），确保包含关键时间变量：
-
$request_time：Nginx 处理整个请求的总耗时（秒，精度毫秒），从收到第一个字节到发完最后一个字节 -
$upstream_response_time：仅在使用proxy_pass或fastcgi_pass时有效，表示后端服务返回全部响应的时间 - 建议把这两个变量放在日志末尾，方便用
awk '{print $NF}'快速提取
示例配置：
按需启用日志并指定路径
在 server 或具体 location 块中绑定该格式：
- 全局记录：在
server块中写access_log /var/log/nginx/access.log timed; - 只记录 PHP 接口：在
location ~ \.php$内单独配置，避免静态资源干扰 - 路径需确保 Nginx 进程有写权限（如
www-data用户）
区分瓶颈类型，靠两个时间差判断
日志中每行末尾类似 0.215 0.212 的数值对，可用于快速归因：
- 两者都大（如 >1s）→ 后端逻辑或数据库慢，优先查应用层日志
- $request_time 明显大于 $upstream_response_time（差值 >0.3s）→ Nginx 层开销高，可能是 SSL、大文件上传、gzip、复杂 rewrite 或客户端弱网
- $upstream_response_time 为空或 “-” 但 $request_time 大 → 请求未走代理，问题可能在静态文件 I/O、磁盘速度或 Nginx 模块本身
用命令行快速分析特定接口耗时
日志写入后，可通过简单命令定位慢请求：
- 提取
/api/order接口所有耗时：awk '$7 ~ /^\/api\/order($|\?)/ {print $NF}' /var/log/nginx/access.log - 查看超过 2 秒的请求完整日志：
awk '$7 ~ /^\/api\/order/ && $NF > 2' /var/log/nginx/access.log - 统计平均耗时（需
datamash）：awk '$7 ~ /^\/api\/order/ {print $NF}' access.log | datamash mean 1
