Nginx记录$request_body实现业务审计需满足三前提：触发body读取（proxy_pass/fastcgi_pass或Lua调用ngx.req.read_body）、合理控制body大小与缓冲（client_max_body_size等）、脱敏后写入定制log_format，并联动后端形成审计闭环。
直接在 access_log 中记录 $request_body 是实现业务级审计最常用也最有效的手段之一，但必须满足几个关键前提，否则日志里只会看到空字符串或截断内容。
确保 request_body 能被 Nginx 正确读取并暴露
Nginx 默认不会主动读取请求体（尤其是 POST），除非有模块触发它——比如 proxy_pass、fastcgi_pass 或显式调用 ngx.req.read_body()（需 Lua）。所以单纯在 log_format 里写 $request_body 很可能记录为空。
- 在需要审计的 location 块中配置
proxy_pass或fastcgi_pass，这是最简单可靠的触发方式 - 若走纯静态转发或自定义逻辑，建议引入
lua-nginx-module，在access_by_lua_block中执行ngx.req.read_body() - 避免依赖未触发 body 解析的 location，例如只做重定向或返回固定响应的路径
控制 body 大小与缓冲策略，防止日志膨胀或丢失
大 body 直接进日志会带来性能和存储风险，Nginx 提供了精细的控制参数：
Web Accessibility (WCAG 2 AA))
下载
将 WCAG 2 AA 无障碍标准应用于设计系统、UI 组件和网页——通过可运行的验证器进行对比度计算，采用设计 token 模式使颜色天生可访问，设定排版和焦点状态规则，并提供语义检查清单。适用于构建或审查 UI。
-
client_max_body_size：限制客户端可发送的最大 body（如设为1m） -
client_body_buffer_size：设置内存缓冲区大小（建议 ≥ 128k，避免频繁落盘） -
client_body_in_single_buffer on：强制 body 存入单块内存，确保$request_body可完整读取（对小到中等 body 有效） - 超大 body（如文件上传）不建议记入 access_log，应改用独立审计模块或后端日志
定制 log_format 并过滤敏感字段
标准格式中加入 $request_body 即可，但生产环境务必注意脱敏：
- 基础示例：
log_format audit '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent req_body:"$request_body" "$http_referer" "$http_user_agent"'; - 敏感字段（如 password、token、id_card）建议用 Lua 在写入前正则替换，或由后端统一处理后再透传
- 避免在日志中记录二进制、base64 编码或加密内容——既无业务意义，又增加解析负担
- Content-Type 也值得记录：
$http_content_type，便于区分 form-data、JSON、纯文本等场景
配合后端审计链路，避免日志孤岛
access_log 记录的是“原始请求快照”，不能替代业务层审计。要形成闭环，还需：
- 确保后端服务也记录相同 trace_id 或 request_id，方便跨系统关联
- 将 access_log 审计字段（如
$request_body、$http_x_forwarded_for）同步到中心化日志平台（如 SLS、ELK） - 对高频异常请求（如 400/401/500 + 特定 body 模式）配置实时告警规则
- 定期抽检日志与数据库变更是否一致，验证审计完整性
