proxy_hide_header能解决安全头冲突，因其在响应头透传前直接丢弃后端输出的X-Content-Type-Options、X-XSS-Protection等易冲突头，确保Nginx通过add_header统一注入，避免双头并存导致浏览器行为未定义。
proxy_hide_header 为什么能解决安全头冲突
后端服务（如 Spring Boot、Express）常默认输出 X-Content-Type-Options、X-XSS-Protection、X-Frame-Options 这类安全响应头，但它们的值可能过时、宽松，甚至与 Nginx 统一配置的策略矛盾。比如后端返回 X-Frame-Options: SAMEORIGIN，而你已在 Nginx 用 add_header X-Frame-Options "DENY" 强制覆盖——此时浏览器实际收到两个同名头，行为未定义，部分浏览器会忽略后者或触发警告。
proxy_hide_header 的作用就是**提前切断后端头的透传路径**，让 Nginx 完全掌控输出，避免双头并存。它不修改响应体，也不重写头，只做“丢弃”动作，轻量且确定性强。
哪些安全头必须优先用 proxy_hide_header 屏蔽
以下头若由后端输出，极易引发策略冲突或降级风险，应无条件屏蔽：
-
proxy_hide_header X-Content-Type-Options：后端可能漏设或设为nosniff外的值，Nginx 应统一用add_header补上 -
proxy_hide_header X-XSS-Protection：现代浏览器已弃用，后端若启用（如旧版 ASP.NET），反而干扰 CSP 生效 -
proxy_hide_header X-Frame-Options：与 CSP 的frame-ancestors冲突；若需兼容老浏览器，也应由 Nginx 单点控制 -
proxy_hide_header Content-Security-Policy：除非后端动态生成且可信，否则应由 Nginx 统一注入，避免拼接错误或覆盖 -
proxy_hide_header Strict-Transport-Security：后端不应设置 HSTS，该头必须由边缘网关（Nginx）在 HTTPS 响应中强制注入
proxy_hide_header 放错位置会导致完全失效
这个指令对书写顺序和作用域极其敏感：
- 必须写在
proxy_pass之后，写在之前等于没写 - 只在当前
location块生效，http或server块里声明无效 - 不能屏蔽 Nginx 自身添加的头（如
Date、Server），Server头要关还得靠server_tokens off - 如果后端用了多次
Set-Cookie，proxy_hide_header Set-Cookie会全部删掉——这不是 bug，是设计如此，慎用
验证是否真生效：别信配置，只信 curl -I
改完配置 reload 后，立刻用真实请求验证：
curl -I https://your-domain.com/api/health
重点检查三点：
- 目标头（如
X-XSS-Protection）是否彻底消失，而不是被替换成空值 -
Content-Security-Policy等关键头是否还在——proxy_hide_header不会误删未显式指定的头 - 确认
add_header设置的新头（如Strict-Transport-Security）已出现在响应中，且值正确
最容易被忽略的是：后端可能在错误页（500/404）HTML 中硬编码输出敏感头，proxy_hide_header 对响应体无效，这类泄露得靠后端修复或 Nginx 的 sub_filter 配合处理。
