$ request_body 默认不生效是因为 Nginx 不缓存请求体，仅在 proxy_pass 等触发读取且配置 client_body_buffer_size 和 client_max_body_size 后才可能有值；启用需谨慎，存在敏感信息泄露、日志膨胀等安全风险。
直接在 log_format 中使用 $request_body 记录请求体是不安全的，且默认不可用，需额外配置并谨慎权衡风险。
为什么 $request_body 默认不生效
Nginx 默认不会缓存请求体，因此 $request_body 变量在大多数日志上下文中为空字符串。它仅在满足以下条件时才有值：
- 请求体已被读取并缓存（例如通过
proxy_pass、fastcgi_pass等代理指令触发） - 或显式启用了
client_body_buffer_size和client_max_body_size，且请求体未被丢弃 - 且该变量出现在请求处理阶段已确定请求体可用的位置（如
log_format在access_log指令中，但前提是请求体已被读取）
启用 $request_body 记录的必要配置
若确需记录请求体（如调试 API 入参），必须主动启用缓冲并确保请求体被读取：
- 设置
client_body_buffer_size（如128k）以控制内存缓冲大小 - 设置
client_max_body_size（如1m）防止过大请求绕过缓冲 - 在 location 块中添加
proxy_pass或其他能触发 body 读取的指令（纯静态服务无法触发） - 注意：即使配置了上述参数，
$request_body在 access_log 中仍可能为空——因为日志写入发生在请求结束时，而 body 读取可能延迟或失败
安全风险与规避建议
记录请求体极易引入严重安全隐患：
- 敏感信息泄露：密码、token、身份证号等可能明文出现在日志文件中
- 日志膨胀与性能下降：大文件上传、长文本提交会导致日志剧增，影响磁盘和 I/O
- 编码与截断问题：二进制内容、特殊字符可能导致日志解析失败或损坏
- 绕过认证/授权逻辑：若日志系统权限管理不当，攻击者可能通过日志获取原始请求数据
替代方案更推荐：
- 仅对特定调试接口（如
/debug/log）临时启用，并限制 IP 和时间 - 用 Lua 模块（如
ngx.re.gsub）脱敏后再记录关键字段 - 结合 WAF 或应用层做结构化审计，而非依赖 Nginx 原始 body 日志
- 改用
$request、$args、$http_x_forwarded_for等更安全的变量组合
最小化实践示例（仅限测试环境）
若必须尝试，请严格限定范围：
log_format body_log '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'req_body:"$request_body"';
<p>server {
listen 80;
client_body_buffer_size 128k;
client_max_body_size 1m;</p><pre class="brush:php;toolbar:false;">location /api/test {
# 强制读取请求体
proxy_pass http://backend;
access_log /var/log/nginx/test_body.log body_log;
}}
上线前务必删除该配置，并禁用所有含 $request_body 的 log_format。
