Nginx日志脱敏需重点防护后端响应中身份证号、手机号等敏感数据，禁用$upstream_http_*等变量，错误日志设为warn/error级，响应体脱敏可选sub_filter或NGINX JS模块，负载均衡下须统一由Nginx执行脱敏。
在 Nginx 作为反向代理或负载均衡器的场景中，日志脱敏不仅要处理客户端请求中的敏感字段（如 token、手机号），更要关注后端服务响应内容本身可能携带的敏感业务数据——比如用户身份证号、银行卡号、完整手机号、邮箱等。这些信息若未经处理就写入 access_log 或 proxy 日志，会直接违反《个人信息保护法》和 GDPR 的“最小必要”原则。
为什么后端响应日志更危险？
默认情况下，Nginx 不记录响应体（$response_body），但以下两类日志极易暴露敏感数据：
- 错误日志（error_log）：当后端返回 5xx 或上游超时，Nginx 可能将原始响应头甚至部分响应体（如 JSON 错误详情）记入 error_log；
- 自定义日志含 $upstream_http_* 变量：例如 log_format 中用了 $upstream_http_x_user_id 或 $upstream_http_set_cookie，而这些响应头由后端注入，常含 Session ID、用户标识等；
- 调试型日志开启时：如启用 debug 日志级别或第三方模块（如 ngx_http_echo_module），可能意外输出完整响应。
不依赖模块的轻量级脱敏方案
核心思路是只记录结构化字段，隔离原始响应内容，避免引入 Lua、JS 或外部工具带来的性能与维护成本：
- 禁用所有 $upstream_http_* 类变量，改用固定安全字段：
log_format balanced '$time_iso8601 | $status | $upstream_status | $request_method | $uri | $body_bytes_sent | $upstream_response_time | $upstream_addr'; - 彻底移除 $http_cookie、$args、$http_authorization 等请求头变量；
- 错误日志级别设为 warn 或 error，避免 info/debug 级别泄露响应细节；
- 若必须记录响应头中的某类标识（如 trace_id），应由后端统一注入可信字段（如 x-request-id），而非复用业务头。
对响应体内容做可控脱敏（需模块支持）
当业务要求记录部分响应体（如 API 返回状态码、关键字段）时，可选以下两种方式：
-
sub_filter 模块（推荐用于文本响应）：
在 location 块中配置，仅对 text/json 类型响应生效：
sub_filter_types application/json text/plain;
sub_filter '"id_card":"[^"]*"' '"id_card":"***"';
sub_filter '"mobile":"[^"]*"' '"mobile":"***"';
sub_filter_once off; -
NGINX JavaScript 模块（高精度控制）：
利用 js_set 定义脱敏函数，在 log_format 中引用计算后的安全值，例如：
js_import /etc/nginx/conf.d/obfuscate.js;
js_set $sanitized_response obfuscate.responseBody;
log_format secure_with_body '$time_iso8601 $status $sanitized_response';
此方式支持正则提取 + 哈希/掩码，且不影响响应流。
负载均衡特有风险点：跨节点日志一致性
在多 upstream server 场景下，不同后端可能返回不同格式的响应（如 A 返回明文手机号，B 返回已脱敏字段）。此时日志脱敏不能依赖后端，必须由 Nginx 统一执行：
- 避免在 upstream 块中使用 proxy_set_header 向后端传递原始敏感参数（如 ?token=xxx）；
- 用 map 指令预清洗 $args，再透传给后端，从源头减少响应中敏感数据生成机会；
- 对 $upstream_addr 记录做 IP 脱敏（如保留前两段），防止通过日志反推后端拓扑。
