要让Nginx全程在内存处理请求体，关键在于client_body_buffer_size需覆盖P95/P99请求体大小并预留25%余量，避开临界点触发磁盘写入；同时必须同步配置client_max_body_size≥该值、确保client_body_temp_path权限与I/O健康、设置合理client_body_timeout，并通过debug日志验证“buffered”行为。

要让 Nginx 把请求体全程留在内存里处理，关键不是堆大数值，而是让 client_body_buffer_size 刚好兜住绝大多数真实上传，并避开内部 25% 余量机制触发磁盘写入的临界点。

按业务上传特征设合理值

默认 8KB 只够纯文本表单。得看你们实际收什么数据：

• 纯 JSON API（含 JWT、小字段）：8KB–16KB 足够，不浪费内存
• 带 Base64 图片的表单（头像、截图，通常 ≤500KB）：建议 128KB–512KB，覆盖 P95 请求体大小
• 文档/压缩包上传（≤20MB）：可设 2MB–4MB，但必须同步确认后端能接住
• 高并发轻量提交（如 IoT 心跳、埋点）：反而可调小到 4KB，省内存换连接数

避开“卡边”陷阱，预留安全余量

Nginx 实际分配缓冲区时会自动加 25%（size += size >> 2）。比如你设 256KB，Nginx 尝试按 320KB 分配；但如果 Content-Length 是 255KB，它仍用 255KB——看似够，实则易因余量逻辑误判溢出。

• 若日志统计最大请求体是 255KB，别设 256KB，建议上探到 384KB 或直接 512KB
• 对齐常见上传上限更稳妥：前端限制上传 ≤512KB → Nginx 设 client_body_buffer_size 512k
• 避免盲目设 2MB+：2000 并发下每个连接多占 2MB，就是 4GB 内存开销

必须同步检查的三个配套配置

只改 client_body_buffer_size 基本无效，这三个必须一起配：

• client_max_body_size 必须 ≥ 缓冲区值，且放在同一作用域（location 最佳），否则合法大请求直接被 413 拦截
• client_body_temp_path 目录需存在、Nginx worker 用户（如 www-data）有读写权限，所在磁盘空间充足、I/O 延迟低（建议单独挂 SSD 分区）
• client_body_timeout 建议设 10–60 秒，防慢速上传长期霸占缓冲区，拖慢 worker 进程

验证是否真走内存，别信配置信日志

改完配置不能只看服务没报错，得盯运行态：

• 开启 debug 日志：error_log /var/log/nginx/debug.log debug;，搜索 http client request body buffered（走内存）或 temp file（落盘）
• 压测对比：用 wrk 模拟典型上传，观察平均延迟、磁盘 write/s 是否下降
• 监控临时目录文件创建频次，或用 strace -p $(pgrep nginx) -e trace=openat 看上传时是否调用临时路径