proxy_hide_header 是 Nginx 安全加固中移除后端敏感响应头（如 X-Powered-By、Server、X-Application-Context 等）最直接有效手段，需置于 proxy_pass 后、location 块内，逐行配置且大小写不敏感。
用 proxy_hide_header 移除后端返回的特殊响应头，是 Nginx 安全加固中最直接有效的手段之一。它不改内容、不加开销，专治那些悄悄暴露技术栈、运行环境甚至部署细节的 Header，比如 X-Powered-By、X-Application-Context、Server（上游的）等。关键在于精准匹配、位置正确、组合得当。
哪些 Header 最该优先隐藏
这些字段常由后端框架或中间件自动注入，攻击者可据此快速判断技术选型、版本漏洞和攻击路径：
-
X-Powered-By：Express、PHP、ASP.NET 等默认添加，直接暴露语言与版本（如
Express或PHP/8.1） -
X-Application-Context：Spring Boot 默认返回，含 profile 名称（如
application:prod），泄露部署环境 - X-AspNet-Version / X-AspNetMvc-Version：.NET 应用特有，指向具体框架版本，易触发已知 CVE
-
Server（上游）：Apache/2.4.52、Tomcat/9.0.83 等，不是 Nginx 自身的 Server，但
proxy_hide_header Server能精准清除它 - X-Runtime / X-Debug-Token：暴露请求耗时或调试开关状态，为自动化扫描提供线索
必须写对的位置和写法
这个指令看似简单，但错一个位置或格式，就完全不生效：
- 必须放在
proxy_pass之后，否则 Nginx 忽略该行 - 只在当前
location或server块内有效，http块中定义无效，子块需单独重复书写 - 每行只能屏蔽一个 Header，不能写成
proxy_hide_header X-Powered-By, Server，语法错误会导致 reload 失败 - 大小写不敏感，但建议按标准首字母大写（如
Server），避免维护歧义 - 多个同名 Header（如后端写了两次
X-Trace-ID）会被一并移除
静态资源场景下的推荐配置
静态文件（JS/CSS/图片等）通常不依赖后端响应头，是最适合集中清理的入口。在对应 location 中配置，既安全又轻量：
（示例）
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff2?|ttf|eot)$ {
proxy_pass http://static_backend;
proxy_hide_header Server;
proxy_hide_header X-Powered-By;
proxy_hide_header X-AspNet-Version;
proxy_hide_header X-Application-Context;
<pre class='brush:php;toolbar:false;'>add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "DENY" always;}
注意：proxy_hide_header 不影响 Nginx 自己生成的头（如 Date、Content-Length），也不处理 Set-Cookie 或 Location —— 这些要用 proxy_cookie_path 或 proxy_redirect 单独控制。
别漏掉的三个配套动作
单靠 proxy_hide_header 不够闭环，实际加固需同步完成以下三件事：
- 关闭 Nginx 自身的版本标识：
server_tokens off;（写在http或server块） - 强制清空可能残留的
Server头：proxy_set_header Server "";（放在location内、proxy_pass后，比proxy_hide_header更彻底） - 统一注入安全响应头：
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains"等，避免后端重复或冲突输出
验证是否生效？用 curl -I https://yoursite.com/app.js 查看响应头，确认敏感字段已消失，且没有意外带出错误页里的 nginx/1.24.0 —— 若仍有，大概率是 502/503 错误页未自定义，需配 error_page 并关掉后端调试模式。
