核心思路是让常见大POST请求全程走内存，避免写临时文件；需结合业务请求体大小、后端处理方式和服务器资源合理设定client_body_buffer_size，并同步配置client_max_body_size、client_body_temp_path和client_body_timeout。
核心思路是让常见大 POST 请求全程走内存，避免写临时文件。关键不在盲目调大数值，而在于匹配业务请求体大小、后端处理方式和服务器资源。
先确认是否真由落盘引发性能问题
别直接改配置，先验证瓶颈是否存在：
- 查 Nginx error 日志，搜索 “client request body is buffered to a temporary file” 或 “could not open temp file” —— 出现即说明频繁落盘
- 用 iostat -x 1 观察
client_body_temp_path所在磁盘的%util和await，持续高于 70% 或毫秒级延迟上升，就是 I/O 在拖慢整体响应 - 运行 ps aux | grep nginx，对比调参前后 worker 进程的 RSS 内存占用——若突增且接近机器上限，说明 buffer 设得过大，反而引发内存压力
按实际请求类型设合理 buffer 值
默认 8K–16K 只适合纯文本表单。必须结合你真实收的数据来定：
- JSON API（含 JWT Token、长参数）：64K–128K。JWT payload 常超 8K，16K 容易溢出；64K 覆盖 95% 结构化请求
- 带 Base64 图片的表单（头像、证件照等）：256K。单张小图 Base64 编码约 100–300KB，256K 可保大部分请求驻留内存
-
文档/压缩包上传代理（如前端直传 OSS）：512K–2M。但必须同步放宽后端限制（如 Tomcat 的
maxPostSize、Spring Boot 的server.tomcat.max-http-form-post-size），否则 Nginx 缓了，后端仍截断 - 高并发轻量上报（日志、埋点）：反向建议设为 4K–8K。省下内存给更多连接，比追求单请求缓冲更重要
必须同步配齐的三项配套设置
只改 client_body_buffer_size 几乎一定失效：
-
client_max_body_size：必须 ≥ buffer 值，且不小于业务允许的最大上传体积。例如设 buffer 256K，但 client_max_body_size 只有 1M，那 1.5M 请求仍会返回 413。建议设为业务上限的 1.2 倍（如上限 100M，此处设 120M） -
client_body_temp_path：确认路径存在、Nginx worker 用户（如 www-data）可写、磁盘空间充足、I/O 延迟低。默认常在系统盘，大流量下易占满；建议单独挂 SSD 分区，例如/data/nginx/client_body 1 2 -
client_body_timeout：设为 10–60 秒。防慢速上传长期霸占缓冲区，避免内存被无效占用
针对缓存或流式后端的特殊处理
若你启用了 proxy_cache 或后端支持流式读取，需额外注意：
- 启用
client_body_in_single_buffer on：确保$request_body变量完整可用，避免因落盘导致缓存 key 不一致（如小请求命中、大请求 miss） - 后端支持流式（如 WebFlux、Express raw parser）：可配
proxy_request_buffering off，跳过 Nginx 缓冲，直接转发 socket 流，彻底规避落盘 - 使用
proxy_cache_methods POST时，proxy_cache_key若含$request_body，buffer 必须足够大，否则变量为空或截断，缓存形同虚设
