Apache需依赖mod_headers模块实现响应头重写，须先启用该模块；在Proxy场景下，应在ProxyPass后于或块中使用Header unset/set/append等指令操作头，并用always修饰符确保对非2xx响应生效。
Apache 本身不直接提供“重写响应头内容”的原生能力，mod_proxy 负责代理转发，但真正实现响应头的添加、修改或删除，必须依赖 mod_headers 模块配合使用。
确保 mod_headers 已启用并正确加载
这是所有响应头操作的前提。检查 httpd.conf 或 mods-enabled 目录中是否已加载：
LoadModule headers_module modules/mod_headers.so
若未加载，请添加该行并重启 Apache。部分发行版（如 Ubuntu）可通过 a2enmod headers 启用。
在 Proxy 场景下精准控制响应头
响应头重写需放在 ProxyPass / ProxyPassReverse 配置之后，且作用域要匹配——通常置于
-
移除后端误设的头：例如后端返回了
Content-Encoding: gzip，但 Apache 自己用mod_deflate压缩，就会冲突。应清除：Header unset Content-Encoding -
强制补充协商头：让浏览器知道服务端支持压缩：
Header append Vary Accept-Encoding -
删除失效的 Content-Length：压缩或改写响应体后，原始长度值不再准确，必须删掉，Apache 会自动计算：
Header unset Content-Length -
按需设置/覆盖特定头：比如统一添加安全头：
Header set X-Content-Type-Options "nosniff"Header always set X-Frame-Options "DENY"
注意作用时机与指令修饰符
Header 指令默认只对 2xx 响应生效。若需处理重定向（3xx）、错误（4xx/5xx）等，需显式加上 always 修饰符：
Header always set Strict-Transport-Security "max-age=31536000"Header always unset Server
否则，像 404 页面就不会带上你设定的安全头。
避免与后端逻辑冲突
若后端是 Java/Spring Boot 等框架，常自带响应头管理（如 Spring 的 @CrossOrigin、WebMvcConfigurer）。此时建议：
- 后端尽量只设业务相关头（如自定义 trace-id），通用安全头交由 Apache 统一注入
- 若后端已设某头（如
X-XSS-Protection），而你想覆盖它，用Header set即可；若想彻底清除再设新值，先unset再set - 不要在后端和 Apache 层重复压缩（如后端 gzip + Apache mod_deflate），会导致双重编码错误
