Nginx 默认不支持记录完整$request_body用于日志审计，因其采用流式处理、不缓存请求体；仅在显式触发读取（如proxy_pass）且body完全驻留内存时才可能获取，但仍受限于缓冲区大小。
Nginx 本身不支持直接读取或记录完整的 $request_body 变量用于日志审计，因为该变量在默认配置下是空的——它仅在启用特定模块（如 ngx_http_proxy_module）且请求体已被读入内存时才可用，且仅限于某些上下文（如 rewrite 或 proxy_pass 前）。盲目依赖 $request_body 记录 POST 全文，极易导致日志缺失、截断、乱码甚至服务异常。
为什么 $request\_body 在大多数情况下为空
Nginx 默认采用流式处理请求体，不缓存原始 body 到内存，以节省资源并支持大文件上传。只有显式触发 body 读取（例如使用 proxy_pass、fastcgi_pass，或设置 client_body_buffer_size + client_max_body_size 并配合 proxy_set_body 等），$request_body 才可能有值。即便如此，它仍受限于缓冲区大小，超长内容会被截断或写入临时文件而无法通过该变量获取。
安全可行的全文审计替代方案
推荐以下三种生产环境可用、可控性强的方式：
- 在上游应用层审计：将审计逻辑下沉到后端服务（如 Python/Java/Node.js），由应用解析原始 body、脱敏后写入审计日志。这是最可靠、可定制性最强的方式，能准确识别 JSON/XML 表单字段，规避编码与边界问题。
-
用 Nginx 模块扩展能力：编译安装第三方模块 lua-nginx-module，在
access_by_lua_block中调用ngx.req.read_body()读取 body，再用ngx.log()或ngx.var.request_body记录（注意控制日志级别和敏感字段过滤）。 -
结合镜像代理 + 外部审计器：用
mirror指令将请求副本转发至专用审计服务（如轻量 HTTP 接收器），由该服务完整接收并解析 body，Nginx 本身不参与存储。适合合规要求高、需独立审计链路的场景。
若坚持用 Nginx 原生方式做简单记录，必须满足的条件
仅适用于小体积、低频、非敏感的调试场景，且需严格配置：
- 设置
client_max_body_size 1m;和足够大的client_body_buffer_size 1m;，确保 body 完全驻留内存； - 在
location块中添加proxy_pass（即使只是转给自身或其他 upstream），触发 body 读取； - 使用
log_format自定义日志格式，包含$request_body，但需注意：该变量在log阶段不可用，必须改用$echo_request_body（需echo模块）或通过 Lua 注入变量； - 务必禁用对敏感字段（如 password、token）的记录，并配置日志轮转与权限限制，防止泄露。
不复杂但容易忽略：Nginx 的设计哲学是“不碰业务数据”，全文审计本质是业务层职责。强行在反向代理层实现，往往得不偿失。
