使用 $request_length 过滤恶意超大报文是网关层最轻量可靠的防护手段，需自定义日志格式记录该字段，结合业务设定合理阈值、用 awk 筛查异常，再通过状态码与耗时交叉验证，并配置 limit_req 或 if 实现实时拦截。
直接用 $request_length 过滤恶意超大报文，是保护后端集群最轻量、最可靠的网关层手段——它在 Nginx 完整接收请求（含请求行、全部 Header 和 Body）后立即生效，不依赖后端响应，也不受压缩、编码或解析逻辑干扰，天然适合做第一道防线。
一、必须显式记录 request_length 并补全关键上下文
默认日志格式（如 combined）不包含该变量，需手动定义 log_format：
log_format safe_log '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $request_length $request_time $upstream_response_time $http_x_forwarded_for';
access_log /var/log/nginx/access.log safe_log;
- $request_length 是核心字段，单位为字节，真实反映客户端发来的原始数据总量
- 搭配 $request_time 和 $upstream_response_time，可区分是客户端慢速发包（如 Slow Body），还是后端卡死未响应
- 保留 $http_x_forwarded_for，避免多级代理下丢失真实源 IP
- 建议同时记录 $request_method 和 $content_length，便于后续识别 POST 类攻击与 Header 填充行为
二、设定业务合理的长度阈值并快速筛选异常请求
没有绝对“恶意”，只有明显偏离业务预期的长度。例如：
- 普通 API 接口（如 /login、/search）通常不应超过 100KB；若出现 >500KB 的 POST 请求，大概率是填充攻击
- 文件上传接口允许 20MB，那日志中 $request_length > 25MB 的条目就值得重点排查（说明已触发 Nginx 拦截但原始包仍很大）
- 用 awk 快速筛查： awk '$12 > 524288 && $6 == "POST" {print}' /var/log/nginx/access.log（假设 $request_length 是第12列）
- 按 IP 统计高频超长请求：awk '$12 > 1048576 {ip[$1]++} END {for (i in ip) print i, ip[i]}' | sort -k2 -nr | head -10
三、结合状态码与后端耗时做闭环验证
单看长度不够，要和响应行为交叉验证：
- 若大量请求 status = 413 且 $request_length 接近 client_max_body_size，说明配置过小，需调大（如从默认 1m 改为 20m）
- 若 $request_length 很高（如 >2MB）但 $upstream_response_time ≈ 0，说明请求已收完却没转发出去——典型静态阻塞信号
- 若 $request_length 高 + $body_bytes_sent 极小（如 ，极可能是恶意构造的无效载荷，已绕过体长限制进入业务层
四、在 Nginx 层实现轻量实时拦截
日志分析是事后手段，配合规则才能主动防御：
- 用 map + limit_req 对超长请求限流：
map $request_length $large_req_key { ~^[5-9][0-9]{5,}$binary_remote_addr; default ""; }
limit_req_zone $large_req_key zone=large_block:10m rate=1r/s; - 在 location 中启用：limit_req zone=large_block burst=3 nodelay;
- 更激进做法：用 if 判断并返回 413（仅限简单场景，避免嵌套）：
if ($request_length > 10485760) { return 413; } - 务必同步检查并调优超时参数：client_header_timeout 15; client_body_timeout 30;，防慢速大包长期占位
