HTTP/3 标准化落地之后，越来越多的浏览器和客户端默认协商 QUIC 传输。Apache 从 2.4.x 后期的实验分支开始引入 mod_http3 模块，用于在服务端终止 QUIC 连接。但一个现实问题摆在眼前：大量生产环境的 Apache 同时承担反向代理和缓存职责，缓存层工作在 HTTP 语义层面，而 QUIC 是全新的传输层协议，两者叠加后行为如何、配置是否需要调整，官方文档目前讲得并不透彻。这篇文章就把整条链路拆开讲清楚，并给出可直接落地的配置。
先理清：QUIC流量到达Apache后经历了什么
客户端发起 HTTP/3 请求时，会先通过 TCP 上的 HTTP/2 响应头 alt-svc 感知到服务端支持 QUIC，随后切换到 UDP 443 端口建立连接。mod_http3 在 Apache 内部维护一个 UDP 监听器，接收到的 QUIC 流会被解封装成标准的 HTTP/3 帧，再交给请求处理管线。关键点在于：从 mod_proxy 和 mod_cache 的视角看，进来的请求和普通 HTTP/1.1 请求没有本质区别，它们操作的依然是 method、URI、头部这些语义层信息。
这意味着缓存命中判断逻辑本身不依赖传输协议。mod_cache 依据 Cache-Control、Expires、ETag、Vary 等头部做决策，这些头部在 HTTP/3 中原样存在。真正需要关注的是两个差异：一是 QUIC 连接是长连接，单个连接上可并发大量流，缓存的锁竞争会比 HTTP/1.1 更集中；二是 HTTP/3 头部压缩使用 QPACK 而非 HPACK，某些动态设置 Vary 的后端可能在极端情况下产生不同的压缩表示，需要在调试时留意。
另一个容易混淆的概念是：QUIC 的 0-RTT 重放只影响传输层握手中的早期数据，不会绕过缓存层。也就是说，即使客户端用 0-RTT 发出请求，Apache 依然要完整解析 HTTP/3 帧后才查询缓存，缓存命中率不会因为 0-RTT 而虚高或失效。
mod_http3 与 mod_cache 的配置实践
mod_http3 目前需要单独编译，主线 Apache httpd 尚未默认捆绑。编译时依赖 ngtcp2 和 ngttp2 库，建议在测试环境先行验证。下面是一份典型的反向代理加缓存的虚拟主机配置，同时开启 HTTP/3 监听：
LoadModule http3_module modules/mod_http3.so
LoadModule cache_module modules/mod_cache.so
LoadModule cache_disk_module modules/mod_cache_disk.so
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
Protocols h2 h3 http/1.1
Listen 443 udp
Listen 443
<VirtualHost *:443>
ServerName example.ipipp.com
SSLEngine on
SSLCertificateFile /etc/pki/tls/certs/server.crt
SSLCertificateKeyFile /etc/pki/tls/private/server.key
# 开启HTTP/3并通告alt-svc
ProtocolsH3 on
Header always set Alt-Svc "h3=\":443\"; ma=86400"
# 磁盘缓存配置
CacheRoot /var/cache/httpd/proxy
CacheDirLevels 2
CacheDirLength 2
CacheEnable disk /
CacheHeader on
CacheDefaultExpire 3600
CacheIgnoreNoLastMod On
# 反向代理到后端
ProxyPass / http://127.0.0.1:8080/
ProxyPassReverse / http://127.0.0.1:8080/
</VirtualHost>这份配置里有几个细节值得展开。首先是 Protocols 指令的顺序，客户端协商时会按优先级从左到右匹配，把 h3 放在前面可以优先协商 HTTP/3。其次，UDP 443 与 TCP 443 用同一个端口完全不冲突，防火墙必须同时放行 TCP 和 UDP 的 443 端口，这是部署时最常见的翻车点，很多运维只开了 TCP，导致客户端 QUIC 握手全部超时，浏览器报 ERR_QUIC_PROTOCOL_ERROR 后静默回落到 HTTP/2，表面看起来一切正常，实际上 HTTP/3 从未生效。
验证方法很简单，用支持 HTTP/3 的 curl 构建（需要 curl 7.66 以上且编译时启用 HTTP/3）执行 curl --http3 -I https://your-domain/，如果响应头中出现 HTTP/3 200 字样，说明 QUIC 链路已经打通。再配合 curl -I 观察响应头里的 X-Cache 信息（由 CacheHeader on 输出），确认缓存命中状态是 HIT 还是 MISS。
缓存策略在HTTP/3场景下的针对性调整
QUIC 连接的复用能力远超 HTTP/1.1，单个客户端可以在一条连接上同时打开上百个流。如果页面里大量静态资源同时请求，多个流可能在同一时刻查询同一缓存键。默认情况下 mod_cache 对过期条目的回源没有合并机制，会出现惊群效应：缓存过期瞬间，几十个流同时穿透到后端。缓解办法是缩短 CacheDefaultExpire 但配合后台刷新，或者干脆在 Apache 前面挂一层更小的内存缓存。目前 httpd 主线还没有 CacheStaleOnError 之外的合并回源指令，这点确实不如 Nginx 的 proxy_cache_lock 好用。
其次是 CacheIgnoreHeaders 的配置。QUIC 客户端某些实现会带上额外的传输层相关头部，如果这些头部被卷入缓存键计算（尤其是被 Vary 覆盖），会导致命中率骤降。建议显式忽略掉与内容无关的头部：
CacheIgnoreHeaders Set-Cookie X-Forwarded-For Forwarded CacheStoreExpired Off CacheLock on CacheLockPath /tmp/mod_cache-lock CacheLockMaxAge 5
这里启用 CacheLock（Apache 2.4.26 之后可用）就是为了对付前面说的惊群问题，它会让同一时刻对同一 URL 的回源请求串行化，其余请求等待最多 CacheLockMaxAge 秒后直接读缓存。这在 HTTP/3 高并发流场景下的收益比 HTTP/1.1 时代更明显。
与Nginx及CDN方案的对比与选型建议
Nginx 官方从 1.25.0 起内置 HTTP/3 支持，成熟度目前领先于 Apache 的 mod_http3，配置也简单得多，一行 listen 443 quic reuseport; 即可。如果你的架构里 Apache 主要作为缓存代理层存在，一个务实的折中方案是：边缘用 Nginx 或云 CDN 终止 QUIC，内部继续由 Apache 承担反代与缓存。QUIC 在公网传输，内部回源走 HTTP/1.1 或 h2c，缓存语义完全不受影响。
反过来，如果你坚持让 Apache 直接面向 HTTP/3 客户端，务必做好灰度。建议先只在部分虚拟主机上开启 ProtocolsH3 on，通过 LogLevel http3:debug 观察一段时间日志，重点盯两类错误：QPACK 解码失败和流量控制窗口死锁，前者通常指向后端返回的畸形头部，后者多与中间防火墙对 UDP 做限速有关。
最后给一个判断标准：已有 Apache 缓存架构、流量以静态内容回源为主、客户端主要在国内移动网络环境（高丢包下 QUIC 收益最大）的场景，升级值得；而如果缓存层前面已经有商用 CDN 终结了 QUIC，Apache 侧跟进 HTTP/3 的紧迫性就低得多，维持稳定的 2.4 LTS 配置反而是更稳妥的选择。