防止Nginx错误日志泄露敏感数据的核心是阻断敏感信息进入日志：关闭debug级别、禁传高危变量、隔离敏感接口、规范后端日志、严格权限管控。
防止 Nginx 错误日志泄露密码等敏感业务数据，核心不是“过滤内容”，而是“不让敏感数据进错误日志”——错误日志本身不记录请求体、Cookie 或查询参数，但一旦后端服务（如 PHP-FPM、Node.js）抛出含原始请求信息的异常堆栈，Nginx 的 error_log 就可能间接落盘明文密码。
关闭 debug 级别，严格限定错误日志输出范围
debug 级别会记录完整请求头、响应体甚至变量值，极易暴露密码、Token、身份证号：
- 将
error_log级别设为warn或更高（error更稳妥），禁止使用info和debug：error_log /var/log/nginx/error.log warn; - 避免在全局
http块中开启低级别日志；若需临时排查，仅在特定server或location中临时启用，并立即还原 - 检查所有
fastcgi_param、proxy_set_header配置，确保未将$request_body、$http_authorization等高危变量透传给后端——这些变量若被后端打印进错误堆栈，就会流入 Nginx error_log
隔离敏感接口，阻断错误信息回流路径
登录、重置密码、绑定手机号等接口一旦出错，后端常把原始 POST 数据拼进错误消息。必须从入口切断：
- 为敏感接口单独配置
location，禁用详细错误输出：location = /api/login {<br> proxy_pass http://backend;<br> proxy_intercept_errors on;<br> error_page 500 502 503 504 /50x.html;<br>} - 配合
proxy_hide_header清除后端返回的敏感响应头（如X-Debug-Info、X-Trace-ID含原始参数） - 若用 PHP，确认
display_errors = Off、log_errors = On，且error_log指向独立文件（不与 Nginx error_log 混用）
收紧后端日志行为，避免“借道”泄露
Nginx 本身不解析请求体，但它是错误日志的“搬运工”。真正风险来自后端应用的不安全日志习惯：
- 禁止后端代码直接
error_log($_POST['password'])或console.error(req.body)—— 这类语句一旦触发，Nginx 的error_log会原样记录该行输出 - 统一使用结构化日志库（如 pino、winston、Monolog），对字段做显式脱敏：
logger.error({ action: 'login_failed', user_id: userId, ip: maskedIP }); - 在反向代理配置中，用
proxy_set_header X-Real-IP $remote_addr;替代传递完整$http_x_forwarded_for（后者可能被伪造并含敏感值）
权限与生命周期管控，守住最后一道门
即使日志内容可控，疏忽的权限设置会让攻击者轻松提权读取：
- 错误日志文件属主设为
root:adm，权限严格设为640：chown root:adm /var/log/nginx/error.log<br>chmod 640 /var/log/nginx/error.log
- 用
logrotate强制归档压缩，7 天自动删除：/var/log/nginx/error.log {<br> daily<br> missingok<br> rotate 7<br> compress<br> delaycompress<br> maxage 7<br> create 640 root adm<br>} - 禁止将
/var/log/nginx/目录挂载到 Web 可访问路径（如alias /logs /var/log/nginx;），防止.log文件被直接下载
