mod_proxy仅负责请求转发，不压缩不缓存；需协同mod_deflate、mod_cache_disk等模块并明确分工，禁用ProxyRequests、精确配置ProxyPass路径、处理Set-Cookie与Last-Modified头、预压缩需配合mod_rewrite与mod_headers，避免mod_deflate与缓存冲突。
mod_proxy 本身不压缩、不缓存、不预处理静态资源——它只做请求转发。所谓“通过 mod_proxy 实现自动化压缩缓存”，本质是把它和 mod_deflate、mod_cache_disk、mod_expires 等模块协同配置，且必须明确分工：proxy 负责路由，其他模块各司其职。
mod_proxy 配置中必须禁用 ProxyRequests 并限定 ProxyPass 范围
这是安全前提，也是避免缓存错乱的第一道防线。ProxyRequests On 会把 Apache 变成开放代理，不仅无法缓存，还可能被滥用。
-
ProxyRequests Off必须全局启用（通常在主配置或虚拟主机外） -
ProxyPass /static/ http://127.0.0.1:8080/static/这类指令要精确到路径前缀，不能写成ProxyPass / http://...否则所有请求都绕过本地静态文件处理逻辑 - 若后端是 Node.js 或 Python 服务，确保它返回的响应头含
Content-Type和Last-Modified；否则mod_cache_disk可能拒绝缓存 - 不要在
ProxyPass后加nocanon，除非你清楚 URI 解码风险——它会导致缓存 key 不一致
mod_cache_disk 缓存静态资源需显式绑定路径并关闭 Cookie 干扰
Apache 的磁盘缓存默认对带 Set-Cookie 头的响应直接跳过，而很多后端框架（如 Express、Django）默认给所有响应加该头。不处理就会导致缓存命中率为 0。
- 必须在
CacheEnable disk前添加：CacheIgnoreHeaders Set-Cookie -
CacheIgnoreNoLastMod On是必要的——后端静态服务（如 nginx 或 Python SimpleHTTPServer）常不返回Last-Modified，但你仍希望缓存 -
CacheRoot "/var/cache/apache2/mod_cache_disk"对应目录需存在且 Apache 用户（如www-data或apache）有读写权限，否则日志里只报cache_disk: failed to open cache file，无其他提示 - 缓存路径匹配基于
ProxyPass的目标路径，例如CacheEnable disk /static/才能命中ProxyPass /static/ http://...的响应
预压缩 .gz 文件无法靠 mod_proxy 自动生效，必须配合 mod_rewrite + mod_headers
这是最容易误解的一点：mod_proxy 不检查 .gz 文件是否存在，也不重写响应头。即使你把 file.js.gz 放在后端服务器上，mod_proxy 默认只会原样转发 file.js 的响应体，不会替换成 .gz 内容，也不会加 Content-Encoding: gzip。
- 真正起作用的是前端 Apache（即启用 mod_proxy 的这台）上的
RewriteCond %{REQUEST_FILENAME}.gz -s+RewriteRule ^(.*)\.js$ $1.js.gz [QSA]这类规则 - 必须手动设置：
Header append Vary "Accept-Encoding"和Header set Content-Encoding "gzip"，否则浏览器无法识别这是压缩内容 - 如果后端已返回
Content-Encoding: gzip，前端 Apache 默认会透传；但此时mod_cache_disk会按原始 URL（如/static/app.js）缓存，而非/static/app.js.gz—— 导致下次未压缩请求也拿到 gzip 内容，浏览器解析失败 - 解决办法：统一让后端只返回未压缩内容，压缩与 .gz 路由全部由前端 Apache 完成，这样缓存 key 和内容类型才可控
mod_deflate 与 mod_cache_disk 共存时的顺序和冲突点
mod_deflate 在响应输出阶段工作，而 mod_cache_disk 在响应生成后、发送前缓存。如果两者同时启用且未协调，会出现“缓存了未压缩内容，但用户请求时又被 deflate 压缩一遍”之类的问题。
- 最佳实践是：关闭
mod_deflate对代理路径的压缩，只让它处理本地静态文件。用<location> SetEnv no-gzip 1 </location>禁用 - 若坚持用 mod_deflate 压缩代理响应，需确保
AddOutputFilterByType DEFLATE不匹配已被缓存的响应——但这不可靠，因为缓存模块不修改响应类型 - 更稳妥的做法是：完全依赖预压缩 +
mod_rewrite路由，禁用 mod_deflate 对代理路径的干预，把压缩逻辑收口到文件系统层 - 验证是否生效：用
curl -I -H "Accept-Encoding: gzip" http://yourdomain/static/app.js查看返回头是否含Content-Encoding: gzip和X-Cache: HIT（需开启CacheIgnoreCacheControl On并配置日志格式）
最关键的细节往往藏在模块协作的缝隙里：mod_proxy 不决定缓存与否，mod_cache_disk 不校验源文件更新，mod_deflate 不感知 .gz 存在。自动化不是开几个模块就自动发生，而是靠你亲手把每个环节的边界划清楚——尤其是路径匹配范围、响应头覆盖时机、缓存 key 构造方式。漏掉任意一环，都会表现为“配置写了，但没效果”。
