$request_length配合状态码是拦截大请求最轻量可靠的网关手段，真实反映原始请求字节数，不依赖后端，需在日志中显式记录二者以识别攻击、实现自动拦截与监控。
直接用 $request_length 配合状态码分析，是拦截大请求最轻量、最可靠的网关层手段——它在 Nginx 完整接收请求后立即可用，数值真实反映客户端发送的原始字节数（含请求行、所有 header 和 body），不依赖后端响应，也不受压缩或伪造 header 干扰。
在日志中同时记录 request_length 和状态码
默认日志格式不包含 $request_length，必须显式定义并确保状态码字段（$status）与之同列：
- 推荐配置示例（放在
http块中）：
log_format req_status '$remote_addr [$time_local] "$request" $status $body_bytes_sent $request_length $request_time';
access_log /var/log/nginx/access.log req_status; - 这样每条日志末尾会带类似
200 142 8372192 0.423的字段：分别对应状态码、响应体字节数、请求总长（字节）、总耗时（秒） - 关键点：保留
$status是为了区分拦截动作是否生效——比如大量413表明client_max_body_size在起作用；而200却伴随超大$request_length，就说明请求已穿透到后端，需进一步排查
用状态码 + request_length 组合识别真实攻击行为
单看长度易误报，结合状态码才能判断是否构成威胁：
-
高频 413 + request_length 远超业务上限：说明攻击者在试探或触发 Nginx 自身限制，例如日志中出现
POST /login HTTP/1.1 413 156 12485760 0.001（12MB 请求被拒），可确认为恶意填充 -
200/500 + request_length 极高但 $body_bytes_sent 很小：如
200 42 9876543 3.210，表示后端可能只返回了错误页或空响应，实际未处理业务逻辑，极可能是上传接口被滥用于发包 - 400/499 + request_length 异常大：常见于畸形请求头或超长 URL，Nginx 在解析阶段就拒绝，这类请求虽未进转发流程，但已消耗 worker 资源，也需关注
基于该组合实现自动拦截与日志标记
不单靠日志告警，还可联动 Nginx 原生命令做实时干预：
- 用
map提取高危请求特征：
map $request_length $is_large_req {
~^[5-9][0-9]{5,}$ 1; # ≥500KB
default 0;
} - 配合限流或拦截：
if ($is_large_req) { return 413; }
或更稳妥地：
limit_req zone=large_block burst=2 nodelay; - 拦截后仍要记录：确保
access_log在location或server块中启用，且日志格式含$status和$request_length，这样每次拦截都会留下可追溯的证据链
日常监控建议
把 $request_length 和 $status 当作结构化字段使用，而非文本扫描：
- 用
awk '$10 > 5000000 && $6 == 413 {print}' /var/log/nginx/access.log快速统计被限的大请求次数 - 在 Grafana + Loki 中对
request_length > 2_000_000且status in (200, 400, 413)设置 P95 聚合告警 - 定期检查
413请求中$request_length的分布：若多数集中在 1MB–2MB，说明当前client_max_body_size设置合理；若大量出现在 10MB+，则可能有攻击者绕过前端校验直连网关
