Nginx 访问日志怎么看慢请求？请求耗时与上游耗时对照
访问日志不仅用于统计请求数量，也能帮助回答“同一个页面为什么偶尔很慢”。本文适用于受维护的 Nginx HTTP 代理站点，示例可用于 Ubuntu 24.04 的常见安装。这里增加的是诊断信息，不会自动找出所有慢请求根因。
先选一个能重复观察的问题
记录慢请求的路径、发生时间和用户实际操作，区分首次页面加载、接口响应和大文件下载。它们都可能表现为等待，但耗时来源不同。先选择只读页面或已确认不会产生副作用的测试请求，不要为了排查反复提交支付或创建任务。
查看现有访问日志是否包含总耗时和上游耗时。若已经具备这些字段，先分析现有数据；不要立即更换整套日志格式，避免影响采集程序。还要确认服务器与应用时间同步，跨服务日志才能按相近时间关联。
在独立日志中添加必要字段
下面的 log_format 放在 http 上下文，access_log 放在目标站点 server 块内。先确认自定义格式名称和文件路径没有被使用：
# http 上下文
log_format timing '$time_iso8601 method=$request_method uri=$uri '
'status=$status rt=$request_time '
'uct=$upstream_connect_time urt=$upstream_response_time '
'upstream=$upstream_addr';
# 目标 server 上下文
access_log /var/log/nginx/site-timing.log timing;
示例使用不带查询参数的 $uri，减少令牌等敏感内容落日志的机会，但路径本身仍可能包含用户标识，仍需检查数据内容。不同字段的适用阶段可查Nginx 日志模块文档。
如果新增站点级 access_log 会覆盖原先继承的日志安排，应一并核对监控和审计是否仍需要旧日志。不要把诊断输出写到网页目录，也不要开启无边界的详细请求体记录。
用时间关系提出假设
总请求时间明显较长而上游时间较短时，可以继续调查客户端上传、下载速度、代理缓冲或其他处理环节；上游耗时本身就高时，重点对照应用、数据库和外部接口。这里得到的是排查方向，不是仅凭一个字段就能认定的结论。
建立上游连接慢与上游处理慢也不同。前者需要检查连接路径、连接积压和上游接入状态；后者更需要关注查询、锁等待和任务执行。没有访问上游的静态请求，相关字段可能为空或显示占位符，不能把它当成统计异常。
发生多次上游尝试时，变量可能包含多个值。应保留完整字段并结合失败信息解释，而不是只取第一个数字。Nginx 上游变量文档
把代理日志与应用证据关联
在相同时段收集少量正常请求与慢请求，按同一路径比较，不要把小图片和报表导出的耗时混在一起。若系统已有请求标识，可以按既有可信生成方式记录它，让代理与应用日志对应；不能用未经限制的访客输入充当可靠审计标识。
应用显示数据库耗时很高时，再看慢查询或锁等待；应用很快返回而访客很慢时，继续检查资源体积和网络。平均值可能掩盖少量极慢请求，应同时关注较慢请求的分布与业务影响，避免只追求一个漂亮的平均数。
验证配置并控制日志成本
修改前备份相关配置，执行 sudo nginx -t，通过后重新加载并发送一次测试请求。确认新增日志确实出现、字段可解析，既有采集没有中断，再观察原来的慢请求。语法通过只说明配置可接受，不代表日志已写入预期位置。
诊断日志需要轮转、保留周期和访问权限。排查结束后保留长期有用的字段，撤回临时增加的内容；若日志增长影响磁盘，先恢复原配置并处理留存安排。记录最后确认的瓶颈与证据，避免下次又把所有慢访问归咎于服务器配置。