Nginx location块无法原生预处理请求体，仅支持大小限制、类型拦截、强制读取及Lua模块轻量改写；需避免rewrite改body、if判body等无效操作。
location 块本身不处理请求体（request body）的“预处理”，比如解析、改写、校验或注入字段——Nginx 是反向代理/Web 服务器，不是应用层处理器。所谓“请求体预处理”，在 Nginx 中实际能做的，仅限于：拦截并拒绝非法请求体、限制大小、强制读取以避免后端超时、或通过第三方模块（如 nginx-http-lua-module）做轻量级改写。纯原生 Nginx 配置无法修改 POST 或 JSON 请求体内容。
控制请求体大小与基本校验
防止恶意大包或格式错误请求抵达后端，这是最常用也最稳妥的“前置把关”：
-
统一设最大体长：在
http或server块中设client_max_body_size 10M;，超出直接返回 413 -
按路径精细化控制：例如上传接口允许大文件，普通 API 严格限制
location /upload/ {
client_max_body_size 100M;
}
location /api/ {
client_max_body_size 2M;
} -
拒绝非预期 Content-Type：用
if+$content_type拦截（注意仅用于简单判断，不替代后端校验）
if ($content_type !~ "^application/json$|^application/x-www-form-urlencoded$") {
return 400 "Unsupported Content-Type";
}
确保请求体被完整读取（防代理中断）
某些后端（尤其 Java Spring Boot）依赖完整读取请求体才开始处理。若 Nginx 未主动读取，可能造成连接挂起或超时。启用以下两项可强制读取：
-
client_body_buffer_size 128k;：设足够缓冲区，避免频繁落磁盘 -
client_body_in_single_buffer on;：强制整个 body 进单块内存，便于后续模块访问（如 Lua） - 搭配
proxy_pass_request_body on;（默认即为 on），确保转发时不丢体
用 Lua 模块做轻量级预处理（需编译支持）
若需真正修改请求体（如添加 trace_id、脱敏字段、重写 JSON 字段），必须借助 ngx_http_lua_module。典型流程是：读取原始 body → 解析/修改 → 替换 $request_body → 继续转发：
- 先启用读取：
lua_need_request_body on;（放在 location 块内） - 用
access_by_lua_block解析 JSON 并注入字段（示例）：
access_by_lua_block {
local json = require "cjson"
local data = json.decode(ngx.var.request_body)
data.trace_id = ngx.var.request_id
ngx.var.request_body = json.encode(data)
} - 注意：该方式会消耗内存，不适用于超大 body；生产环境建议只对关键路径启用
绕过请求体处理的常见误操作
这些做法看似“预处理”，实则无效或危险，应避免：
- 在 location 中写
rewrite尝试改写 POST body —— rewrite 只作用于 URI，对 body 无影响 - 用
proxy_set_header添加 header 代替 body 修改 —— header 和 body 是分离的，不能混用 - 依赖
if判断 body 内容 —— Nginx 原生命令无法在 if 中访问 $request_body（除非已开启 lua_need_request_body） - 在 server 级配置
client_max_body_size后，以为所有子 location 都继承 —— 实际上它可被子块覆盖，但不会自动向下传递逻辑
