核心是让client_body_buffer_size覆盖P95/P99请求体大小并避开25%余量临界点，确保POST/PUT请求体全程内存处理；需同步设置client_max_body_size≥该值、client_body_temp_path权限与I/O健康、client_body_in_file_only off，并通过debug日志验证“buffered in memory”行为。
核心是让 client_body_buffer_size 覆盖绝大多数真实请求体大小，同时避开 Nginx 内部 25% 余量机制触发的临界写盘点，使代理转发全程在内存中完成，避免临时文件介入导致延迟上升或缓存失效。
理解它怎么影响代理行为
该参数不决定请求是否被接受（那是 client_max_body_size 的事），而是控制 Nginx 在 proxy_pass 前如何暂存客户端发来的 POST/PUT 数据：
- 请求体 ≤ 缓冲区大小 → 全部驻留内存，直接转发给后端，低延迟、可缓存
- 请求体 > 缓冲区大小 → 超出部分写入磁盘临时文件，Nginx 再读取拼合后转发，引入 I/O 和额外开销
- 若启用了
proxy_cache且请求体落盘，默认跳过缓存（静默失效）
按代理场景设定合理值
不能统一设大，要匹配你实际转发的请求体特征：
- 纯 JSON API 代理（含 JWT、配置下发）：64k–128k 足够，覆盖 95% 请求体，避免默认 8k 导致 Base64 头像或长 token 溢出
- 表单提交 + 小附件（如前端直传元数据+缩略图）：建议 256k，比实测 P95 值上探 30% 左右，绕开 25% 余量卡边问题
- 大文件分片代理（如上传到 OSS 或 MinIO）：可设为 1m，但必须确认后端能流式接收，且
client_max_body_size同步放宽 - 高并发轻量埋点/心跳代理：反而可调小到 4k，降低每个连接内存占用，提升 worker 并发承载力
必须同步配齐的三项
只改 client_body_buffer_size 几乎无效，以下三者缺一不可：
-
client_max_body_size必须 ≥ 缓冲区值，且放在同一作用域（推荐 location 块）：否则合法大请求直接 413，缓冲再大也无用 -
client_body_temp_path目录需存在、Nginx worker 用户可写、所在磁盘空间充足、I/O 延迟低：即使小概率落盘，也要确保不成为瓶颈 -
client_body_in_file_only off（默认即为 off）：禁用此选项，防止所有请求体强制落盘，彻底失去内存优化意义
验证是否真走内存转发
别信配置加载成功，要看运行时行为：
- 开启 debug 日志：
error_log /var/log/nginx/debug.log debug;，上传后搜索 "http client request body buffered in memory" —— 出现即表示成功 - 若日志里有 "write to temp file" 或 "client request body temp file"，说明仍落盘，需调大缓冲或检查配套配置
- 观察临时目录文件创建频次：
ls -lt /var/lib/nginx/body/（或你自定义路径），上传前后应无新增文件
