直接调大 client_body_buffer_size 不能解决缓冲区溢出，真正起拦截作用的是 client_max_body_size；该参数仅控制单次读取的内存缓冲单元大小，超限后自动落盘，不触发拒绝动作。
直接调大 client_body_buffer_size 并不能解决缓冲区溢出问题，反而可能加剧内存压力——它只是控制“单次接收 body 的内存块大小”，真正起拦截作用的是 client_max_body_size。溢出的本质，是请求体过大、超时未完成或配置不匹配导致 Nginx 被迫写临时文件、卡住连接或耗尽 worker 内存。
明确 client_body_buffer_size 的真实作用
这个参数不是“总缓冲上限”，而是“单次读取的内存缓冲单元大小”：
- 若上传体 ≤ 该值（如设为
4k），Nginx 尝试全程走内存，效率高、无磁盘 IO - 若上传体 > 该值，Nginx 自动将超出部分写入临时磁盘文件（路径由
client_body_temp_path指定） - 它本身不触发拒绝动作；超限后是否失败，取决于
client_max_body_size是否被突破、磁盘是否可写、超时是否触发
溢出常见诱因与对应处理
日志中出现 buffer overflow detected 或 500 Internal Server Error，往往不是单一参数问题，需结合上下文排查：
-
富文本含 base64 图片：单次 POST 可能达几 MB，远超默认 8k 缓冲，又未设
client_max_body_size，导致解析中途崩溃 -
慢速 body 上传：攻击者分段发数据，
client_body_timeout过长（如默认 60s）会让连接长期占用缓冲资源 -
临时目录不可写或空间不足：当 body 超出缓冲需落盘时，
client_body_temp_path权限错误或磁盘满，直接报错 -
反向代理场景叠加放大：开启
proxy_buffering on且后端响应也大，worker 内存被双倍占用
推荐的协同配置组合
不孤立调参，而是按业务特征做闭环设置：
-
client_max_body_size 50M;—— 放在location块中，仅对上传接口生效，硬性拦截超限请求（返回 413） -
client_body_buffer_size 4k;—— 平衡内存与 IO，小请求走内存，大请求自动落盘，避免设成 1m 导致每个连接预占过多 RSS -
client_body_timeout 12s;—— 从请求头收完开始计时，body 中断即断连，防慢速攻击 -
client_body_temp_path /var/tmp/nginx/client_body 1 2;—— 确保路径存在、有写权限、所在磁盘有足够空间 -
proxy_buffering off;—— 在上传接口的location中显式关闭，避免代理层二次缓存放大内存压力
验证与可观测要点
改完配置别急着上线，先确认是否真解决问题：
- 用
curl -X POST --data-binary @large-file.bin模拟边界上传，观察是否稳定返回 413 或成功接收 - 检查 error.log 是否还有
buffer overflow、no space left on device、Connection timed out等线索 - 监控
nginx_stub_status中 Active connections 和 Writing 数值，异常升高说明连接/缓冲未及时释放 - 压力测试时关注 worker process 的 RSS 内存占用，若随并发线性上涨，大概率是
client_body_buffer_size设得过大或proxy_buffering未关
