图片分发是很多站点最容易被忽视的性能短板。一张Photoshop导出的高清设计图，动辄几十MB，如果每次请求都回源拉取，用户等待时间会非常难看。把Apache反向代理与HTTP/3 QUIC结合起来，一方面利用代理缓存把回源次数降到最低，另一方面利用QUIC在弱网下的高效传输特性，能明显改善大图片的加载体验。本文从原理到配置逐一展开。
一、先理解为什么要用反向代理缓存
反向代理的核心价值是让请求在离用户更近的一层就被拦截并命中缓存。当用户第一次请求某张图片时，代理服务器去后端源站取回内容，同时把响应写入磁盘缓存；后续再有相同请求，直接从缓存返回，源站压力骤减，响应时间从几百毫秒降到几毫秒级别。
对大图片场景来说，缓存的意义不只是快。图片文件体积大，回源一次的带宽成本高，如果源站在异地机房，一次回源可能要走几百上千公里的公网链路。代理缓存把这个成本从N次降到1次，尤其是热点图片，收益非常可观。
Apache中承担这个职责的是mod_cache、mod_cache_disk和mod_proxy三个模块的组合。mod_proxy负责把请求转发到后端，mod_cache负责判断请求是否可缓存，mod_cache_disk负责把响应体落到本地磁盘。三者协作，一个典型的缓存代理层就成型了。
二、Apache代理缓存的核心配置
下面给出一份可以直接落地的配置片段。假设后端源站是192.168.0.1上的8080端口，代理服务器对外提供80端口的图片服务。
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule cache_module modules/mod_cache.so
LoadModule cache_disk_module modules/mod_cache_disk.so
<IfModule mod_cache.c>
CacheEnable disk /images/
CacheRoot "/var/cache/httpd/proxy"
CacheDirLevels 2
CacheDirLength 1
CacheMaxFileSize 104857600
CacheMinFileSize 1024
CacheIgnoreCacheControl On
CacheDefaultExpire 3600
</IfModule>
<VirtualHost *:80>
ServerName img.ipipp.com
ProxyPreserveHost On
ProxyPass /images/ http://192.168.0.1:8080/images/
ProxyPassReverse /images/ http://192.168.0.1:8080/images/
<Directory "/var/cache/httpd/proxy">
Require all granted
</Directory>
</VirtualHost>几个参数需要特别注意。CacheDirLevels和CacheDirLength控制缓存文件的目录散列深度，图片量大时建议保持2层目录，避免单目录下文件过多导致文件系统性能下降。CacheMaxFileSize我这里设成了100MB，是为了容纳Photoshop导出的超大原图，如果你的业务只有缩略图，这个值可以大幅调低，防止个别异常大文件占满磁盘。
还有一个容易被忽略的坑：CacheIgnoreCacheControl On会让代理忽略客户端的Cache-Control: no-cache请求头。图片类静态资源通常希望这个行为开启，否则某些浏览器或中间设备带上这些头就会频繁击穿缓存。但如果你代理的是个性化内容，千万不要开这个选项，否则会把不同用户的内容错误地共享。
缓存键的设计也值得说一句。Apache默认用完整URL作为缓存键，因此带查询参数的动态图片URL（例如带时间戳版本号的photo.jpg?v=123）会被视为不同资源。建议在源站规范URL，或者用CacheIgnoreQueryString配合合理的失效策略来管理版本。
三、HTTP/3与QUIC解决了什么问题
HTTP/2虽然实现了多路复用，但它跑在TCP之上。TCP层一旦丢包，所有流都要停下等待重传，这就是著名的队头阻塞问题。对大图片传输来说，丢包意味着整个下载进度被卡住，弱网环境（移动网络、跨境链路）下体验尤其糟糕。
QUIC协议直接把传输层搬到UDP上，自己实现了可靠传输、流控和加密。它的优势主要有三点：第一，连接建立只需一次往返，甚至可以做到零往返恢复会话，首次请求的延迟显著降低；第二，不同流之间完全独立，某个流丢包不会阻塞其他流；第三，连接迁移让用户切换网络（比如从Wi-Fi切到4G）时连接不断，下载不中断。
需要澄清一个常见误解：HTTP/3不会让单张图片的极限下载速度变快。带宽还是那个带宽，QUIC提升的是握手效率和弱网下的抗丢包能力。所以它对大量小图请求、高延迟链路、移动端场景收益最大，而对一次性的单大文件下载，改善相对有限。把代理缓存与QUIC组合，本质上是一个互补方案：缓存减少传输次数，QUIC优化剩余传输的链路质量。
四、在Apache中启用HTTP/3
Apache从2.4.x后期版本开始通过mod_http3模块提供实验性的HTTP/3支持，需要配合支持QUIC的构建选项编译。下面是基本配置思路。
LoadModule http3_module modules/mod_http3.so <VirtualHost *:443> ServerName img.ipipp.com Protocols h3 h2 http/1.1 SSLEngine on SSLCertificateFile "/etc/httpd/certs/img.pem" SSLCertificateKeyFile "/etc/httpd/certs/img.key" # HTTP/3基于UDP，需要单独监听443端口 Listen 443 ProtocolsH3ClearPort 443 # 复用前文的代理与缓存配置 ProxyPass /images/ http://192.168.0.1:8080/images/ ProxyPassReverse /images/ http://192.168.0.1:8080/images/ CacheEnable disk /images/ </VirtualHost>
Protocols h3 h2 http/1.1这行的顺序很重要，浏览器会按优先级协商，不支持h3的旧客户端会自动降级到h2或http/1.1，所以这个配置是安全的渐进式升级方案。注意QUIC工作在UDP协议上，防火墙必须放行443端口的UDP流量，这是部署时最常踩的坑——很多人配好了模块却忘记安全组规则，结果QUIC握手始终失败，浏览器默默降级回TCP却毫不知情。
证书方面，QUIC强制要求TLS 1.3，因此证书和密钥必须支持现代加密套件。同时建议在响应头中输出Alt-Svc: h3=":443"; ma=86400，告知浏览器这个域名支持HTTP/3，后续请求才会主动走QUIC通道。
五、验证与调优建议
部署完成后，用curl可以快速验证：curl --http3 -I https://img.ipipp.com/images/photo.jpg，如果返回头中显示HTTP/3字样，说明QUIC链路已经打通。缓存命中情况可以通过mod_cache加入CacheDetailHeader on配置，在响应头里看到cache hit或miss的明细。
调优方向主要有三个。一是磁盘缓存空间，用htcacheclean工具定期清理，设置缓存总量上限，避免磁盘写满影响服务；二是启用CacheLock防止热点图片过期瞬间的缓存击穿；三是结合mod_expires在源站输出合理的Cache-Control: max-age，让浏览器本地缓存与代理缓存形成两级缓存体系，进一步减少请求次数。
整体来看，这套方案的成本不高：Apache模块化架构让缓存和协议升级互不干扰，配置改完平滑重启即可生效。先用代理缓存把回源流量压下来，再逐步开启HTTP/3优化传输层，两条腿走路，大图片分发的性能问题基本可以得到解决。
Apache反向代理HTTP/3QUIC协议修改时间：2026-09-01 00:28:42