client_body_buffer_size决定POST数据内存缓冲上限，超限部分写入临时文件；它不控制请求拒绝（由client_max_body_size决定），需协同调优三参数并验证落盘行为。
调大 client_body_buffer_size 能减少磁盘写入，但不能只看“越大越好”——它本质是在内存开销和磁盘 I/O 之间做取舍，必须结合上传规模、并发连接数和后端处理方式来定。
它到底管什么？不是限制大小，而是决定存哪儿
client_body_buffer_size 不拒绝请求，只决定客户端 POST 数据（比如表单、文件）在内存里能放多大。小于这个值，全程走内存；超过它，超出部分就写进临时文件（路径由 client_body_temp_path 指定）。这和 client_max_body_size 完全不同——后者才是硬性上限，超了直接返回 413 错误。
也就是说：
- 设为 128k：≤128k 的上传全在内存；129k–500k 的上传，前 128k 在内存，剩下落盘
- 设为 0：所有请求体跳过内存，直接写临时文件（极少用，I/O 压力大）
- 不设或用默认值（通常是 8k 或 16k）：小表单没问题，但稍大点的图片上传就频繁触发落盘
怎么设才合适？按上传特征分场景
没有通用值，关键看你的业务上传数据分布：
- 纯 API 接口（JSON 提交）：保持默认 8k 或 16k 即可，够用且节省内存
- 带头像/截图的表单（≤2MB）：建议 128k–512k，基本覆盖 95% 上传，避免小图反复写磁盘
-
支持文档/压缩包上传（≤20MB）：可设 2m–4m，但必须同步确认
client_max_body_size≥ 这个值，否则大请求还没进缓冲区就被 413 拦截 - 高并发轻量提交（如移动端心跳、埋点）：反而可以调小到 4k，降低每个连接的内存占用，提升整体连接承载能力
光调这个参数没用，三个配套动作必须做
单独改 client_body_buffer_size 很可能无效甚至出错：
-
检查
client_max_body_size：它必须 ≥ 缓冲区大小，且要放在同一作用域（http、server或location），否则缓冲再大也拦不住 413 -
确认
client_body_temp_path：确保目录存在、Nginx 工作用户有读写权限，所在磁盘有足够空间和 I/O 余量（尤其 buffer 不足时落盘频繁） -
设置合理的
client_body_timeout：建议 10–60 秒，防止慢速上传长期占着缓冲区，拖慢 worker 进程
怎么验证调得对不对？别只看不报错
上线后重点观察这几件事：
- 查
error.log：搜索"client intended to send too large body"（buffer 不足）、"could not open temp file"（临时目录异常） - 压测对比：用
wrk或ab对上传接口测试，看平均延迟、错误率是否下降，特别是磁盘 I/O 是否明显减少 - 监控内存变化：执行
nginx -t && nginx -s reload后，用ps aux | grep nginx看 worker 进程 RSS 是否异常增长 - 开启 debug 日志（临时）：
error_log /path/to/debug.log debug;，找"client request body buffered"或"temp file"日志，确认实际走的是内存还是磁盘
