apache代理不压缩不解压，仅透传后端gzip响应；关键需验证后端真实返回content-encoding: gzip并保留vary: accept-encoding头，禁用proxypass上下文中的addoutputfilterbytype deflate等重复压缩配置，避免header unset content-encoding破坏头信息。
Apache 代理本身不压缩、不解压、也不修改后端返回的压缩内容——它只做请求转发。要让代理正确透传或适配后端的 gzip 压缩响应，关键在于配置协同与头信息控制，而非依赖 mod_proxy 自身处理压缩。
确保后端真实返回 gzip 响应
这是前提。不能假设后端已压缩，必须验证：
- 用
curl -v -H "Accept-Encoding: gzip" http://backend-url/file.js直连后端，检查响应头是否含Content-Encoding: gzip，且响应体为二进制（非明文） - 若后端是 Node.js（Express）、Python（Flask/Django）等框架，需显式启用压缩中间件，或由 Nginx 等前置服务完成；Apache mod_proxy 不会替后端补压缩
- 避免后端在压缩后错误移除
Vary: Accept-Encoding头，否则缓存可能混存 gzip 与非 gzip 版本
禁用代理侧的重复压缩或解压
mod_proxy 默认透传压缩头，但常见错误配置会破坏它：
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
- 在 ProxyPass 所在上下文（如虚拟主机或 Location 块）中，不要设置
AddOutputFilterByType DEFLATE或SetOutputFilter DEFLATE，否则 Apache 会对已压缩的响应再次尝试 deflate，导致乱码 - 检查是否误用了
Header unset Content-Encoding或Header edit Vary，这些会删掉关键头，使浏览器无法识别压缩格式 - 若需统一处理响应头，用
Header always set或Header append，避免覆盖原始值
配合缓存时保留编码区分
如果同时启用了 mod_cache_disk，必须让缓存能区分 gzip 和非 gzip 版本：
- 确认
CacheIgnoreHeaders没有忽略Vary，例如不要写CacheIgnoreHeaders Vary - 推荐保留默认行为：mod_cache 自动根据
Vary: Accept-Encoding生成不同缓存 key，无需额外配置 - 若后端未返回
Vary，可加Header always set Vary "Accept-Encoding"（仅当后端确实支持 gzip 时）
浏览器收到乱码？快速排查点
典型现象：响应头有 Content-Encoding: gzip，但页面显示乱码或报“failed to decode response”：
- 后端返回的 gzip 数据是否完整？检查是否有截断（如超时、缓冲区溢出）
- Apache 是否启用了
mod_deflate并错误作用于代理路径？查看配置中AddOutputFilterByType是否匹配了/static/类路径 - 是否在 proxy 配置里加了
nocanon？它可能导致 URI 解码异常，间接影响缓存 key 和头处理逻辑 - 用
curl -I对比直连后端和经 Apache 代理的响应头，重点比对Content-Encoding、Vary、Content-Length
