$request_length 是观测不规则大体积请求对 Nginx worker 吞吐损耗最准、最及时的方式，因其在请求完整接收后即刻定值，真实反映原始字节数（含请求行、header、body），不依赖后端响应且不受压缩或伪造干扰。
直接看 $request_length 是观测不规则大体积请求对 Nginx worker 吞吐损耗最准、最及时的方式——它在请求完整接收后即刻定值，真实反映该连接实际承载的原始字节数（含请求行、全部 header、整个 body），不依赖后端响应，也不受压缩或伪造字段干扰。一旦数值显著偏离业务常态，就说明该请求正在持续占用 worker 连接与内存缓冲区，拖慢整体吞吐。
为什么 $request_length 能精准反映 worker 吞吐损耗
worker 的并发能力受限于连接数与内存缓冲。当客户端发送不规则大报文（如 Slow Body、Gzip 炸弹、巨量 header 填充）时：
- Nginx 必须收完全部字节才进入后续处理流程（转发或响应），此阶段持续占用一个 worker connection
- 每个请求分配的 buffer（如 client_header_buffer_size、client_body_buffer_size）可能被撑满甚至触发临时文件写入，加剧 I/O 开销
- 若大量此类请求并发抵达，worker 连接池迅速耗尽，新请求排队等待，表现为 request_time 骤升、upstream_response_time 为 “-”、status=499/504 比例上升
- 而 $request_length 正是这个“占用时长 × 数据量”的客观量化结果，比单纯看请求数或平均响应时间更早暴露瓶颈
配置日志以捕获关键上下文指标
默认 combined 格式不含 $request_length，需自定义 log_format 并确保包含以下字段：
- $request_length：核心指标，单位字节，必须显式写入且位置固定（建议第11或12列）
- $request_time：从接受首字节到接收完成耗时，判断是否“发得慢”
- $upstream_response_time：若为 “-” 或极小（如 < 0.01s），说明请求未出站，卡在 Nginx 接收层
- $status 和 $body_bytes_sent：区分是被拦截（413）、解析失败（400）、还是穿透至后端但无有效响应（200 + 极小 body）
- $http_x_forwarded_for：保留真实源 IP，避免代理链失真
示例配置：
log_format worker_load '$remote_addr $http_x_forwarded_for [$time_local] "$request" $status $body_bytes_sent $request_length $request_time $upstream_response_time "$http_user_agent"';access_log /var/log/nginx/access_worker.log worker_load;
用组合阈值识别真实吞吐损耗信号
单一大值不等于损耗，需结合频次、时间窗口与关联字段交叉判定：
- 同一 IP 在 60 秒内出现 ≥ 3 次 $request_length > 2MB 的 POST 请求，且 $upstream_response_time 全为 “-”
- $request_length > 5MB，但 $request_time > 3s 且 $upstream_response_time ≈ 0 → 典型 Slow Body 卡住 worker
- $request_length 与 $content_length 差值 > 500KB → 大量垃圾 header 占用解析资源
- 某 URI 路径（如 /api/submit）的 $request_length P99 值在 5 分钟内突增 300%，而该路径 QPS 未同步增长 → 异常载荷注入
监控与响应闭环建议
把 $request_length 当作吞吐健康度的“输入侧血压计”：
- 接入 Prometheus + Grafana，按分钟聚合 sum($request_length)，绘制入向数据压力趋势图，设置同比/环比突增告警
- 用 awk 或 Loki 查询高频异常请求：
sum by (remote_addr) (count_over_time($request_length > 3000000[1m])) > 2 - 对确认损耗型请求，可在 location 中叠加限流：
limit_req zone=slow_post burst=1 nodelay;，并确保日志记录其 $status 和 $request_length 以便追溯 - 定期比对 $request_length 分布与 client_max_body_size 设置：若大量 413 集中出现在略低于该值处，说明攻击者正试探边界；若 200 请求中存在远超该值的 $request_length，则可能是通过 header 绕过体长限制
