QUIC协议把传输层握手和TLS握手合并到同一次交互里完成，这让它天生适合代理场景。当Apache作为反向代理承担流量转发时，传统HTTP/2 over TCP的方案在高丢包率网络下会出现队头阻塞，而QUIC的流之间相互独立，单个请求丢包不会拖慢同一条连接上的其他请求。把代理缓存加进来之后，静态资源在边缘命中、动态请求走QUIC快速回源，整体链路的响应时间可以压到一个相当可观的水平。这篇文章就从协议原理、配置落地和问题排查三个层面，把Apache上跑HTTP/3代理缓存的完整思路梳理一遍。
QUIC协议为什么能提升代理转发性能
先从底层说起。QUIC跑在UDP之上，但它在用户空间实现了可靠传输、拥塞控制和加密。与TCP相比，最大的优势在于连接建立的开销。TCP需要三次握手，TLS 1.3还需要额外一轮交互，而QUIC把这两步合成一次往返，如果是重连场景（客户端曾经访问过该服务器），借助会话票据还能做到零往返直接发送业务数据。对代理服务器来说，这意味着回源请求的第一字节时间（TTFB）会显著缩短。
第二个关键点是消除传输层队头阻塞。HTTP/2虽然在应用层做了多路复用，但底层还是一条TCP连接，一旦某个包丢了，整条连接上所有流都得等着重传。QUIC在UDP之上为每个流单独做可靠传输，丢包只影响对应的流。代理场景下经常是几十个并发请求共用连接回源，这个特性直接决定了弱网环境下的体验差异。
第三个优势是连接迁移。QUIC用连接ID标识会话而不是四元组，客户端从WiFi切到蜂窝网络时IP变了，连接依然保持，不需要重新握手。对于移动端占比高的业务，这一点能减少不少重连带来的延迟抖动。
Apache侧的模块组合：mod_proxy与mod_cache协作
目前Apache主线的HTTP/3支持依赖mod_http3模块，它基于ngtcp2和quiche等QUIC实现库构建。代理缓存这条链路涉及四个模块的配合：mod_http3负责QUIC监听，mod_proxy负责上游转发，mod_cache加mod_cache_disk做磁盘缓存存储。先看监听端口的配置。
# 开启HTTP/3相关的模块（编译安装路径可能不同）
LoadModule http3_module modules/mod_http3.so
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
# 同时监听UDP 443（QUIC）和TCP 443（兼容HTTP/1.1与HTTP/2）
Listen 443
Protocols h3 h2 http/1.1
<VirtualHost *:443>
ServerName proxy.ipipp.com
Protocols h3 h2 http/1.1
# TLS证书，QUIC强制要求加密，证书配置不可省略
SSLEngine on
SSLCertificateFile "/etc/httpd/certs/server.crt"
SSLCertificateKeyFile "/etc/httpd/certs/server.key"
# 磁盘缓存的存储位置与缓存层级
CacheRoot "/var/cache/httpd/proxy"
CacheDirLevels 2
CacheDirLength 1
CacheMaxFileSize 10000000
# 对指定路径启用代理缓存
<Location "/static/">
CacheEnable disk
ProxyPass "http://backend.ipipp.com/static/"
Header add Cache-Control "public, max-age=3600"
</Location>
# 动态内容不走缓存，直接透传
<Location "/api/">
ProxyPass "http://backend.ipipp.com/api/"
CacheDisable
</Location>
</VirtualHost>
这段配置里有几个细节值得展开。首先是Protocols h3 h2 http/1.1的顺序，它表示优先协商HTTP/3，客户端不支持时降级到h2再降级到HTTP/1.1。QUIC的发现机制依赖Alt-Svc响应头，Apache会在响应里自动带上alt-svc: h3=":443"，客户端下次访问就会尝试UDP。其次是缓存命中的判断逻辑，mod_cache默认只缓存GET和HEAD请求，且要求上游响应带有明确的缓存许可，比如Cache-Control: public, max-age=3600或者Expires头。如果后端返回的是Cache-Control: private或no-store，即使配置了CacheEnable也不会落盘。
缓存键的生成也要留意。mod_cache_disk默认以完整的请求URL作为键，包含了Host头。如果代理前面还有一层负载均衡改写了Host，可能出现缓存命中率异常低的情况，这时候要么统一Host，要么用CacheKeyParseURL相关的指令调整键的构成。另外，带查询字符串的URL会被视为不同的缓存条目，对于/static/app.js?v=1这类带版本号的资源，版本号变更后旧缓存会成为死数据，建议配合CacheExpiryHTTP和定期清理脚本控制磁盘占用。
性能调优与常见问题排查
QUIC跑在UDP上，Linux内核默认的UDP接收缓冲区往往偏小，高并发下会出现丢包剧增的情况。用ss -u -l -n观察丢包计数，必要时调整系统参数。
# 提高UDP缓冲区上限（需root，重启失效可写入sysctl.conf） sysctl -w net.core.rmem_max=16777216 sysctl -w net.core.wmem_max=16777216 sysctl -w net.core.rmem_default=1048576 sysctl -w net.core.wmem_default=1048576 # 确认防火墙放行UDP 443，这是最常见的部署遗漏 firewall-cmd --permanent --add-port=443/udp firewall-cmd --reload # 查看QUIC监听与丢包情况 ss -u -a -n | grep :443 netstat -su | grep -i "receive buffer"
排查HTTP/3是否真正生效，最直接的办法是看响应头。用curl --http3 -v测试，如果输出里出现HTTP/3 200字样说明QUIC链路已通。如果客户端一直回退到h2，常见原因有三类：一是云服务商的安全组没有放行UDP 443，二是中间链路有设备主动丢弃UDP流量，三是证书链不完整导致QUIC握手失败。前两类可以通过在服务器本地curl --http3测试来区分，本地通而外部不通基本就是网络层拦截。
缓存层面的问题通常表现为命中率上不去。可以在日志里加上%{cache-status}e变量记录缓存命中状态，命中会输出HIT，未命中是MISS，被后端禁止的是SKIP。命中率为零时优先检查后端响应头，很多应用框架默认给所有响应加Set-Cookie，而带Set-Cookie的响应默认不会被缓存，需要在后端剥离Cookie或者用CacheStoreNoStore Off之类的指令谨慎放行。还有一点容易被忽略：mod_cache对同一URL的并发MISS请求默认不做合并（部分版本支持CacheStaleOnUpdating相关策略缓解），缓存击穿时后端压力会瞬间放大，热点资源最好预先预热或在后端做兜底限流。
最后提一下降级策略的稳健性。生产环境建议TCP 443和UDP 443长期并存，不要轻易移除h2和http/1.1的支持，因为部分企业内网和老旧移动网络对UDP限速甚至封禁。通过Apache的Protocols指令保留完整降级链，配合监控QUIC流量占比，逐步观察HTTP/3的实际收益，再决定是否调整缓存和连接参数，这是比较稳妥的演进路径。
Apache代理缓存HTTP/3QUIC修改时间：2026-09-07 20:46:51