不建议直接用 $request_body 记录敏感接口请求体，因其默认为空、存在安全与性能风险；应通过精准匹配、强制读取和定制日志实现可控记录，或采用WAF、应用层上报等更安全方案。
不建议直接用 $request_body 记录敏感接口的完整请求体到 Nginx 日志，因为该变量在默认配置下多数情况下为空，且存在安全与性能风险。真正可行的方案需结合条件匹配、请求体读取控制和日志格式定制。
为什么 $request_body 大多时候是空的
Nginx 默认不会缓存或读取请求体（尤其是 POST/PUT），除非显式启用相关指令。即使配置了 log_format 包含 $request_body，若未提前触发读取逻辑，该变量始终为空字符串。
-
必须开启
client_body_buffer_size并确保请求体能被内存缓存（否则会写临时文件，$request_body仍不可用） -
需配合
client_max_body_size合理设限，避免大请求拖慢日志写入甚至耗尽内存 - 仅对已解析的请求体生效：Nginx 不解析 JSON/XML，只原样保留原始字节，且不保证编码完整性
安全记录敏感接口请求体的正确姿势
应限定范围、脱敏处理、异步落盘，而非无差别全量记录。推荐分三步实现：
-
精准匹配目标接口：用
location或map指令识别敏感路径（如/api/v1/login、/user/profile/update），避免全局启用 -
强制读取请求体：在对应 location 中添加
proxy_pass_request_body on;（若转发）或echo_read_request_body;（需 echo 模块），或更稳妥地用lua_need_request_body on;（OpenResty） -
定制日志格式并限制长度：例如
log_format sensitive '$time_local | $uri | $status | $request_length | $request_body';，再通过log_subrequest on;或 Lua 截断前 1024 字节，防止日志爆炸
替代方案：比 $request_body 更可靠的做法
直接依赖 $request_body 风险高，生产环境推荐以下组合方式：
- 前置 WAF 或 API 网关记录：如 Kong、Traefik 或云厂商 WAF，自带请求体采样与脱敏能力
- 应用层主动上报：后端服务在收到请求后，将脱敏后的关键字段（如手机号掩码、操作类型）打点到统一日志平台
-
Nginx + Lua 做轻量级过滤：用
access_by_lua_block判断 URI 和 Content-Type，调用ngx.req.read_body()获取 body，再按规则提取并写入独立日志文件（不走 access_log）
必须规避的安全与合规红线
记录请求体涉及隐私与合规问题，实施前务必确认：
- 禁止记录明文密码、身份证号、银行卡号等 PCI/DPO 明确禁止字段，即使日志加密也不合规
- 日志存储需加密且权限严格隔离，避免运维误查或泄露；定期自动清理（如 7 天滚动）
- 所有记录行为须有明确审计依据和用户授权说明，尤其在 GDPR、等保三级场景下
真正落地时，优先用应用日志替代 Nginx 日志记录敏感参数，Nginx 层只做必要元数据标记（如是否命中敏感路径、请求大小、响应状态）。这样既满足可观测性需求，又守住安全底线。
