要让大体积POST表单全程内存处理，需按真实请求分布设client_body_buffer_size（如P95=320KB→设512k），并同步配置client_max_body_size、client_body_temp_path和client_body_timeout，避免落盘与内存耗尽。
应对大流量冲击时，client_max_body_size 和 client_body_buffer_size 不是“堆大就行”，而是要协同控制请求准入、内存路径选择与系统承压能力。核心逻辑是：让绝大多数请求体全程走内存，避免磁盘 I/O 拖慢流水线；同时用硬限制防滥用，防止慢速或超大请求耗尽 worker 内存。
按真实流量分布设 client_body_buffer_size，避开“卡边落盘”
该参数决定单个请求体是否全驻内存。Nginx 实际分配时会自动加约 25% 余量（size += size >> 2），所以不能按 P95 值直接设，需向上取整跳过临界区：
- 若日志统计显示 95% 的 POST 请求体 ≤ 320KB → 推荐设
client_body_buffer_size 512k或1m - 纯 JSON API（含 JWT、嵌套字段）且 P95 ≤ 16KB →
64k足够，比默认 16k 更稳 - 高并发小体上报（如 IoT 心跳、埋点），单体平均 1–2KB，但每秒数千连接 → 反而设
4k或8k，降低单连接内存开销 - 切忌全局设过大（如 4m），否则 500 并发即占 2GB 内存，易触发 OOM
client_max_body_size 要分层设限，不只看上传上限
它不参与缓冲决策，只做“守门人”：超限直接 413 拒绝，连缓冲逻辑都不进。必须和业务场景、后端能力、攻击防护联动：
- 在
location /api/块中设client_max_body_size 2m，匹配 JSON 接口实际需求，防恶意大包耗尽连接 - 在
location /upload/块中设client_max_body_size 100m，并确保后端（如 Spring Boot 的spring.servlet.multipart.max-request-size）同步放宽 - 企业级网盘或视频平台可设至
2g，但需配合client_body_timeout 300s防慢速上传霸占资源 - 所有 location 级配置都必须 ≥ 对应的
client_body_buffer_size，否则缓冲还没开始就被拦截
必须同步校准的三项配套项
单独调这两个参数几乎无效，以下三者必须同作用域声明、数值自洽：
-
client_body_temp_path /var/tmp/nginx-body 1 2;：路径需存在、Nginx 用户可写；建议用/dev/shm（内存文件系统）提升落盘性能；多租户建议按 host 分子目录 -
client_body_timeout 30s;：防止客户端缓慢发送导致缓冲区长期被占；大文件上传可延长至 60–120s，但不宜无限制 - 确认未启用
client_body_in_file_only on;：该指令强制所有请求体写磁盘，与内存优化目标完全冲突
验证是否真走内存，别靠猜测
reload 配置 ≠ 生效。需通过运行态行为确认：
- 开启 debug 日志：
error_log /var/log/nginx/debug.log debug;，搜索"http client request body buffered"—— 出现即表示走内存 - 若看到
"temp file"或"client request body is buffered to a temporary file"，说明已落盘，需回查大小设置或临时路径权限 - 用
wrk -H "Content-Length: 350000" -d 10s http://your-api/模拟典型体积压测，观察延迟波动与磁盘 write/s 是否下降
