怎么调优 client_body_buffer_size 预防恶意表单数据过载导致 Worker 磁盘频繁暂存

调优client_body_buffer_size防恶意表单过载，关键是以P95流量设缓冲（如120KB→256k）、用client_max_body_size在读体前主动拦截超限请求（如设2m）、配合client_body_timeout（15–30s）和client_body_temp_path挂载内存盘，实现精准缓冲、主动拦截、安全回退三重防护。

调优 client_body_buffer_size 防止恶意表单数据过载，关键不是堆大数值，而是用“精准缓冲 + 主动拦截 + 安全回退”三重机制，让合法请求走内存、恶意或异常请求被快速识别或限制，避免 worker 进程因大量小而碎的临时文件写入陷入 I/O 瘫痪。

按真实合法流量设缓冲，避开“差1字节就落盘”的临界点

Nginx 对每个请求独立分配缓冲区内存，且内部会自动加约 25% 余量（size += size >> 2）。若你设 256k，而某恶意脚本发送 255KB 的畸形表单体，Nginx 实际尝试分配约 319KB —— 但因配置值不足，仍会触发磁盘暂存，产生大量小临时文件，拖垮 I/O。

• 从 access log 提取 $request_length 或前端埋点中的 Content-Length，统计 P95 值（覆盖 95% 正常表单）
• P95 是 120KB → 推荐设 256k（而非 128k 或 255k），跳过 128k×1.25=160k、256k×1.25=320k 这两个易抖动临界区
• 纯 JSON 表单（含 JWT）通常 ≤100KB，设 128k 已足够；含 Base64 头像字段的表单，P95 常达 300–400KB，建议 512k

用 client_max_body_size 主动拦截超限恶意请求

client_body_buffer_size 不管“能不能传”，只管“放哪暂存”。真正防恶意过载的第一道防线是 client_max_body_size —— 它在读取请求体前就做判断，超限直接返回 413，完全不进缓冲逻辑，零磁盘开销。

• 对普通表单接口（如登录、注册），设 client_max_body_size 2m；明显超过该值的请求，大概率是扫描器或构造攻击，不该给它写磁盘的机会
• 必须与 client_body_buffer_size 同作用域（推荐放在 location /form/ 块内），且前者 ≥ 后者，否则合法大表单也会被误拦
• 配合后端框架限制（如 Express 的 limit: '2mb'、Spring Boot 的 spring.servlet.context-parameters.max-http-post-size），形成前后端双校验

强制 clean 临时文件 + 限定超时，堵住慢速攻击漏洞

即使缓冲区设得合理，攻击者仍可能用极慢速分段上传（slowloris 变种），长期霸占 buffer 和临时文件句柄。需用配套参数主动收口：

• client_body_timeout 设为 15–30 秒：比默认 60 秒更严，防弱网伪装下的恶意停顿
• client_body_temp_path /dev/shm/nginx-body 1 2：挂载到内存盘（tmpfs），避免 SSD 盘被大量小文件刷爆 IOPS；同时确保 www-data（或对应 worker 用户）对该路径有读写权限
• client_body_in_file_only clean（慎用）：仅在高风险入口启用，让所有请求体强制落盘但处理完立即删除，彻底规避内存耗尽风险——代价是性能下降，适合风控前置网关场景

验证是否真防住了，别信 reload 成功

配置生效 ≠ 行为受控。必须观测运行态表现：

• 开启 debug 日志：error_log /var/log/nginx/debug.log debug;，上传正常表单后搜索 "client request body buffered"（走内存）或 "temp file"（已落盘）
• 模拟攻击测试：用 curl -X POST --data-binary @huge-junk.bin 发送略超 client_max_body_size 的数据，确认返回 413 且 error log 中无 temp file 记录
• 监控 iostat -x 1 中 client_body_temp_path 所在设备的 %util 和 write/s，调优后应显著下降