Nginx作为最常用的反向代理和Web服务器，每天记录着海量访问日志。大多数团队只拿它做流量统计和故障排查，却很少意识到日志里那些时间字段和字节数字段，可以拼出一幅客户端网络质量的真实画像。当有用户反馈页面加载缓慢时，运维人员往往需要在服务端性能和用户网络之间做判断，而Nginx日志恰好提供了低成本的数据来源，不需要在前端埋点，也不需要额外的拨测系统，就能得到接近真实的网络传输耗时。
本文从日志字段配置入手，介绍如何利用时间差值法估算网络传输耗时，再给出具体的分析脚本和常见误判场景，帮助你把访问日志变成一个持续运行的网络质量监控系统。
一、配置日志格式：采集评估所需的关键字段
Nginx默认的combined日志格式只包含基础信息，缺少时间类变量，无法做网络质量分析。要做评估，首先需要在nginx.conf中自定义日志格式，把请求耗时、上游耗时、请求和响应字节数都记录下来。
log_format net_quality '$remote_addr - $status '
'"$request" '
'req_time=$request_time '
'upstream_time=$upstream_response_time '
'body_bytes=$body_bytes_sent '
'req_bytes=$request_length '
'http_ver=$server_protocol '
'ua="$http_user_agent"';
server {
access_log /var/log/nginx/net_quality.log net_quality;
}这段配置中有几个字段是网络质量评估的核心。$request_time记录的是从收到客户端第一个字节到发送完响应的完整耗时，包括读取请求体、上游处理和响应传输三个阶段。$upstream_response_time是Nginx转发给后端并收到完整响应的时间，二者的差值主要消耗在客户端与Nginx之间的网络传输上。$body_bytes_sent是发送给客户端的响应体字节数，结合传输耗时可以粗略计算吞吐速率。
另外建议加上$time_iso8601或$time_local方便按时间维度聚合，加上$http_range可以识别断点续传请求，这类请求的耗时分段特性会干扰统计，需要在分析时过滤掉。
二、差值法原理：如何区分服务端耗时与网络传输耗时
评估客户端网络质量的核心思路是分解request_time。整个请求时间线可以简化为三个阶段：客户端发送请求（受上行带宽影响）、Nginx与上游交互（upstream_response_time）、响应回传客户端（受下行带宽影响）。当一个请求没有命中代理、直接由Nginx返回静态文件时，upstream_response_time为空，此时差值法退化为观察request_time与响应大小的关系。
具体的计算公式是：网络传输耗时约等于request_time减去upstream_response_time，再减去读取请求体的时间。由于Nginx没有单独暴露读取请求体的耗时，对于GET请求来说请求体几乎为零，可以忽略不计；对于大文件上传的POST请求，这个近似就不准确了，需要单独归类分析。
举个例子：某次请求request_time为2.5秒，upstream_response_time为0.3秒，响应体大小为500KB，那么网络侧耗时约2.2秒，下行速率大约227KB/s。如果同一时刻其他用户的同接口请求传输耗时只有0.2秒，基本可以判断这位用户的下行链路存在问题，可能是弱网环境、运营商劫持或者跨地域访问导致的。
三、实战分析：用awk脚本做慢请求聚合
有了日志之后，下一步是做聚合分析。最直接的方式是写一个awk脚本，从日志中提取网络耗时，按URI或客户端网段分组，计算平均值和分位值。
#!/bin/bash
# 分析网络传输耗时 TOP URI
# net_time = request_time - upstream_response_time
awk '{
req_time = 0; up_time = 0;
for (i = 1; i <= NF; i++) {
if ($i ~ /^req_time=/) { split($i, a, "="); req_time = a[2] + 0 }
if ($i ~ /^upstream_time=/) { split($i, b, "="); up_time = b[2] + 0 }
if ($i ~ /^body_bytes=/) { split($i, c, "="); bytes = c[2] + 0 }
}
net_time = req_time - up_time;
if (net_time < 0) net_time = 0;
if (bytes > 0) {
speed = bytes / 1024 / net_time; # KB/s
uri = $4;
gsub(/\?.*/, "", uri);
sum[uri] += net_time;
cnt[uri]++;
}
}
END {
for (u in sum) printf "%-50s avg_net=%.3fs count=%d\n", u, sum[u]/cnt[u], cnt[u];
}' /var/log/nginx/net_quality.log | sort -k2 -t= -nr | head -20这个脚本输出的平均网络耗时可以快速定位哪些接口受网络影响最大。需要注意的是，平均值的参考价值有限，一条慢请求可能被大量快请求稀释掉，更严谨的做法是计算分位数。如果日志量不大，可以把字段提取后导入Python用numpy的percentile函数计算P90、P95，弱网用户的特征通常体现在长尾分位上。
按$remote_addr的前两段做网段聚合也是常用手段。如果发现某个运营商网段的网络耗时系统性偏高，而其他网段正常，问题大概率出在链路或者该运营商的互联互通上，这时应该考虑接入CDN或者增加就近接入点，而不是优化服务端代码。
四、常见误判与干扰因素
差值法虽然简单，但有几个容易被忽视的干扰因素。第一是Keepalive长连接，客户端复用连接时省去了TCP握手时间，而新建连接的请求会多出握手和慢启动开销，两者混在一起统计会让数据抖动很大，建议结合$connection_requests字段区分首请求和复用请求。
第二是客户端主动断开。用户等不及点了关闭按钮，Nginx仍会记录request_time直到写入失败，这类请求的状态码可能是499，其耗时不代表真实网络速度，应从统计中剔除，或者单独作为用户流失信号分析。
第三是响应体大小差异。不能直接比较不同URI的网络耗时，小请求的耗时主要是RTT（往返延迟），大请求的耗时主要是带宽瓶颈。把响应字节数纳入计算，观察耗时与字节数的比值是否异常，才能区分是延迟高还是带宽低。延迟高的用户适合做连接复用和减少请求数优化，带宽低的用户则需要压缩、瘦身资源。
五、从评估到优化：针对弱网用户的行动建议
当日志持续显示某类用户网络传输耗时长，可以按延迟型和带宽型分别施策。对延迟型用户，开启HTTP/2减少连接数、配置keepalive_timeout鼓励连接复用、对静态资源设置长缓存减少往返次数，都是有效手段。Nginx中启用HTTP/2的配置很简单：
server {
listen 443 ssl http2;
keepalive_timeout 65s;
keepalive_requests 1000;
gzip on;
gzip_min_length 1k;
gzip_comp_level 5;
}对带宽型用户，重点是减小传输体积：开启gzip或brotli压缩、把图片转成WebP格式、对JS和CSS做代码分割，让首屏只加载必要资源。日志中的$http_accept_encoding字段还能帮你确认用户浏览器是否支持压缩，从而评估压缩的实际覆盖率。
最后建议把这套指标接入现有的监控体系。用Filebeat或Vector采集日志，写入Elasticsearch或ClickHouse，按分钟粒度输出网络耗时分位图。当某个地区或某个运营商的网络耗时P95突然抬升时及时告警，你就拥有了比用户投诉更早的感知能力，把网络质量评估从一个事后分析动作，变成一个常态化的运行时监控手段。
Nginx日志分析网络质量评估request_time修改时间：2026-09-07 10:22:57