Nginx 高级度量：如何通过配置日志记录路径流量与响应时间的比值动态估算客户端物理带宽

Nginx无法测量客户端物理带宽，但可通过$ body_bytes_sent / $ request_time计算服务端视角的下行吞吐率（B/s），作为识别慢速客户端、网络瓶颈或异常行为的相对效率指标，需结合路径分离、日志解析与分位数分析使用。

Nginx 本身不直接提供“客户端物理带宽”的测量能力，也无法通过日志变量精确反推真实网络带宽（受 TCP 拥塞控制、缓冲区、中间设备、丢包重传等影响）。但你可以基于路径流量与响应时间的比值，构建一个近似、可观测、可用于横向对比的带宽估算指标，用于识别慢速客户端、异常下载行为或网络瓶颈趋势。

这个估算不是绝对带宽值（单位 Mbps），而是相对吞吐效率指标：
估算吞吐率 = $body_bytes_sent / $request_time（单位：字节/秒）

它反映的是“该次请求中，Nginx 实际向客户端有效发送数据的平均速率”，可作为客户端侧带宽受限或网络质量差的强提示信号。

---

一、配置日志记录必要变量

必须在 log_format 中显式包含两个核心字段：

• $body_bytes_sent：实际发送给客户端的响应体字节数（不含响应头）
• $request_time：完整请求耗时（秒，精度毫秒），从接收首字节到发送末字节

示例配置（加入 http 块）：

log_format bandwidth_log   '$remote_addr [$time_local] "$request" '  '$status $body_bytes_sent $request_time '  '$upstream_response_time $http_user_agent';access_log /var/log/nginx/bandwidth.log bandwidth_log;

⚠️ 注意：$request_time 包含上传时间、处理延迟、上游等待、发送耗时；若只关心“下行吞吐”，且响应体较大（如文件下载），该比值更具参考性。对小响应（如 JSON API），比值易受固定开销干扰，需过滤。

---

二、按路径（location）分离统计，聚焦高流量接口

为避免混杂，建议对重点路径（如 /download/, /api/v1/report）单独打点：

location ^~ /download/ {    access_log /var/log/nginx/download-bandwidth.log bandwidth_log;}location ^~ /api/v1/stream {    access_log /var/log/nginx/stream-bandwidth.log bandwidth_log;}

这样可分别计算各业务路径的平均吞吐表现，识别是否某类资源普遍下发缓慢。

---

三、用日志解析动态估算并识别异常低速请求

使用 awk 快速提取并计算单条请求的吞吐率（B/s），再转换为 KB/s 或 MB/s：

# 提取 download 日志中吞吐率 > 0 且 request_time > 0.1s 的请求，并转为 KB/sawk '$6 > 0 && $7 > 0.1 { printf "%.1f KB/s (%.3fs, %d B) — %sn", $6/$7/1024, $7, $6, $10 }'   /var/log/nginx/download-bandwidth.log | head -20

常见判断阈值参考（需结合业务调整）：

• < 50 KB/s：疑似移动弱网、Wi-Fi 信号差、或客户端限速
• < 5 KB/s 且 request_time > 5s：高度可疑（如后台被挂起、TCP 失连重试）
• 同一 IP 短期内大量 < 10 KB/s 请求：可能为爬虫或异常下载工具

---

四、聚合分析：小时级平均吞吐 + 分位数分布

单纯看均值会掩盖长尾。推荐用以下方式做聚合：

# 按小时统计平均吞吐（KB/s）、P95 吞吐、最低吞吐、请求数awk -F'[][]' '{    hour = substr($2, 1, 13)    if ($6 > 0 && $7 > 0.05) {        t = $6/$7/1024        sum[hour] += t        cnt[hour]++        vals[hour][++n[hour]] = t    }}END {    for (h in sum) {        printf "%st%.1ft%.1ft%.1ft%dn", h, sum[h]/cnt[h],           asort(vals[h], sorted), sorted[int(n[h]*0.95)], cnt[h]    }}' /var/log/nginx/download-bandwidth.log | sort

输出示例：

10/Jun/2026:14     124.3    312.0    8.2    2417

→ 该小时平均 124 KB/s，P95 达 312 KB/s，但最低仅 8.2 KB/s，说明存在显著拖慢样本。

---

补充说明：为什么不能替代真实带宽测试？

• Nginx 只知道“自己发出了多少、花了多久”，不知道客户端是否卡在接收缓冲、是否丢包重传、是否启用了 HTTP/2 流控
• $body_bytes_sent 不等于 Content-Length（如 chunked 编码、gzip 后长度变化）
• 客户端并发连接数、TCP 窗口大小、RTT 等完全不可见

所以它本质是服务端视角的下行交付效率指标，适合用于：

• 运维侧快速筛查慢响应路径
• 产品侧识别下载失败高发的网络环境
• 安全侧发现异常低速持续拉取行为（如隐蔽 C2 通信）

不复杂但容易忽略——真正有用的是把 bytes/time 当作一个可排序、可分组、可告警的业务信号，而不是执着于换算成 Mbps。