proxy_hide_header 是响应头拦截指令，仅在 Nginx 转发后端响应前移除指定响应头，需严格配置位置、顺序与字段，配合 server_tokens off 和 proxy_set_header Server "" 才能彻底隐藏敏感头。
proxy_hide_header 不是“过滤器”，而是响应头拦截指令——它只在 Nginx 接收后端响应后、转发给客户端前，把指定名称的响应头从转发链中移除。要让它真正起效，关键不在“写没写”，而在“写在哪、写哪些、配得全不全”。
必须拦截的敏感响应头有哪些
这些头普遍存在于 Spring Boot、Express、PHP、Tomcat、ASP.NET 等后端，默认暴露技术栈和版本，是自动化扫描器首轮识别目标：
-
Server：后端真实标识（如
Apache-Coyote/1.1、uvicorn、gunicorn/21.2.0） -
X-Powered-By：框架语言线索（如
Express、PHP/8.2、Spring Boot/3.2.0） -
X-Application-Context：Spring Boot 默认返回，含 profile 名称（如
application:prod） - X-AspNet-Version / X-AspNetMvc-Version：.NET 应用特有，指向具体框架版本
- X-Debug-Token / X-Runtime / X-Trace-ID：暴露调试开关、执行耗时或内部追踪 ID，辅助攻击者定向分析
正确写法：位置、顺序、格式一个都不能错
这个指令对上下文极其敏感，90% 的失效源于配置位置错误：
- 必须紧接在
proxy_pass指令之后，写在它前面完全无效 - 只在当前
location或server块内生效，http块里声明不会继承到子块 - 每个头单独一行，不支持逗号分隔、空格合并或通配符（
proxy_hide_header X-*;是非法语法） - 大小写不敏感，但建议按 RFC 标准首字母大写（如
Server），避免后期维护歧义 - 若后端返回多个同名头（如两个
X-Trace-ID），会一并移除
单靠 proxy_hide_header 不够，必须三步协同
尤其针对 Server 头，Nginx 有特殊处理逻辑，仅靠 proxy_hide_header Server 很容易被绕过：
-
关自身版本：在
http块中加server_tokens off;，防止 Nginx 自动补上nginx/x.y.z -
拦后端透传：在对应
location内、proxy_pass后写proxy_hide_header Server; -
清残留值：同一 location 中加
proxy_set_header Server "";，强制覆盖可能被自动恢复的值
别漏掉错误页这个高危盲区
proxy_hide_header 只影响后端正常响应，对 Nginx 自己生成的错误页（如 502、404）完全无效：
- Spring Boot 的 Whitelabel 错误页默认显示
Whitelabel Error Page和版本号 - Nginx 默认 502 页面硬编码包含
nginx/1.24.0等字样 - 必须用
error_page 404 /404.html;和error_page 502 503 504 /5xx.html;自定义错误页 - 同时确保后端关闭调试模式（如 Spring Boot 的
spring-boot-devtools、Express 的app.set('env', 'production')）
验证是否真生效
别只看配置文件，用命令实测：
- 重载配置：
sudo nginx -t && sudo systemctl reload nginx - 检查响应头：
curl -I https://your-domain.com/api/health - 确认结果中：
– 没有Server:、X-Powered-By:等已屏蔽字段
– 关键安全头（如X-Content-Type-Options）由 Nginx 通过add_header统一注入，而非后端输出
