调优client_body_buffer_size的核心目标是让大多数post/put请求体全程驻留内存，避免磁盘写入；需按p95/p99真实大小设值、避开25%自动余量临界点，同步配置client_max_body_size、client_body_temp_path、client_body_timeout及禁用client_body_in_file_only，并通过debug日志验证“buffered in memory”行为。
调优 client_body_buffer_size 的核心目标，是让大多数 POST/PUT 请求体全程驻留在内存中处理，避免写入临时磁盘文件——这不是靠盲目堆大数值，而是匹配真实业务流量、避开 Nginx 内部机制陷阱，并控制单请求内存开销。
按 P95/P99 实际大小设值，跳过 25% 自动余量临界点
Nginx 在分配缓冲区时会自动加约 25% 余量（size += size >> 2）。比如你设 256k，它实际尝试分配约 320k；若请求体刚好是 319k，仍可能因边界判断触发落盘。
- 从 access log 提取
$request_length或前端埋点中的Content-Length，统计 P95 或 P99 值 - 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），形成前后端双校验
强制临时路径挂载内存盘 + 限定上传超时
即使缓冲区设得合理，攻击者仍可能用慢速分段上传长期霸占 buffer 和临时文件句柄。需用配套参数主动收口：
-
client_body_timeout设为15–30s：比默认 60s 更严，防弱网伪装下的恶意停顿 -
client_body_temp_path /dev/shm/nginx-body 1 2：挂载到内存盘（tmpfs），降低落盘成本；确保 Nginx worker 用户有读写权限、目录存在、空间充足 - 禁用
client_body_in_file_only on（默认即 off），避免所有请求体强制写磁盘
验证是否真走内存，别信 reload 信日志
配置生效 ≠ 行为生效。要确认优化效果，必须观察运行时行为：
- 开启 debug 日志：
error_log /var/log/nginx/debug.log debug;，上传后搜索client request body buffered in memory—— 出现这条才算成功 - 若看到
write to temp file或client request body temp file，说明仍落盘 - 检查临时目录文件数变化：
ls -lt /dev/shm/nginx-body/，上传前后应无新增文件
