QUIC 协议把传输层握手与 TLS 加密合并到同一个流程里，在高丢包、高延迟的网络环境下，页面首次加载时间往往比传统 HTTP/2 over TCP 快 30% 以上。而 Apache 作为老牌的 Web 服务器和反向代理，从 2.4.52 版本开始以实验性模块的形式引入了 mod_http3，配合成熟的 mod_cache 缓存体系，完全可以搭建一套既支持 HTTP/3 又具备代理缓存加速能力的服务架构。本文将从代理缓存配置、QUIC 启用、二者结合的注意事项三个层面展开。
一、Apache 代理缓存的工作原理与基础配置
Apache 的代理缓存由三个模块协同完成：mod_proxy 负责反向代理转发，mod_cache 负责缓存决策，mod_cache_disk 或 mod_cache_socache 负责实际存储。当客户端请求到达时，Apache 先查询缓存是否命中，命中则直接返回本地副本，未命中才把请求转发给后端源站。这个机制对动态内容的加速效果尤为明显，比如后端的 PHP 接口返回内容在一定时间内不变，就可以用短 TTL 缓存挡住大部分流量。
先启用需要的模块：
a2enmod proxy proxy_http cache cache_disk headers rewrite systemctl restart apache2
接着在虚拟主机中配置一个典型的反向代理缓存，假设后端源站跑在 8080 端口：
<VirtualHost *:443>
ServerName www.ipipp.com
SSLEngine on
SSLCertificateFile /etc/ssl/certs/site.pem
SSLCertificateKeyFile /etc/ssl/private/site.key
# 开启磁盘缓存
CacheEnable disk /
CacheRoot /var/cache/apache2/mod_cache_disk
CacheDirLevels 2
CacheDirLength 1
CacheMaxFileSize 5000000
CacheMinFileSize 100
# 后端返回 Cache-Control 才缓存，默认至少缓存 60 秒
CacheDefaultExpire 60
CacheIgnoreNoLastMod On
ProxyPreserveHost On
ProxyPass / http://127.0.0.1:8080/
ProxyPassReverse / http://127.0.0.1:8080/
</VirtualHost>
这里有几个容易踩坑的点需要说明。第一，Apache 的 mod_cache 默认遵循后端返回的响应头，如果源站返回了 Cache-Control: no-store，Apache 是不会缓存的，可以视情况用 CacheStoreNoStore On 强制覆盖。第二，CacheDirLevels 和 CacheDirLength 决定缓存文件的目录散列结构，站点文件量大时建议保持两级目录，避免单目录文件过多导致文件系统性能下降。第三，对携带 Cookie 的请求，mod_cache 默认不缓存响应，这一点对于登录态接口是合理的，但要确认匿名访问的请求没有携带多余的 Cookie。
二、启用 HTTP/3 与 QUIC 协议
QUIC 运行在 UDP 协议之上，默认使用 443 端口（准确说是 UDP 443）。这与传统 TCP 443 并不冲突，两者可以同时监听，Apache 会通过 Alt-Svc 响应头告知客户端：这个站点同时支持 HTTP/3，客户端后续请求可以切换到 QUIC 通道。整个协商过程不需要用户感知，Chrome、Firefox、Safari 等主流浏览器均已原生支持。
目前启用 HTTP/3 需要编译 mod_http3 实验模块，以 Debian 系统为例：
apt install libnghttp3-dev libngtcp2-dev libngtcp2-crypto-openssl-dev git clone https://github.com/icing/mod_http3 cd mod_http3 ./configure --with-apxs=apxs make && make install
编译完成后在配置文件中加载并启用：
LoadModule http3_module modules/mod_http3.so Listen 443 Protocols h3 h2 http/1.1 ProtocolsHonorOrder On
Protocols h3 h2 http/1.1 这行指令声明了协议优先级，浏览器支持 QUIC 时会优先走 h3，不支持时自动降级到 h2 或 http/1.1，老客户端完全不受影响。要注意的是 mod_http3 依赖 OpenSSL 3.x 才能提供 QUIC 所需的 TLS 1.3 能力，如果系统自带的是 OpenSSL 1.1，需要先升级或者改用 BoringSSL 编译。另外防火墙必须放行 UDP 443 端口，这是最常见的配置遗漏，症状是浏览器网络面板里协议始终显示 h2。
三、代理缓存与 HTTP/3 结合的实践要点
把两套能力放到同一个虚拟主机里，架构上有一个关键问题需要理解：QUIC 终止在 Apache 这一层，客户端与 Apache 之间走 QUIC，而 Apache 与后端源站之间仍然是传统的 HTTP/1.1 或 h2c 连接。也就是说，缓存判断发生在协议转换之后，无论客户端用什么协议访问，缓存命中与否的逻辑完全一致，这正是分层设计的优势。
完整的组合配置示例：
<VirtualHost *:443>
ServerName www.ipipp.com
Protocols h3 h2 http/1.1
SSLEngine on
SSLCertificateFile /etc/ssl/certs/site.pem
SSLCertificateKeyFile /etc/ssl/private/site.key
CacheEnable disk /
CacheRoot /var/cache/apache2/mod_cache_disk
CacheDefaultExpire 120
ProxyPass /api/ http://127.0.0.1:8080/api/
ProxyPassReverse /api/ http://127.0.0.1:8080/api/
# 对静态资源主动追加缓存头，提升命中率和浏览器复用
<FilesMatch "\.(css|js|png|jpg|woff2)$">
Header set Cache-Control "public, max-age=86400"
</FilesMatch>
</VirtualHost>
验证缓存是否生效，可以用 curl -I 观察响应头，如果出现 X-Cache: HIT from ... 之类的标记（需要配置 CacheDetailHeader），说明缓存命中。验证 HTTP/3 则可以用 curl --http3 或者访问在线的 QUIC 检测工具，浏览器地址栏输入 chrome://net-export 抓包也能确认协议协商细节。
最后提两个运维层面的建议。一是 mod_http3 目前仍标记为实验性质，生产环境建议先在灰度节点上验证，并保留 h2 作为兜底协议；二是缓存目录要纳入监控，磁盘写满会导致缓存写入失败，表现为后端压力突然上升，可以配合 htcacheclean 定时任务自动清理过期文件，例如 htcacheclean -p /var/cache/apache2/mod_cache_disk -l 512M 把缓存总量控制在 512MB 以内。缓存与协议优化从来不是一次性工作，持续观察命中率报表和协议分布，才能让这套架构真正发挥价值。
Apache代理缓存HTTP/3QUIC修改时间：2026-09-11 22:24:49