nginx不支持请求体分段解析，优化核心是控制缓冲行为、及时释放资源：设client_body_buffer_size为8k–32k（小api）、配client_max_body_size限大小、启用client_body_temp_path落盘兜底、proxy_request_buffering off实现流式透传，并辅以超时熔断。
Nginx 本身不支持对请求体进行“分段解析”（如边接收边流式处理并逐块解析 JSON 或表单字段），它采用的是整体缓冲或落盘机制。所谓“优化请求体内存占用”，核心在于避免将整个请求体长期驻留在内存中，而应根据业务场景主动控制缓冲行为、及时释放资源、必要时交由后端处理。
以下是真正可行且被生产环境广泛验证的配置策略：
控制请求体内存缓冲大小
每个客户端连接都会为请求头和请求体分配独立缓冲区。若上传大文件或提交巨量表单，不加限制会导致单连接内存飙升（尤其在高并发下）。
client_header_buffer_size 1k;
设置请求头初始缓冲区大小。普通 HTTP 请求头通常large_client_header_buffers 4 8k;
当请求头超长（如带大量 Cookie 或自定义 Header），最多分配 4 块 × 8KB 缓冲区。避免设成8 32k这类过大组合。client_body_buffer_size 16k;
关键参数：请求体在内存中暂存的最大值。
✅ 小 API（JSON/表单）：设为8k～32k即可
❌ 不要设为128k或1m——除非你确认所有请求都小且高频，否则极易造成内存浪费client_max_body_size 10m;
全局或 location 级硬限制。超出即返回413 Request Entity Too Large。
必须与后端服务能力对齐（例如后端只接受 ≤10MB 文件，Nginx 就不该允许更大）。
启用临时文件落盘，而非强留内存
当请求体超过 client_body_buffer_size，Nginx 默认会写入临时文件（路径由 client_body_temp_path 指定）。这是降低内存压力的核心机制：
client_body_temp_path /var/tmp/nginx/client_body 1 2; client_body_in_file_only off; # 生产环境必须为 off（仅调试时设 on 强制全落盘）
-
client_body_temp_path的目录需有足够磁盘空间和读写权限 -
1 2表示两级子目录哈希（防文件过多），不影响内存，但提升 IO 效率 - 切勿开启
client_body_in_file_only on（它会让所有请求体都写磁盘，增加 IO 开销，且不解决根本问题）
按需关闭代理缓冲，启用流式透传
如果你的后端（如 Node.js、Go API）本身支持流式读取请求体（比如 req.pipe() 或 io.Copy），可让 Nginx 跳过缓冲、直通转发，彻底规避内存驻留：
location /upload/stream {
proxy_buffering off;
proxy_request_buffering off; # 关键：禁用 Nginx 对请求体的预读与缓冲（需 nginx ≥ 1.15.0）
proxy_pass http://backend;
}
-
proxy_request_buffering off是决定性开关：它让 Nginx 在收到Content-Length或Transfer-Encoding: chunked后，不再等待完整 body，而是边收边转 - 配合
proxy_buffering off可进一步禁用响应缓冲（适用于大文件下载、SSE、视频流等场景） - 注意：此模式下无法做
limit_req、auth_request或重写请求体，功能受限，需后端兜底校验
配合超时与连接管理，防止异常堆积
大请求体传输慢时，若不设限，连接会长期占用内存与 fd：
-
client_header_timeout 15s; -
client_body_timeout 60s; -
send_timeout 30s; keepalive_timeout 30s; keepalive_requests 100;
这些不是“解析分段”的手段，但能快速切断卡住的连接，回收内存。
不复杂但容易忽略：Nginx 的内存优化不在“怎么分段”，而在“什么时候不缓存、不等待、不保留”。合理设置缓冲上限 + 落盘兜底 + 流式透传 + 超时熔断，四者协同，才能稳定压低单连接内存开销。
