proxy_hide_header可轻量屏蔽后端敏感响应头如Server、X-Powered-By等，但仅作用于proxy_pass之后的上游响应，不处理Nginx自身Server头、缓存响应及错误页，须配合server_tokens off、add_header和error_page等指令才能全面加固。

直接用 proxy_hide_header 屏蔽后端返回的敏感响应头，是最轻量、无需改动应用代码的安全加固手段。它不能隐藏 Nginx 自身的版本信息，也不能处理缓存响应或错误页中的硬编码指纹，必须配合其他指令才能真正“抹除”全部暴露点。

哪些响应头必须优先屏蔽

这些头是自动化扫描工具（如 nuclei、wpscan）识别技术栈的第一依据，泄露后可能直接关联已知 CVE：

• Server（后端的）：如 Tomcat/9.0.83、Apache-Coyote/1.1、uvicorn
• X-Powered-By：如 Express、PHP/8.2、Spring Boot/3.1.0
• X-AspNet-Version 或 X-AspNetMvc-Version：.NET 应用专属，暴露框架版本
• X-Application-Context：Spring Boot 默认返回 application:prod，暴露运行环境
• X-Runtime、X-Debug-Token：虽不显式标版本，但可辅助推断框架与调试状态

正确配置的关键细节

写错位置、顺序或作用域，配置就等于没做：

aperture: the L402 aware reverse proxy

安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。

下载

• 必须放在 proxy_pass 之后——Nginx 只对已收到的上游响应执行隐藏
• 每个头单独一行：proxy_hide_header X-Powered-By; ✅，proxy_hide_header X-Powered-By, Server; ❌（语法错误）
• 仅在当前 location 或 server 块内生效，http 块中定义不会继承到子块
• 大小写不敏感，但建议统一用首字母大写（如 Server），便于维护和排查
• 若后端重复设置同名头（如两个 X-Trace-ID），该指令会一并清除

必须同步处理的三个盲区

只配 proxy_hide_header 远远不够，以下三类场景它完全不覆盖：

• Nginx 自身的 Server 头：用 proxy_hide_header Server 只能屏蔽后端的，不影响 Nginx 返回的 nginx/1.24.0。必须在 http 或 server 块加 server_tokens off;
• 缓存命中响应：Nginx 缓存的是原始响应全量（含未隐藏的头），proxy_hide_header 不会重跑。需搭配 add_header Server "Proxy" always; 强制覆盖所有响应（含缓存）
• 错误页（502/504 等）：这些页面由 Nginx 自行生成，其 HTML body 内常硬编码版本信息（如 Spring Boot 的 Whitelabel Error Page）。需自定义 error_page 并替换模板

验证是否真正生效

别只看配置文件，用真实请求验证：

• 正常路径：curl -I https://your.com/api/user，确认目标头已消失
• 错误路径：curl -I https://your.com/api/invalid-endpoint，检查 5xx 响应头和页面源码
• 缓存路径：先触发一次请求使缓存生效，再用 curl -I 查看是否仍带原始 Server
• 浏览器开发者工具 → Network → Headers 标签页，比对原始响应与预期一致