ProxyPassReverse仅重写Location等响应头，不参与缓存；必须置于CacheEnable之前，确保缓存保存的是已修正的响应头，否则可能缓存含内网地址的错误跳转。

ProxyPassReverse 本身不参与缓存逻辑，它只负责重写响应头中的 Location、Content-Location 和 URI 等字段，确保客户端看到的是代理后的地址，而非后端真实地址。它和 Apache 的代理缓存（mod_cache）是两个独立但可协同工作的模块——关键在于配置顺序与响应头兼容性。

ProxyPassReverse 必须放在缓存启用之前

Apache 处理请求时按配置顺序执行指令。如果先启用缓存再做响应头重写，缓存可能已保存了含原始后端地址的 Location 响应头，后续请求直接返回错误跳转。

• 正确顺序：先 ProxyPass + ProxyPassReverse，再启用 CacheEnable 或 CacheQuickHandler off
• 典型片段示例：

  <VirtualHost *:80>
      ProxyPreserveHost On
      ProxyPass /app/ http://backend:8080/
      ProxyPassReverse /app/ http://backend:8080/
  <pre class='brush:php;toolbar:false;'># 缓存配置必须在此之后
  CacheEnable disk /app/
  CacheRoot "/var/cache/apache2/mod_cache_disk"
  CacheIgnoreNoLastMod On

  </VirtualHost>

  

  CPA Update - Secure CLI Proxy API Maintenance

  安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。

  下载

缓存内容需保留可重写响应头

如果后端返回的响应头被缓存前已被 ProxyPassReverse 修改，那缓存的就是“修正后”的版本，这是理想状态；但如果后端使用相对路径或未设 Location，缓存不会出错，但 ProxyPassReverse 也无事可做。

• 确保后端返回的 Location: /login 这类相对路径，ProxyPassReverse 才能将其转为 /app/login
• 避免后端返回绝对 URL（如 Location: https://internal.example.com/login），否则 ProxyPassReverse 默认不处理——需配合 ProxyPassReverseCookieDomain 或自定义响应头过滤
• 缓存模块默认不修改响应头，所以只要 ProxyPassReverse 已生效，缓存保存的就是最终对外正确的响应

注意 Vary 和缓存键的兼容性

当代理涉及不同客户端（如移动端/桌面端）或带认证的请求时，Vary 响应头会影响缓存键。若 ProxyPassReverse 不改变 Vary，而缓存又依赖它，则需确保后端设置合理。

• 例如后端返回 Vary: User-Agent，Apache 缓存会为不同 UA 存不同副本，ProxyPassReverse 不影响该行为
• 但若后端未设 Vary: Cookie，而登录态靠 Cookie 区分，缓存可能混用响应——这不是 ProxyPassReverse 的问题，而是缓存策略缺失
• 建议搭配 CacheIgnoreHeaders Set-Cookie 避免缓存含敏感 Cookie 的响应（除非明确需要）

调试建议：用 curl 检查实际缓存内容

绕过浏览器缓存，直接验证 Apache 缓存输出是否包含正确重写的响应头：

• 首次请求：curl -I http://proxy/app/redirect → 观察 Location 是否为 /app/target
• 再次请求（命中缓存）：curl -I http://proxy/app/redirect → 对比两次 Location 是否一致
• 查看缓存文件：ls -l /var/cache/apache2/mod_cache_disk/（路径依 CacheRoot 而定），确认缓存条目存在且时间戳更新