必须删除的响应头包括Server、X-Powered-By等暴露技术栈的头，需用Header always unset配合ServerTokens Prod和ServerSignature Off；X-Drupal-Cache-Tags等冗余头可直接Header unset；ETag应优先用FileETag None从源头禁用；Date、Content-Length等HTTP/1.1强制头无法删除。
Apache 的 mod_headers 是控制响应头最直接、最常用的手段，但“删掉就完事”容易踩坑。真正有效的删除，需要理解哪些头能删、哪些删不干净、删了是否真生效，以及如何配合其他配置协同防御。
哪些响应头必须删，又该怎么删才可靠
以下三类头是常见敏感信息源，处理方式各不相同：
-
Server、X-Powered-By、X-AspNet-Version：暴露技术栈，应优先清除。
写法：Header always unset Server+Header always unset X-Powered-By。
⚠️ 注意：Server头需配合ServerTokens Prod和ServerSignature Off才彻底隐藏，否则错误页仍会泄露 -
X-Drupal-Cache-Tags、X-Varnish、X-Cache：CMS 或 CDN 注入的冗余头，可能过大引发 500 错误。
写法：Header unset X-Drupal-Cache-Tags（无需always，因只在正常响应中存在） -
ETag：虽可用
Header unset ETag，但更稳妥的是从源头禁用：FileETag None，避免重写后又被模块重新生成
哪些头看似能删，实则删不掉或不该删
Apache 对部分 HTTP/1.1 强制头有硬性保护，强行 unset 会被忽略：
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
-
Date、Content-Length、Connection：协议要求必须存在，指令无效，不必浪费配置 -
Content-Encoding：若 Apache 自身启用压缩（mod_deflate），而上游已压缩，需用Header unset Content-Encoding避免双重编码；但删它本身不安全，应先理清压缩责任归属 -
Set-Cookie：不能也不该用Header unset Set-Cookie删除——这会破坏登录态。如需防止含 Cookie 的响应被缓存，应改用CacheIgnoreHeaders Set-Cookie
确保删除真正生效的验证方法
别只靠 curl -I 看一眼就收工。真实环境干扰多，必须交叉验证：
- 加缓存绕过头再测：
curl -I -H "Cache-Control: no-cache" https://yoursite.com/api/user，排除代理或浏览器缓存干扰 - 分路径检查：根路径、静态文件（.js/.css）、PHP 脚本、404 页面分别请求，确认
Header unset作用域覆盖完整 - 看「实际响应」而非预检：浏览器开发者工具 Network 标签中，点开具体请求 → Response Headers → 确认显示的是「Actual response」，不是 OPTIONS 预检或跳转响应
- 排查上游干扰：若前端有 CDN、Nginx 反向代理或负载均衡器，Apache 层的 unset 对其无效，必须在对应层重复配置
进阶技巧：配合 always 修饰符与作用域精准控制
默认情况下，Header 指令仅对 2xx 成功响应生效。但安全头、清理头往往需覆盖所有状态码：
- 登出接口返回 302 跳转？用
Header always set Clear-Site-Data "\"*\""，确保跳转响应也带清理指令 - 自定义错误页（403/500）也要加防护？写成
Header always set X-Frame-Options "DENY" - 作用域建议放在
<virtualhost></virtualhost>块末尾，或包裹在<location></location>中，避免全局污染；同时务必用<ifmodule mod_headers.c></ifmodule>包裹，防模块未加载时报错
