Apache作为反向代理使用时，经常遇到一个奇怪的现象：后端Tomcat、Nginx或者Node服务明明开启了gzip压缩，用curl直接访问后端能拿到Content-Encoding: gzip的响应，但一旦请求经过Apache代理，浏览器收到的响应就变成了未压缩的明文。这会导致带宽浪费、页面加载变慢，甚至在超大响应场景下引发超时。本文将从原理层面讲清Apache反向代理对压缩内容的处理机制，并给出可落地的配置方案。
一、理解代理链路上的压缩处理原理
HTTP压缩协商的核心是请求头中的Accept-Encoding。浏览器发送请求时带上这个头，表明自己支持gzip、deflate、br等压缩算法；后端服务根据这个头决定是否压缩响应体，并在响应头中用Content-Encoding标记实际使用的算法。
问题出在Apache的代理模块上。默认情况下，mod_proxy会把客户端的Accept-Encoding头透传给后端，这一点通常没问题。真正容易踩坑的有两个地方：一是mod_deflate如果在代理层也开启了压缩，就可能对已经压缩过的内容做二次压缩，不仅浪费CPU，还会因为gzip数据不具备再压缩性导致体积反而增大；二是某些配置中对请求头或响应头做了人为修改，比如用RequestHeader unset Accept-Encoding去掉压缩协商头，后端自然就返回明文了。
另一个关键点是分块传输。当后端启用压缩后，响应体是流式产出的，此时Content-Length头通常被替换为Transfer-Encoding: chunked。如果代理层对响应做缓冲改写，可能破坏分块结构。理解了这三点，后面的配置就有了明确方向：要么让压缩完全由后端负责、代理原样透传，要么让后端不压缩、压缩统一收敛到代理层做。
二、方案一：后端压缩，代理层原样透传
这是最推荐的架构。压缩在离应用最近的地方完成，代理层只做转发，不消耗额外CPU。要做到这一点，核心是确保代理层不干扰压缩协商头，也不对响应做二次处理。参考配置如下：
# 加载必要模块（httpd.conf或conf.modules.d中确认）
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule deflate_module modules/mod_deflate.so
LoadModule headers_module mod_headers.so
# 关闭代理层的压缩，避免二次压缩
SetOutputFilter DEFLATE 是错误做法，正确方式是只对需要代理层压缩的路径配置
<VirtualHost *:80>
ServerName example.ipipp.com
# 保留客户端的 Accept-Encoding 头，透传给后端
ProxyPreserveHost On
ProxyPass /api/ http://127.0.0.1:8080/
ProxyPassReverse /api/ http://127.0.0.1:8080/
# 确保没有对 Accept-Encoding 做 unset 操作
# 如果全局配置中有 RequestHeader unset Accept-Encoding，必须去掉
</VirtualHost>
配置完成后，用以下命令验证透传是否生效：
# 模拟浏览器发送压缩请求，观察响应头
curl -s -D - -o /dev/null -H "Accept-Encoding: gzip" \
-H "Host: example.ipipp.com" http://127.0.0.1/api/data
# 期望看到：Content-Encoding: gzip
如果响应头中没有Content-Encoding，先检查全局配置里是否有RequestHeader unset Accept-Encoding之类的指令，这是导致透传失败最常见的原因。其次检查mod_filter的FilterChain配置，确认没有对proxy输出附加DEFLATE过滤器。
三、方案二：后端不压缩，代理层统一压缩
当后端是老旧服务无法开启压缩，或者后端数量很多、希望压缩策略统一管理时，可以把压缩职责放到Apache这一层。这种方案的好处是压缩规则集中可控，改一处配置全站生效；缺点是代理服务器要承担压缩的CPU开销，高并发场景需要评估机器规格。
<VirtualHost *:80>
ServerName example.ipipp.com
ProxyPass /api/ http://127.0.0.1:8080/
ProxyPassReverse /api/ http://127.0.0.1:8080/
# 明确剥离客户端的压缩请求头，让后端始终返回明文
RequestHeader unset Accept-Encoding
# 对代理响应启用压缩，按类型过滤
<Location /api/>
SetOutputFilter DEFLATE
AddOutputFilterByType DEFLATE text/html text/plain text/css application/json
AddOutputFilterByType DEFLATE application/javascript text/javascript
# 已经是压缩格式的资源不要再压缩
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|zip|gz|woff2?)$ no-gzip dont-vary
</Location>
# 必须开启 Vary 头，避免代理和CDN缓存出错
Header append Vary Accept-Encoding
</VirtualHost>
这里有几个细节值得展开。RequestHeader unset Accept-Encoding放在代理指令之前，保证后端收到请求时不带压缩协商头，返回的就是明文；随后AddOutputFilterByType只对文本类内容压缩，图片、字体这类本身已压缩的格式通过SetEnvIfNoCase排除，避免做无用功。
Header append Vary Accept-Encoding这行容易被忽略但非常重要。它告诉下游的缓存层，响应内容会随客户端的压缩能力变化，如果缺失，CDN可能把gzip版本的内容发给不支持gzip的客户端，造成乱码。
四、常见故障排查与性能建议
压缩链路上的问题通常可以用三步定位。第一步，绕过代理直接curl后端，确认后端本身压缩正常；第二步，经过代理curl，对比两者的响应头差异；第三步，检查Apache配置中所有涉及Accept-Encoding和DEFLATE的指令。多数问题都能在这三步内暴露。
性能方面，mod_deflate默认压缩级别是6（在ZLIB的1到9范围内），对JSON接口类响应，级别4到5通常能在压缩率和CPU之间取得更好的平衡，可以通过DeflateCompressionLevel 5调整。另外，对大文件下载路径建议显式关闭压缩，因为流式压缩会长时间占用工作进程，得不偿失。
最后提醒一点，如果代理前面还有Nginx或者CDN层，注意压缩只应在一个环节发生，多层都开压缩是最常见的资源浪费。理清每一层的职责边界，压缩透传问题自然迎刃而解。
Apache反向代理mod_deflatemod_proxy压缩透传修改时间：2026-09-05 19:38:47