https本身不能防止敏感信息泄露，必须同步精简响应头（如server、x-powered-by）、拦截敏感路径、关闭目录索引、自定义错误页、收紧日志记录，并在应用层实施严格访问控制。
HTTPS 站点配置本身不能自动防止敏感信息泄露，关键是在启用 HTTPS 的同时，同步收紧响应内容、头信息、错误处理和日志行为。否则，加密通道里照样可能传明文密码、泄露路径结构或暴露后端技术栈。
精简并清理所有 HTTP 响应头
即使走 HTTPS，Server、X-Powered-By 等头仍会明文暴露在加密流量中，攻击者解密后一目了然。
- 在 http 块中添加
server_tokens off;，让 Nginx 自身的Server: nginx/1.24.0变成Server: nginx - 对 proxy_pass 场景，在对应 location 块中逐个清除后端返回的敏感头：
proxy_hide_header X-Powered-By;、proxy_hide_header Server;、proxy_hide_header X-Debug-Token; - 若已编译
headers-more-nginx-module，可用more_clear_headers "Server" "X-Powered-By" "X-AspNet-Version";一次性清空
拦截敏感路径与关闭目录索引
HTTPS 不代表路径自动受保护。攻击者仍会尝试访问 /.env、/git/config、/backup.sql 等，这些请求走的仍是加密连接，但结果可能是完整文件下载。
- 屏蔽所有隐藏文件：
location ~ /\. { deny all; } - 禁止常见敏感后缀：
location ~* \.(env|git|htaccess|log|bak|swp|sql|yml|yaml|json)$ { deny all; } - 显式关闭目录列表：
autoindex off;（建议放在 server 或 location 块内，不依赖默认值）
自定义错误页并截断后端错误详情
HTTPS 下的 500 错误页面若包含堆栈、SQL 报错或请求体片段，等同于把调试信息加密后发给攻击者。
- 配置静态错误页：
error_page 404 /404.html;、error_page 500 502 503 504 /50x.html;，确保页面内容简洁、无路径回显、无技术标识 - 对敏感接口（如
/api/login），启用proxy_intercept_errors on;，强制将后端错误转为统一错误页，不透传原始响应体 - 检查 fastcgi_param 或 proxy_set_header，确认未意外透传
$request_body、$http_authorization等变量
收紧日志记录范围
HTTPS 请求体中的密码、token、手机号等，一旦被记入 access_log 或 error_log，就变成本地明文“证据”。
- 将
error_log级别设为warn或error，禁用info和debug - 自定义 log_format，剔除
$request_body、$http_cookie、$args等高危字段 - 对登录、重置密码等敏感接口，单独配置
access_log off;或写入隔离日志文件
HTTPS 是传输层的锁，而这些设置才是应用层的门禁、窗帘和碎纸机——缺一不可。
