合理设置 client_body_buffer_size 的核心是让多数请求体驻留内存，避免超1字节即写临时文件；需依真实请求 P95/P99 统计值设定，并同步配置 client_max_body_size、client_body_temp_path 和 client_body_timeout。
合理设置客户端请求体缓冲区（client_body_buffer_size），核心是让绝大多数请求体完整驻留在内存中，避免哪怕只超 1 字节就触发临时文件写入——这会导致延迟上升、缓存失效、I/O 增加。
按真实请求分布设值，别拍脑袋
先从 access log 或前端埋点采集 Content-Length，统计 P95 和 P99 分位值。Nginx 内部会自动加约 25% 余量（size += size >> 2），所以不能直接照搬最大值：
- 若 P95 是 320KB → 推荐设 512k 或 1m，跳过临界区
- 若 P95 是 4.8MB（如静态包上传）→ 设 6m（4.8 × 1.25），比设 5m 更稳妥
- 纯 JSON 表单（含 JWT、小字段）：64k–128k 足够
- 头像/Base64 表单（通常 ≤500KB）：建议 256k–512k
必须同步配齐三项关联配置
单独调大 client_body_buffer_size 几乎无效，以下三者必须同级声明、逻辑自洽：
- client_max_body_size ≥ 缓冲区值，且作用域一致（推荐放在 location 块内）。否则合法大请求还没进缓冲区就被 413 拦截
- client_body_temp_path 必须指向可写、有空间、低延迟路径（如 /dev/shm/nginx-body 1 2）。即使 buffer 设得再大，超限仍要落盘，路径不可用则请求直接失败
- client_body_timeout 建议设 10–60s（常用 30s），防慢速上传长期霸占缓冲区，拖垮整个 worker
不同场景的典型参考值
不追求“统一最优”，而要匹配业务特征：
- 高并发小数据 API（如移动端 JSON 提交）：可设为 4k–16k，降低单连接内存开销
- 普通表单含图片（头像、证件照）：建议 128k–512k
- 支持中大型文件上传（文档、压缩包，≤20MB）：可设为 2m–4m，但需确认磁盘 I/O 和内存余量
- 微服务网关或需透传大量 body 的代理场景：优先观察实际 body 大小分布，避免盲目设大
验证是否真走内存，靠日志不靠猜
Nginx 默认不会记录是否落盘，但可通过以下方式间接验证：
- 开启 debug 日志级别（谨慎用于临时排查），搜索 "writing client request body to temporary file"；未出现即大概率全程内存处理
- 监控 client_body_temp_path 所在目录的文件创建和 I/O 活动
- 启用 proxy_cache 后，对比缓存命中率变化：一旦请求体落盘，该请求默认不参与缓存
