$request_length是最有效的攻击识别切入点——它精确反映请求原始字节数（含请求行、Header、Body），需显式加入log_format，结合阈值筛选、client_max_body_size验证及高危路径告警形成闭环防御。
直接看 $request_length 是最有效的切入点——它精确反映客户端发来的原始请求总字节数（含请求行、全部 Header 和 Body），不依赖后端解析，也不受压缩编码干扰，天然适合在 Nginx 代理层第一时间识别恶意构造的大载荷。
一、必须自定义日志格式并显式记录 $request_length
默认的 combined 日志格式不包含该变量，必须手动加入：
log_format attack_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 attack_log;
关键点：
• $request_length 必须显式写入，它是判断“是否异常大”的第一标尺
• 补充 $request_time 和 $upstream_response_time，可辅助区分是客户端慢速发包（如 Slow Body），还是后端响应延迟导致缓冲堆积
• 保留 $http_x_forwarded_for，避免代理链路中丢失真实源 IP
二、用数值阈值快速定位攻击特征
不要人工翻日志。把 $request_length 当作结构化数值字段处理，用命令或日志平台筛选：
• 查单次请求超 2MB 的记录（单位：字节）：
awk '$12 > 2097152 {print}' /var/log/nginx/access.log
• 按 IP 统计 request_length > 1MB 的高频行为（假设该字段为第12列）：
awk '$12 > 1048576 {ip[$1]++} END {for (i in ip) print i, ip[i]}' /var/log/nginx/access.log | sort -k2 -nr | head -20
典型攻击线索：
• 同一 IP 短时间（如 60 秒内）多次发送 >1MB 的 POST 请求
• 请求方法为 POST，但 URI 指向非上传路径（如 /login、/search、/api/submit）
• $body_bytes_sent 极小（例如仅几十字节），说明服务端几乎没返回有效数据
三、结合 client_max_body_size 做闭环验证
$request_length 异常高，往往意味着请求已触达 Nginx 的体长限制边界。
检查对应请求的 status：
• 若大量出现 413 Request Entity Too Large，需确认 client_max_body_size 是否配置过小（如仍为默认 1m，而业务实际需 10m）
• 若 status 正常（如 200 或 500），但 $request_length 极高、$body_bytes_sent 极低，更可能是恶意填充攻击，而非配置不足
• 注意：client_max_body_size 只限制请求体，不包含请求头；而 $request_length 包含全部，因此后者更全面、更难绕过
四、轻量级实时拦截（可选增强）
可在 Nginx 配置中基于 $request_length 实现初步拦截：
map $request_length $large_req_key {
~^[5-9][0-9]{4,}$ $binary_remote_addr;
default "";
}
limit_req_zone $large_req_key zone=large_req:10m rate=3r/s;
然后在 location 中启用：
limit_req zone=large_req burst=5 nodelay;
该方案优势：
• 不依赖 Lua 或外部模块，开销极低
• 对已知大请求行为（如 >50KB）做速率限制，防止单 IP 持续投毒
• 配合白名单机制（如对 /upload/* 路径跳过）可兼顾业务灵活性
