mod_headers是Apache中唯一可靠修改响应头的模块，支持set、unset、append、edit四类操作，需在等作用域内配置，且必须显式unset Content-Length以配合mod_deflate。
mod_headers 是重写响应头的唯一可靠方式
Apache 本身不提供“响应体级”头部重写能力，mod_proxy 和 mod_proxy_http 只负责转发，不修改头；mod_proxy_html 只处理 HTML 文本中的链接；真正能安全、稳定、按规则操作响应头的，只有 mod_headers。它支持 Header set、Header unset、Header append、Header edit 四类操作，且可结合环境变量和条件表达式使用。
- 必须确认模块已启用：
a2enmod headers（Debian/Ubuntu）或检查LoadModule headers_module是否在httpd.conf中启用 -
Header指令只对当前作用域生效：放在 - 若后端返回了
Content-Encoding: gzip，再用Header set强行改Cache-Control不会失败，但浏览器可能因压缩与缓存策略冲突而拒绝解析
Header edit 要慎用，正则易出错且不支持捕获组回溯
Header edit 是唯一能做模式替换的头部操作指令，但它底层调用的是 Apache 自带的正则引擎（PCRE 子集），不支持 \1 这类捕获组引用，也不能跨字段匹配。例如想把 X-Backend-Id: node-a-v2 改成 X-Backend-Id: node-a，不能写 Header edit "X-Backend-Id" "^(node-[a-z])-v\d+$" "$1"——这会直接报错或静默忽略。
- 正确写法是用字面量替换：
Header edit "X-Backend-Id" "node-a-v2" "node-a" - 若需动态处理，得先用
SetEnvIf提取值到环境变量，再用Header set+$envvar插值，例如：SetEnvIf X-Backend-Id "(node-[a-z])" BACKEND_PREFIX=$1，然后Header set X-Backend-Id "%{BACKEND_PREFIX}e" -
Header edit默认只处理第一个匹配项；加early或env=...标志可控制执行时机，但无法实现“全局替换”
响应头过滤必须配合 ProxyPass 的作用域控制
很多问题源于头被“多层覆盖”：后端设了 Cache-Control: private，Apache 在 public，结果以最后出现的为准。更麻烦的是，ProxyPassReverse 会自动重写 Location、Content-Location 等头，如果你在同级块里用 Header unset 去删它们，可能删的是代理前的原始值，而非重写后的。
- 推荐将头操作严格限定在
Header unset X-Powered-By… - 避免在
ProxyPass同级位置写Header，否则可能对非代理路径也生效 - 若需统一清理所有代理响应的敏感头（如
Server、X-AspNet-Version），应在
Header unset Content-Length 是压缩场景下的强制动作
当后端返回了 Content-Length，而你在代理层启用了 mod_deflate（比如用 SetOutputFilter DEFLATE），Apache 不会自动更新该头——它仍保留原始长度，导致客户端收到截断响应或解压失败。这不是 bug，而是设计：Apache 认为“长度应由生成方保证”，所以必须显式清除。
- 只要用了
DEFLATE或任何响应体变换（如mod_substitute），就必须配Header unset Content-Length - 不要试图用
Header edit修改Content-Length值——你根本不知道压缩后是多少，Apache 会在发送前自动计算并设置 - 如果后端还返回了
Content-Encoding（比如gzip），也要Header unset，否则mod_deflate会跳过压缩（认为已压缩）
实际中最容易被忽略的是作用域嵌套和执行顺序：一个 Header set 写在 VirtualHost 顶层，另一个 unset 写在 Location 里，最终行为取决于 Apache 的指令合并规则，而不是“谁写在后面谁生效”。调试时建议用 curl -I 配合 LogLevel headers:trace4 查看每一步头的实际变更。
