最有效防泄露手段是直接改日志格式；需精简log_format，移除$request_body、$http_cookie等高危变量，禁用查询参数，启用脱敏、权限管控与tls传输等多重防护。
不能直接在 HTTPS 请求体或 URL 参数里“看到”明文敏感数据——因为 TLS 加密后，Nginx 只能解密到 HTTP 层内容，而原始请求中的密码、Token、身份证号等若出现在 $request、$request_body 或 $args 中，就可能被无意记录进日志，形成泄露。识别的关键不是解密流量，而是检查 Nginx 是否在日志、响应头、错误页等环节把本该保密的信息“主动吐了出来”。
看日志格式有没有埋雷
Nginx 默认的 combined 日志格式会记录完整 $request（含 URL 和查询参数）、$http_cookie、$http_authorization 等变量，极易把登录态、API Key、用户 ID 暴露在磁盘上。
- 检查
log_format是否包含$request_body、$http_cookie、$http_x_api_key等高危字段 - 确认是否用了
$request而非更安全的$request_method $uri $server_protocol（后者不带$args） - 推荐启用精简格式：只保留
$remote_addr、$time_local、$request_method $uri、$status、$body_bytes_sent等必要字段
查响应头和页面是否暴露敏感信息
即使请求加密了，服务端返回的内容仍可能反向泄露：
- 开启
server_tokens off，避免响应头中出现Server: nginx/1.22.1这类版本标识 - 禁用
error_page的详细错误输出（如 PHP 报错、SQL 语法错误），防止500页面直接打印数据库连接串或堆栈路径 - 用
more_set_headers或原生add_header清理掉X-Powered-By、X-Backend-Server等冗余头
盯紧 Referer 和跳转行为
用户从一个带参数的 HTTPS 页面跳转到第三方站点时，浏览器默认会把完整 URL 当作 Referer 发出去——比如 https://app.com/user?uid=123456&token=abc，第三方就能拿到 uid 和 token。
- 在 server 块中统一加响应头：
add_header Referrer-Policy "strict-origin-when-cross-origin"; - 该策略确保跨域时只发源站（
https://app.com），不带路径和参数；同域则保持完整，不影响内部跳转 - 配合前端规范：禁止在 GET 请求 URL 中传 Token、session_id、手机号等
监控异常 TLS 行为辅助判断
Nginx 本身不检测 MITM，但某些中间人工具（如 Evilginx）在伪造握手时会暴露特征：
- 在日志格式中加入
$ssl_protocol和$ssl_cipher，观察是否集中出现老旧协议（TLSv1.0）或非常规密钥套件 - 错误日志中高频出现
SSL routines::unknown protocol或sslv3 alert bad certificate，尤其来自同一 IP 访问多个域名，值得排查 - 启用
ssl_ciphers严格列表（如仅允许ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256），过滤掉易被降级利用的算法
