Apache httpd 长期以来在反向代理场景中扮演着重要角色，借助 mod_proxy 和 mod_cache 可以构建出稳定的缓存层。随着 HTTP/3 与 QUIC 的普及，越来越多的边缘节点需要接收基于 UDP 的流量并继续承担代理缓存职责。Apache 官方从 2.4.53 版本开始提供 mod_http3 实验模块，但这并不意味着带缓存的反向代理可以开箱即用。把 mod_http3、mod_proxy 和 mod_cache 组合起来，需要重新理解监听端口、协议协商、缓存键和连接复用等细节。本文会给出可落地的配置方案，并分析这一架构下常见的故障原因。
一、HTTP/3 在 Apache 中的运行机制与模块依赖
HTTP/3 不再依赖 TCP，而是基于 QUIC 协议在 UDP 上进行多路复用传输。与 HTTP/2 相比，它从传输层上消除了队头阻塞，因此在弱网或高延迟场景下能更快恢复。Apache httpd 的 mod_http3 模块使用了 ngtcp2 和 nghttp3 两个库来实现 QUIC 和 HTTP/3 协议栈，因此编译前必须确保这两个库及其开发头文件已经安装。
启用 HTTP/3 的 Apache 通常运行在 event MPM 模式下，因为 QUIC 连接需要异步 socket 处理，不能被传统的 prefork 或 worker 模型阻塞。构建参数中要显式加入 --enable-http3，同时还需要开启 proxy 和 cache 相关模块。稍后配置文件中需要加载 mod_http3、mod_proxy、mod_proxy_http、mod_cache 和 mod_cache_disk。
# 安装 QUIC 相关依赖
sudo apt install libngtcp2-dev libnghttp3-dev libngtcp2-crypto-gnutls-dev
# 编译 Apache httpd
./configure \
--enable-http3 \
--enable-proxy \
--enable-cache \
--enable-cache-disk \
--enable-proxy-http \
--enable-ssl \
--with-ssl=/usr \
--with-ngtcp2=/usr \
--with-nghttp3=/usr
make -j$(nproc)
sudo make install
编译完成后，还需要在监听层面同时打开 TCP 443 和 UDP 443。客户端第一次访问时可能先走 HTTP/2 或 HTTP/1.1，服务器会在响应中返回 Alt-Svc 头，告诉客户端下次可以尝试 h3。因此 alt-svc 的生成与缓存策略会直接影响 HTTP/3 的升级率。
二、配置反向代理与磁盘缓存的完整示例
下面是一个典型配置片段，Apache 同时承载 QUIC 入口和反向代理缓存。需要说明的是，多数后端服务并未升级到 HTTP/3，因此 mod_proxy 默认仍以 HTTP/1.1 或 HTTP/2 回源，这并不影响前端 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
Listen 443
Listen 443 quic
<VirtualHost *:443>
ServerName edge.ipipp.com
Protocols h2 http/1.1
H3Protocols h3
SSLEngine on
SSLCertificateFile /etc/pki/tls/certs/edge.crt
SSLCertificateKeyFile /etc/pki/tls/private/edge.key
# 反向代理到后端
ProxyPass /backend http://10.0.2.15:8080/backend
ProxyPassReverse /backend http://10.0.2.15:8080/backend
# 磁盘缓存配置
CacheEnable disk /backend
CacheRoot /var/cache/apache2/mod_cache_disk
CacheDefaultExpire 3600
CacheMaxExpire 86400
CacheIgnoreNoLastMod On
CacheQuickHandler off
CacheLock on
CacheLockPath /tmp/apache-cache-lock
CacheLockMaxAge 5
CacheHeader on
CacheDetailHeader on
</VirtualHost>
在这个配置中，CacheQuickHandler off 是最容易忽略的一项。如果不关闭快速处理，Apache 会在代理模块之前直接把请求交给缓存处理，导致带查询参数或需要回源的请求无法正确进入代理逻辑。对于 HTTP/3 请求同样如此，这个指令必须显式设置为 off。
另一个值得关注的是 CacheIgnoreNoLastMod On。许多动态后端并不返回 Last-Modified 头，如果保持默认值，这些响应根本不会被缓存。开启该指令后，只要响应没有 Cache-Control: no-store 或 Set-Cookie 等禁止缓存的头，mod_cache 就会按照默认过期时间进行缓存。对于 API 响应，还可以配合 CacheStorePrivate On 将带 Authorization 的响应短暂缓存，但需要评估安全风险。
针对 HTTP/3 的特殊性，缓存键通常不包含入口协议。也就是说，同一个资源无论通过 HTTP/2 还是 HTTP/3 进入，都可能命中同一份缓存。这有利于提高缓存命中率，但也要注意 Vary 头是否覆盖了 Alt-Svc 或 QUIC 相关字段。如果后端返回了错误的 Vary，可能导致客户端拿到不适合其协议的缓存内容。
三、验证升级效果与常见故障排查
配置完成后，首先可以用 curl 验证 HTTP/3 是否生效。较新版本的 curl 支持 --http3 参数，执行下面的命令观察响应头和握手信息。
curl --http3 -I https://edge.ipipp.com/backend/foo # 查看详细握手过程 curl --http3 -v https://edge.ipipp.com/backend/foo
如果响应中出现 Alt-Svc: h3=":443"; ma=86400 和 Age 头，说明 HTTP/3 升级提示和缓存都在工作。Age 头表示该缓存副本已经存活的时间，如果多次请求后 Age 仍然为 0，说明没有命中缓存。此时需要检查编解码日志，确认缓存模块是否真的接管了请求。
抓包也是定位问题的有效手段。使用 tcpdump 捕获 UDP 443 端口的流量，再用 Wireshark 的 QUIC 协议解析器查看连接建立过程。如果客户端始终回退到 TCP，首先检查服务器是否在首个 HTTP/2 或 HTTP/1.1 响应中发送了 Alt-Svc，其次确认防火墙是否放行 UDP 443，以及负载均衡器是否支持 QUIC 会话保持。
另一个常见错误是在启动时出现 AH03003: mod_http3: unable to bind socket。这通常是 UDP 443 已被其他进程占用，或者系统 ulimit 设置过低。可以用 ss -lunp | grep 443 找出占用进程。还需要确保 Apache 以足够权限启动，并且开启了 UDP 相关内核参数。
四、性能权衡与架构落地建议
HTTP/3 的 0-RTT 连接恢复可以显著减少重复访问时的握手延迟，但该特性也存在重放攻击风险。在反向代理场景中，如果后端资源包含敏感状态变更，建议谨慎开启早期数据。可以通过 SSLearlydata 指令控制是否允许 0-RTT 请求。
对于缓存本身，使用磁盘缓存适合小规模节点，但如果边缘节点流量较大，可以考虑使用 mod_cache_socache 将缓存放入内存。无论采用哪种存储，都要设置合理的 CacheLockMaxAge，避免在缓存失效瞬间出现大量回源请求。尤其在 HTTP/3 下，UDP 连接更多、更轻量，客户端重试频率可能提高，缓存击穿的负面影响会被放大。
最后，如果网络中还存在资源受限的终端模块，例如基于嵌入式 RTOS 的 EMW3080 Wi-Fi 模组，它们通常没有能力直接运行 Apache 或处理 QUIC 流量，只能作为普通客户端接入。HTTP/3 反向代理缓存层应当部署在边缘网关或标准服务器上，终端模块通过 HTTPS 或 HTTP/3 客户端库访问代理节点。这样可以在不改造终端硬件的前提下，让整体链路享受 QUIC 带来的体验提升。
Apache代理缓存HTTP/3QUIC修改时间：2026-10-01 13:12:31