HTTP/3的落地让不少团队开始尝试在Apache反向代理层同时启用QUIC和缓存模块。理想情况是客户端通过UDP 443端口建立QUIC连接，Apache把请求转发给源站，再把响应写入缓存供后续请求复用。但实际操作中，QUIC的连接迁移、0-RTT会话恢复、以及基于连接ID的寻址方式，会和传统HTTP/1.1、HTTP/2时代的缓存逻辑产生一系列冲突。这些冲突往往不是配置错误，而是协议行为和既有缓存假设之间的天然错位。
先从最基本的接入方式说起。Apache支持HTTP/3需要启用mod_http3和mod_quic模块，这两个模块通常不在默认编译列表中。以常见的源码编译为例，需要额外指定enable开关，并且必须搭配支持QUIC的SSL库版本，比如OpenSSL 3.x。编译完成后，配置文件中需要同时监听UDP和TCP端口，因为QUIC在UDP上跑，而老客户端依然走TCP的HTTP/2或HTTP/1.1。
LoadModule http3_module modules/mod_http3.so
LoadModule quic_module modules/mod_quic.so
LoadModule proxy_module modules/mod_proxy.so
LoadModule cache_module modules/mod_cache.so
LoadModule cache_disk_module modules/mod_cache_disk.so
Listen 443 https
Listen 443 quic
<VirtualHost *:443>
ServerName www.ipipp.com
Protocols h2 h3 http/1.1
SSLEngine on
SSLCertificateFile /etc/ssl/certs/example.crt
SSLCertificateKeyFile /etc/ssl/private/example.key
ProxyPass / http://backend-server:8080/
ProxyPassReverse / http://backend-server:8080/
CacheEnable disk /
CacheRoot /var/cache/apache2/mod_cache_disk
CacheDirLength 2
CacheDirLevels 3
CacheDefaultExpire 3600
CacheHeader on
CacheDetailHeader on
</VirtualHost>
这个配置表面上看没什么问题，但一旦启用HTTP/3，缓存模块的行为就会变得不稳定。原因在于mod_cache在判断缓存键时，默认使用请求的URL和部分头信息，并不关心底层的传输层协议。当同一个用户在QUIC连接迁移后，请求虽然指向同一个URL，但源端口和源IP可能已经改变，Apache得到的请求对象本身没有太多区别，理论上缓存命中应该不受影响。然而实际测试中发现，如果客户端在0-RTT阶段发送了请求，而该请求恰好匹配了一个尚未完成验证的缓存条目，mod_cache可能会把陈旧数据直接返回，甚至在某些边界条件下把0-RTT请求错误地转发到源站，导致缓存击穿。
QUIC连接迁移对代理缓存命中判定带来的影响
QUIC协议在设计上支持连接迁移，即客户端从Wi-Fi切到移动网络后，源IP和端口发生变化，但连接ID保持不变。对HTTP层来说，连接迁移通常是无感知的，请求依然在同一个逻辑会话中继续处理。然而Apache的代理缓存模块在记录请求来源和缓存状态时，会间接使用到连接相关的信息。部分第三方缓存扩展或自定义的缓存键生成逻辑，会把客户端IP作为缓存变体的一部分。当连接迁移发生时，IP发生变化，缓存键随之改变，导致本应命中的缓存条目没有被找到。
更隐蔽的一个问题出现在QUIC的connection ID与mod_proxy的连接复用上。Apache在向源站转发请求时，会维护一个后端连接池。如果源站也支持HTTP/3，Apache可以通过QUIC与源站通信；如果源站只支持HTTP/1.1或HTTP/2，Apache则退回到TCP连接。这两种模式下，代理缓存写入的响应头可能包含不同的传输相关字段，比如Alt-Svc或者Via头。Via头在HTTP/3场景下会被赋予特定的协议标识，如果缓存模块把这些头一并存储，后续通过不同协议访问同一个资源时，缓存响应的头信息可能不匹配，触发不必要的缓存失效。
可以通过减少缓存变体的维度来缓解这个问题。如果业务场景允许，建议在缓存键中排除客户端IP和User-Agent等容易变化的头，只保留URL和必要的Accept-Encoding变体。Apache的CacheKeyBaseURL指令可以强制缓存键只基于URL，避免连接迁移导致的缓存碎片化。示例配置如下：
CacheEnable disk / CacheRoot /var/cache/apache2/mod_cache_disk CacheKeyBaseURL on CacheIgnoreHeaders Set-Cookie CacheIgnoreNoLastMod On CacheStorePrivate On CacheLock on CacheLockMaxAge 10
CacheLock指令在HTTP/3高并发场景下尤其重要。由于QUIC在UDP上的握手开销比TCP低，客户端发起请求的速度更快，多个请求可能同时到达缓存层。如果源站响应较慢，没有缓存锁的情况下，多个相同的请求会同时穿透到源站，造成源站压力瞬间放大。CacheLock让第一个请求去源站取数据，其余请求等待，等待超时后再决定是否放行。这个机制在HTTP/3下需要配置得更精细，因为QUIC客户端对等待时间的容忍度与TCP不同，过长的锁等待会导致客户端侧超时重连。
0-RTT会话恢复与缓存一致性的冲突场景
HTTP/3的0-RTT允许客户端在重连时直接发送应用数据，而不需要等待握手完成。这大幅降低了延迟，但也带来了一个棘手的问题：0-RTT请求可能被重放。攻击者可以捕获0-RTT数据包并在之后重新发送，如果这个请求是某种有副作用的操作，比如POST表单或者订单提交，就可能造成重复提交。Apache在处理0-RTT请求时，需要识别出这类请求并拒绝或延迟处理。mod_quic提供了QuicTLS0RTT配置项，可以控制是否接受0-RTT数据。
Quic on QuicTLS0RTT off QuicLog /var/log/apache2/quic.log QuicLogLevel debug
把QuicTLS0RTT设为off可以彻底关闭0-RTT，但会损失一部分性能收益。更细粒度的做法是在反向代理层对0-RTT请求做安全过滤，只允许幂等的GET或HEAD请求在0-RTT阶段被处理，其他方法一律等待完整握手。对缓存来说，0-RTT请求如果命中了缓存，直接返回响应是安全的，因为GET请求的重复处理不会对源站造成额外压力。但前提是缓存条目必须是最新的，否则0-RTT请求可能会得到一个过期的响应。可以通过设置较短的缓存过期时间或者强制校验Last-Modified来降低这种风险。
另一个与0-RTT相关的glitch出现在缓存写入阶段。当一个0-RTT请求被转发到源站后，源站返回的响应会被写入缓存。如果这个响应带有Set-Cookie或者Vary头，Apache需要把这些变体信息一并存储。在QUIC连接复用的情况下，同一个连接上可能交错多个请求的响应，mod_cache_disk在写入磁盘缓存时，依靠请求的序列号来区分不同条目。如果QUIC流之间的响应顺序被打乱，缓存写入可能会出现串扰，导致条目A的响应被写入条目B的缓存文件。这个问题在压力测试下更容易复现，表现为缓存内容随机错乱，用户访问A页面却看到了B页面的内容。
排查思路与实际优化手段
遇到Apache代理缓存在HTTP/3下表现异常的情况，建议先确认UDP 443端口是否真正可达。很多云环境的安全组默认只放行TCP，UDP端口没有打开。QUIC客户端在UDP不通时会自动回退到TCP，问题不一定能立刻暴露，但在网络切换或某些中间设备干扰下，QUIC和TCP之间的切换会造成连接抖动，间接影响缓存稳定性。可以用quiche-client或者curl的HTTP/3支持版本来做连通性测试。
# 测试UDP 443端口连通性 nc -u -v server.ipipp.com 443 # 用curl的HTTP/3支持查看响应头 curl --http3-only -I https://server.ipipp.com/cacheable-resource
观察Apache的访问日志和缓存日志也很关键。mod_cache支持CacheDetailHeader，开启后会在响应头中加入X-Cache-Detail字段，标明缓存命中的具体位置和原因。在HTTP/3客户端请求中查看这个头，可以判断请求是否真正命中了磁盘缓存，还是因为连接迁移或协议切换导致缓存键不匹配而穿透到源站。如果发现大量MISS，建议检查后端日志中对应的请求量是否异常增加。
在配置层面，针对HTTP/3代理缓存最实用的几个调整包括：关闭0-RTT或者限制0-RTT只处理GET；启用CacheLock并设置合理的锁超时；使用CacheKeyBaseURL统一缓存键；排除不必要的变体头；以及为源站连接单独配置协议版本。如果源站支持HTTP/3，可以尝试让Apache到源站这一段也走QUIC，这样端到端都基于UDP传输，减少协议转换带来的开销和潜在的状态不一致。不过要注意，Apache的mod_proxy_http3目前还在完善阶段，生产环境使用前需要充分测试。
还有一点容易被忽略的是DNS解析。HTTP/3的Alt-Svc头会告诉客户端下次可以尝试用QUIC连接，如果DNS解析返回的IP地址在多个节点间切换，而QUIC会话又绑定在特定节点上，连接迁移就会频繁发生。这种情况下，代理缓存层的缓存键如果包含了客户端IP或者连接ID相关的信息，命中率会受到明显影响。建议在负载均衡和DNS层面做好会话保持，减少不必要的连接迁移。
综合来看，Apache代理缓存与HTTP/3的结合还处在磨合期，很多glitch来自协议设计与既有缓存假设之间的错位。理解QUIC的连接模型和0-RTT语义，是排查这类问题的基础。实际部署时，先从小流量开始，逐步观察缓存命中率和源站回源量的变化，再决定是否全量开启HTTP/3。对于已经出现缓存错乱的环境，可以先关闭QUIC协议栈的0-RTT支持，同时启用CacheLock，大多数场景下问题都能得到缓解。
Apache代理缓存HTTP/3QUIC协议修改时间：2026-10-01 22:05:06