必须三者协同才可靠：proxy_hide_header Server 仅影响后端响应头但常失效，server_tokens off 控制 Nginx 自身版本暴露，proxy_set_header Server "" 在响应阶段强制清空所有 Server 头。
只靠 proxy_hide_header Server 基本无效 —— 它无法真正清除后端 Server 头，必须配合 server_tokens off 和 proxy_set_header Server "" 三者协同才可靠。
为什么 proxy_hide_header Server 单独写没用
Nginx 把 Server 视为“受信响应头”，即使你写了 proxy_hide_header Server，它仍可能被透传、被重写，或在某些版本中直接忽略。尤其当后端是 Apache/Tomcat/Spring Boot 等默认发 Server 头的服务时，该指令常形同虚设。
- 它只影响后端返回的响应头，对 Nginx 自己生成的
Server头完全无感 - 不支持通配符或正则，
proxy_hide_header Server和proxy_hide_header server效果一样，但大小写统一更稳妥 - 若后端多次设置
Server（如负载均衡层加了一次、应用层又加一次），它可能只清掉其中一份
server_tokens off 必须放在 http 或 server 块里
这个指令控制的是 Nginx 自身是否暴露版本号，比如把 Server: nginx/1.24.0 缩成 Server: nginx 或彻底不发。但它只作用于 Nginx 生成的响应头，不影响后端透传过来的内容。
- 写在
http块里：全局生效，推荐 - 写在
server块里：仅对该虚拟主机生效 - 写在
location块里：语法允许，但实际效果和上层一致，不建议局部控制 - 注意：修改后必须执行
sudo nginx -t && sudo systemctl reload nginx，否则不生效
proxy_set_header Server "" 是真正起效的关键
这不是设置请求头，而是强制将响应中的 Server 头清空 —— Nginx 在代理响应阶段会用这个值覆盖所有已存在的 Server 头（包括后端发的和自己加的）。
- 必须写在
location块内，且要在proxy_pass之后 -
proxy_set_header Server ""比proxy_set_header Server "nginx"更干净，避免引入新标识 - 如果同时用了
add_header Server "MyApp"，后者会被前者覆盖（因proxy_set_header在响应组装阶段更底层） - 该方式无需编译第三方模块，原生 Nginx 1.1.4+ 全支持
验证时最容易漏掉的三个地方
配置改完 reload，不代表就藏住了。很多团队卡在验证环节，因为没打中关键点：
- 用
curl -I http://your-domain.com查看响应头，但忘了加-k（HTTPS 场景下证书错误会导致失败，掩盖真实头） - 触发的是 200 响应，但没测 404/502 错误页 —— 这些页面的 HTML 源码里可能还硬编码着
nginx/1.24.0 - 只检查了主域名，忽略了 API 路径（如
/api/v1/users），而proxy_hide_header只对启用proxy_pass的location生效
真正脱敏不是删掉一行配置，而是让 Server 字样从响应头、错误页、重定向 Location、甚至后端日志输出路径里都消失 —— 这需要源头治理（后端关掉自己的 Server 头）+ 中间层拦截（Nginx 三步法）+ 终端验证（多路径、多状态码）。
