关键在于精准匹配高频post路径的真实请求体分布并规避nginx缓冲临界陷阱；需按该路径实际大小设值，而非全局平均，以避免磁盘i/o、压低延迟。
要让高频 POST 路径（如埋点上报、API 网关、实时鉴权）的请求体全程在内存解析，关键不是堆高数值，而是精准匹配该路径的真实请求体分布，并规避 Nginx 内部缓冲机制的临界陷阱，从而绕过磁盘 I/O，压低端到端延迟。
按该路径真实请求体大小设值，不看全局平均
高频 POST 通常载荷轻但量大，比如 JSON 埋点（禁用所有可能强制落盘的行为 哪怕只有一条配置错误，就会让本该走内存的请求掉进临时文件： - 确保 `client_body_in_file_only off`（默认即为 off，但显式声明更稳妥） - 不要在该 location 中启用 `proxy_buffering off` 或 `proxy_request_buffering off`——这会跳过 Nginx 请求体读取阶段，导致 `$request_body` 为空，反而破坏依赖 body 的逻辑（如 auth_request 提取字段） - 避免在 upstream 或 server 块中设置 `client_body_buffer_size`，必须放在具体 `location /api/track/ { ... }` 块内，确保作用域精准同步配齐三项硬性配套
缺一不可，否则 buffer 再合适也无效： - `client_max_body_size` 必须 ≥ 缓冲值，且同在该 location 块中；例如设 `client_body_buffer_size 4k`，则 `client_max_body_size 10m`（远大于业务上限，防误拦） - `client_body_temp_path` 目录需存在、Nginx worker 用户（如 `www-data`）可写、磁盘有空间——即使不常用，也要防止“缓冲不足时无法创建临时文件”导致 500 错误 - `client_body_timeout 10s`：从收到 header 后开始计时，防慢速发包长期占着缓冲区；高频路径通常秒级完成，10s 已足够宽松用 debug 日志验证是否真走内存
上线后不靠重启确认，而靠运行态证据： - 开启 `error_log /var/log/nginx/debug.log debug;`，在日志中搜索 `"http client request body buffered"` —— 出现即表示成功驻留内存 - 若看到 `"client request body temp file"` 或 `"buffered to a temporary file"`，说明某类请求已溢出，需回查实际 `Content-Length` 分布并上调 buffer - 可配合 `log_format` 记录 `$request_length`，聚合统计该 location 下请求体大小直方图，持续迭代优化不复杂但容易忽略
