关键是要让client_body_buffer_size精准覆盖p95/p99请求体并避开25%安全扩容临界点，同步配置client_max_body_size≥该值、client_body_temp_path可写、禁用client_body_in_file_only，并通过debug日志和iostat验证是否真走内存。
要让大请求全程走内存、避开磁盘 I/O，关键不是盲目调大 client_body_buffer_size，而是让它精准匹配业务真实请求体大小，并绕开 Nginx 内部 25% 安全扩容触发的临界点。配置不对，哪怕设成 2m，仍可能部分落盘。
按真实请求体分布设值，别信平均值
日志里平均 POST 体是 120KB 没参考价值。必须统计 P95 或 P99 的 Content-Length：
- 纯 JSON + JWT 接口：P99 通常在 80–120KB → 建议设
128k或256k - 含 Base64 图片的表单（头像、截图）：P99 常达 300–500KB → 建议
512k - 文档/压缩包直传（≤20MB）：P95 在 1.5–3MB → 可设
2m～4m，但需后端同步支持
避开“差一点就落盘”的临界陷阱
Nginx 实际分配缓冲区时会自动加 25%（size += size >> 2）。若你设 256k，而最大请求体是 255KB，它仍可能按 256KB 分配 → 超出部分写临时文件。
- 实测最大为 319KB？别设 256k 或 320k，直接上探到
384k或512k - 前端限制上传 ≤512KB → Nginx 设
client_body_buffer_size 512k更稳妥 - 避免卡在 1m、2m 等整数边界附近，容易因余量计算误判
必须同步配齐的三项配套设置
只改 client_body_buffer_size 几乎无效，以下三者缺一不可：
-
client_max_body_size必须 ≥ 缓冲区值，且放在同一location块内；否则合法大请求直接返回 413 -
client_body_temp_path目录需存在、Nginx worker 用户（如www-data）可写，磁盘空间充足、I/O 延迟低；建议挂tmpfs或专用 SSD 分区 -
禁用
client_body_in_file_only on—— 一旦开启，所有请求强制落盘，缓冲区完全失效
验证是否真走内存，不靠猜测靠日志
改完配置后，必须观察运行态行为：
- 开启 debug 日志：
error_log /var/log/nginx/debug.log debug; - 压测时搜索日志关键词：
"client request body buffered"（走内存）或"temp file"（落盘） - 用
iostat -x 1观察client_body_temp_path所在磁盘的write/s是否明显下降
