不能直接在Nginx日志记录原始敏感参数，因其明文落盘违反《个人信息保护法》和等保要求；Nginx原生不支持条件脱敏，需通过OpenResty的Lua模块在log_by_lua_block中动态识别API路径、解析参数并掩码处理，同时注意RequestBody读取限制与性能优化。
为什么不能直接在 Nginx 日志里记录原始敏感参数
因为像手机号、身份证号、银行卡号等字段一旦明文落盘，就违反《个人信息保护法》和等保要求。Nginx 默认的 $args 或 $request_body 会完整记录请求内容，而它本身不支持正则替换或条件脱敏逻辑——更无法区分“这是登录接口”还是“这是查询订单接口”。直接开启 full log 风险极高，但全量关闭又失去审计价值。
用 Lua + OpenResty 实现动态上下文感知脱敏
Nginx 原生不支持脱敏，但通过 OpenResty（Nginx + Lua） 可以在请求处理阶段介入。关键不是“过滤日志”，而是“重构日志字段”：在 log_by_lua_block 中读取已识别的 API 路径和请求体，按预设规则对特定 key 做掩码处理。
- 先用
set_by_lua_block在 rewrite 阶段标记敏感路径（如/api/v1/user/bind），存入变量$is_sensitive_api - 在
log_by_lua_block中判断该变量，若为真，则解析ngx.var.request_body（需开启lua_need_request_body on）或从 query string 提取参数 - 对匹配字段（如
id_card、phone）执行固定脱敏：保留前3位+后2位，中间用***替代；或使用哈希 ID 映射（适合关联分析） - 将脱敏后的结构写入自定义日志变量，例如
$sanitized_log，再由log_format引用
避免常见陷阱：RequestBody 获取与性能边界
不是所有请求都带 body，也不是所有场景都能安全读取 request_body。Nginx 默认不缓存 request body，需显式配置：
- 必须启用
client_body_buffer_size和client_max_body_size，防止大 body 被截断或 413 错误 -
lua_need_request_body on会阻塞请求，仅建议在明确需要审计的 location 块中开启，全局开启影响吞吐 - 对 GET 请求，优先从
$args解析；对 POST/PUT，才尝试读 body —— 并加 try-catch 防止 JSON 解析失败导致日志丢失 - 脱敏逻辑要轻量：不调外部服务、不查数据库、不递归遍历嵌套 JSON，用字符串匹配或简单 JSON 解析（如
cjson.decode）即可
审计日志格式与合规落地要点
脱敏只是第一步，日志本身还要满足可追溯、防篡改、留存周期等审计要求：
- 每条日志至少包含：时间戳、客户端 IP（需真实 IP，注意 X-Forwarded-For）、上游服务地址、HTTP 方法、URI、脱敏后的参数快照、响应状态码、响应耗时
- 用
log_format定义结构化日志（如 JSON 格式），方便后续接入 ELK 或 SIEM 系统；避免空格分隔，防止字段错位 - 日志文件权限设为
600，目录不可被 web 访问；建议对接 syslog 或远程日志中心，实现集中存储与访问控制分离 - 敏感操作日志单独切片（如
access_sensitive.log），并设置独立 rotation 策略（如 7 天滚动、压缩归档）
