HTTP/3 协议基于 QUIC（Quick UDP Internet Connections）传输，它不再像 HTTP/1.1 和 HTTP/2 那样依赖 TCP，而是使用 UDP 进行多路复用传输，并强制使用 TLS 1.3 加密。Apache 从 2.4.43 版本开始通过 mod_http3 模块实验性地支持 HTTP/3，该模块底层依赖 Cloudflare 的 quiche 库。为了让反向代理同时提供 HTTP/3 接入和缓存能力，我们需要在代理服务器上同时开启 TCP 和 UDP 监听，并妥善配置代理缓存模块，使缓存逻辑与 QUIC 传输层解耦，实现协议透明的缓存服务。
Apache HTTP/3 的工作机制与前置条件
Apache 的 HTTP/3 支持有两个关键前提：一是编译时需启用 --enable-http3 并链接 quiche 库；二是在运行时，虚拟主机必须同时监听一个 TCP 端口（用于 HTTP/1.1 和 HTTP/2 的初始连接）和一个 UDP 端口（用于 QUIC 数据报）。因为 QUIC 连接建立后，HTTP/3 数据直接在 UDP 上传输，但客户端的初次发现仍需通过 TCP 连接获取 Alt-Svc 头部，该头部会告诉浏览器“本服务器也支持在 UDP 端口 X 上使用 h3 协议”。
在实际部署中，我们不能只开启 UDP 监听而放弃 TCP，因为几乎没有浏览器会只通过猜测 UDP 端口来发起 HTTP/3 连接。一个标准的配置片段会在虚拟主机内分别指定 TCP 和 UDP 监听地址：
<VirtualHost *:443>
Protocols h2 http/1.1
# 其他常规配置...
</VirtualHost>
<VirtualHost *:443>
Protocols h3
# HTTP/3 专用配置...
</VirtualHost>
需要注意，Protocols h3 仅在专门针对 UDP 监听的虚拟主机中有效，并且该虚拟主机不能与 TCP 监听共用同一个端口声明。apache 的 HTTP/3 实现要求使用独立的虚拟主机段来配置 UDP 端口，但这两个虚拟主机可以指向同一个文档根目录或反向代理目标，从而实现逻辑上的统一。
除了编译和监听配置，TLS 证书也必须支持 TLS 1.3，因为 QUIC 强制使用 TLS 1.3 握手。在配置中，可以为 TCP 和 UDP 虚拟主机指定相同的证书文件，Apache 会复用相同的 SSL 配置。如果证书链不完整或者使用了仅支持 RSA 的旧证书，都会导致 HTTP/3 协商失败，浏览器始终回退到 HTTP/2。
搭建 HTTP/3 反向代理并接入缓存
要让 Apache 作为反向代理缓存 HTTP/3 流量，我们需要启用 mod_proxy、mod_proxy_http（必要时还有 mod_proxy_http2，但 mod_proxy_http 足以与后端 HTTP/1.1 通信）和 mod_cache、mod_cache_disk 等模块。反向代理的核心指令是 ProxyPass 和 ProxyPassReverse，而缓存则通过 CacheEnable 激活。
下面是一个同时支持 HTTP/3 和磁盘缓存的完整示例配置。假设我们在 TCP 和 UDP 443 端口上分别配置了两个虚拟主机，并将请求代理到后端的 http://192.168.0.1:8080：
# TCP 监听虚拟主机（用于 HTTP/1.1 和 HTTP/2）
<VirtualHost *:443>
ServerName example.ipipp.com
Protocols h2 http/1.1
SSLEngine on
SSLCertificateFile /etc/ssl/certs/example.crt
SSLCertificateKeyFile /etc/ssl/private/example.key
# 启用 alt-svc 头部，告知客户端 HTTP/3 可用
Header always set Alt-Svc 'h3=":443"; ma=86400'
# 代理与缓存配置
ProxyPreserveHost On
ProxyPass / http://192.168.0.1:8080/
ProxyPassReverse / http://192.168.0.1:8080/
# 磁盘缓存配置
CacheRoot /var/cache/apache2/mod_cache_disk
CacheEnable disk /
CacheDirLevels 2
CacheDirLength 1
CacheDefaultExpire 3600
CacheHeader on
CacheDetailHeader on
</VirtualHost>
# UDP 监听虚拟主机（仅用于 HTTP/3）
<VirtualHost *:443>
ServerName example.ipipp.com
Protocols h3
SSLEngine on
SSLCertificateFile /etc/ssl/certs/example.crt
SSLCertificateKeyFile /etc/ssl/private/example.key
# HTTP/3 不需要 Alt-Svc 头部，因为连接本身已经是 h3
# 代理和缓存可以复制上述配置，或通过 Include 共享
Include /etc/apache2/conf-available/proxy-cache-common.conf
</VirtualHost>
在这个配置中，关键点在于 TCP 虚拟主机中设置了 Alt-Svc 响应头，它告诉浏览器该站点同样支持 h3 协议，并且 QUIC 端口为 443。当浏览器首次通过 TCP 访问并收到该头部后，后续请求便可能直接通过 UDP 发起 HTTP/3 连接。而 UDP 虚拟主机中无需再次设置 Alt-Svc，因为它自己已经在处理 HTTP/3 请求。
缓存模块的配置在两个虚拟主机中保持一致，这样无论请求是通过 TCP 还是 UDP 到达，代理后端的响应都会被缓存到磁盘。由于 mod_cache 是基于 URI 的缓存，它不关心底层传输协议，所以 HTTP/3 请求与 HTTP/2 请求可以共享同一份缓存条目，只要它们的 URI、Vary 头等缓存键匹配。这在实际运行中非常高效。
缓存行为调优与常见问题处理
在 HTTP/3 反向代理缓存场景下，有几个容易忽略的行为需要引起注意。首先是缓存键（Cache Key）的构成。Apache 默认使用完整的请求 URI（包括查询字符串）作为缓存键，但如果应用使用了不同格式但语义相同的 URI（例如 /api?x=1&y=2 与 /api?y=2&x=1），就会导致重复缓存和低命中率。可以通过 CacheKeyBaseURL 或 CacheKeyDefaultExpire 等指令进行调整，并结合实际业务需求规范化查询参数顺序或剥离无关参数。
其次，HTTP/3 通常用于加速交互，但代理缓存对 POST 请求的处理需要特别关注。默认情况下，Apache 不会缓存 POST 请求的响应，这是因为 POST 通常对应有副作用的写操作。如果后端 API 存在部分幂等或可缓存的 POST 请求，我们可以使用 CacheEnable 配合 CacheMethods 指令来显式允许：
<Location /api/search>
CacheEnable disk
CacheMethods GET POST
CacheHeader on
CacheDetailHeader on
</Location>
但这样做风险较高，务必确保该 POST 接口确实安全且幂等。另外，缓存失效策略也值得规划。可以使用 CacheDisable 对部分敏感路径禁用缓存，或者通过 CacheIgnoreCacheControl 强制忽略后端响应的 no-cache 等头部，适合静态资源或变化极慢的动态数据。
另一个常见问题是缓存因 Vary 头产生过多变体。例如后端返回 Vary: Accept-Encoding，这会导致同一 URI 依据客户端支持的压缩算法存储多个版本。Apache 的磁盘缓存可以正确处理这种情况，但会占用更多磁盘空间。如果代理与后端之间统一使用 gzip 压缩，并且客户端也支持，则可以适当调整后端应用，避免产生不必要的 Vary 膨胀。
性能方面，当大量 HTTP/3 请求命中缓存时，Apache 直接从磁盘返回已缓存的响应，这比转发给后端快得多。但由于 HTTP/3 通过 UDP 传输，其自身的流控和丢包恢复由 QUIC 层处理，与 TCP 的拥塞控制不同，在高丢包场景下，QUIC 反而能提供更稳定的吞吐。所以在弱网环境下，HTTP/3 代理缓存的用户体验提升尤为明显。
最后，如果希望进一步减轻后端压力，可以结合 mod_slotmem_shm 使用共享内存缓存，但大部分场景下磁盘缓存已足够。定期监控缓存命中率（可通过 mod_cache 的状态页面或日志分析）并调整 CacheMaxExpire、CacheMinExpire 等参数，是维持高性能的必要操作。