计算网站平均响应延迟需区分用户感知延迟（$request_time）和后端真实延迟（$upstream_response_time或$upstream_header_time），并依目标选择对应变量、配置精准日志格式、用外部工具聚合统计，同时关注p95等指标避免平均值失真。
计算网站的平均响应延迟，关键不是用 $request_time 粗略估算，而是要区分“用户感知延迟”和“后端真实延迟”，并根据目标选择对应变量和统计方式。
明确你要监控的是哪一类延迟
不同场景下，“响应延迟”的含义不同，需先锁定目标：
-
用户端整体体验延迟：用
$request_time（单位秒），它包含客户端上传、Nginx 处理、后端响应、响应下发全过程。适合看页面加载慢不慢、API 总耗时高不高。 -
后端服务真实处理延迟：用
$upstream_response_time，只记录 Nginx 与后端之间通信耗时（从发起到收到响应头）。适合排查是后端慢了，还是网络或 Nginx 自身拖慢了。 -
后端首字节返回延迟（TTFB）：用
$upstream_header_time，精度更高，能反映后端应用启动、数据库查询等前置环节效率。
在日志中可靠采集原始数据
所有统计都依赖高质量日志字段。必须在 http 块中定义带目标变量的日志格式，并在 server 或 location 中启用：
示例（记录后端真实延迟）：
log_format upstream_log '$remote_addr [$time_local] "$request" $status '
'$body_bytes_sent "$upstream_addr" $upstream_response_time '
'$request_time';
注意：
-
$upstream_response_time在重试时为逗号分隔字符串（如"0.021, 0.145"），失败时对应位置为-；后续分析需清洗（推荐取第一个有效值）。 - 务必同时记录
$upstream_addr，否则无法区分是哪台后端变慢。 - 避免把所有 upstream 混在一个日志流里，可为不同集群单独配置
access_log路径。
用外部工具做聚合统计（Nginx 不直接算平均值）
Nginx 本身不提供运行时平均值计算功能，需将日志导入支持聚合的系统：
-
Prometheus + nginx-prometheus-exporter：开启
--enable-upstream-stats后，指标nginx_upstream_response_msecs_sum / nginx_upstream_response_msecs_count即为各节点平均毫秒级响应时间；Grafana 中用rate(...[5m])滑动窗口更稳定。 -
Loki + Grafana：用 LogQL 查询，例如：
sum by (addr) (avg_over_time({job="nginx"} |~ `upstream_addr` | regexp `"(?P<addr>[^"]+)" (?P<rt>\d+\.\d+)` | unwrap rt [5m]))</rt></addr> -
简单脚本（临时排查）：用
awk提取有效数值并求平均：awk '{if($NF != "-" && $NF > 0) {sum += $NF; cnt++}} END {print "avg:", sum/cnt}' /var/log/nginx/upstream.log
快速验证单次请求的真实路径与耗时
不依赖日志解析，适合压测抽样或故障初判：
- 在测试 location 中添加：
add_header X-Upstream-Addr $upstream_addr;add_header X-Upstream-Time $upstream_response_time; - 执行：
curl -I https://example.com/test | grep -E "(X-Upstream-Addr|X-Upstream-Time)"
可立即看到本次请求落到哪台后端、耗时多少。
不复杂但容易忽略：平均值掩盖异常，建议同步关注 P95、标准差或环比变化率——比如某 IP 的 $upstream_response_time 5 分钟均值突增 300%，比单纯看“平均 80ms”更能暴露负载注入或节点退化。
