Caddy IPv6 的 HTTP/3 超时，核对 UDP 回包地址与 AAAA

同一域名用 IPv6 访问，HTTP/1.1、HTTP/2 能返回页面，HTTP/3 却等到超时；换成 IPv4，HTTP/3 又能完成请求。此时需要单独检查 IPv6 的 UDP 路径。TCP 上的 HTTPS 正常，不能证明 QUIC 数据包也能按预期地址往返。

这类现象曾出现在 Caddy 2.6.2、Docker macvlan 和主机同时有多个 IPv6 地址的部署中。它不足以说明所有该版本都有缺陷，也不能直接归因于 Docker。排查时应把 DNS 地址、容器地址、UDP 入包目的地址和出包源地址放在一起比较。

先确认成功的请求确实用了 HTTP/3

查看 curl -V，确认所用构建支持 HTTP/3。当前 curl 的 --http3 允许回退到较早的 HTTP 版本；要隔离 QUIC 连接，使用 curl 7.88.0 起提供的 --http3-only。下面的域名和地址均为示例：

curl -4 -v --http3-only --max-time 15 https://example.com/
curl -6 -v --http3-only --max-time 15 https://example.com/
curl -6 -v --http2 --max-time 15 https://example.com/

检查输出中实际协商的协议、远端地址和响应状态。第三条用于对照 TCP 上的连接，不能代替前两条的结果。不要用 -k 跳过证书校验，也不要把 HTTP/3 不受支持的客户端报错当成服务器超时。

如果域名有多个 AAAA，用已确认属于服务的地址逐个固定目的地，保留原域名用于 SNI、Host 和证书验证：

curl -6 -v --http3-only --max-time 15 \
  --resolve 'example.com:443:[2001:db8::10]' https://example.com/

固定地址的请求正常而普通解析失败，说明还要检查其余 AAAA 或 DNS 缓存；它不能证明整个 IPv6 网络已经恢复。

比较 UDP 的入包与出包

确认 Caddy 实际启用了 HTTP/3，并检查服务所在网络命名空间的 UDP 443 监听。当前 Caddy 的默认协议包含 h1 h2 h3，已有配置仍可能显式限制协议。容器部署还要核对 UDP 端口、macvlan 地址、宿主机路由和防火墙，不能只看 TCP 443。

在获授权的客户端和服务网络内，对同一短时间测试抓取 UDP 443。记录客户端发往哪个 IPv6 地址、服务是否收到 QUIC 初始报文，以及服务回包采用哪个源地址和接口。抓包可能包含网络标识和数据，应保存在私有位置。

如果客户端发往一个固定地址，而服务返回时使用另一个 SLAAC 地址，应继续定位地址选择、路由及中间网络对这组报文的处理。只有看到实际报文，才能把“没有响应”与“响应使用了不符合预期的地址”区分开。

监听地址显示为 :: 本身不能证明回包一定会选错源地址。Caddy 2.6.2 对应的 quic-go 0.29.2 已有读取目的地址与接口信息、用于发送回包的实现；自定义构建、操作系统和网络路径仍需按实际环境检查。仅凭通配监听就断定内核随意选择地址，会跳过真正的证据。

修正经过验证的服务地址

若确认 AAAA 指向的地址与可正常提供 QUIC 的稳定服务地址不一致，可以修正该记录。先核对地址属于预期实例、能长期保留，并确认 IPv6 防火墙及返回路由允许访问。不要把临时地址写入长期 DNS，也不要因为一次成功就直接删除其他实例的记录。

保留修改前的记录和 TTL。修改后，用固定地址和普通域名分别验证 IPv6 HTTP/3，再对照 IPv4、HTTP/2 及证书验证。DNS 缓存尚未过期的客户端可能继续访问旧地址，应分别判断。

如果没有观察到回包地址异常，继续检查 UDP 丢包、路由、地址族相关防火墙和实际 Caddy 构建。改成 host 网络模式或升级软件会同时改变多个条件，不能把偶然恢复当成已找到根因；也没有依据承诺某个版本可以修复所有 IPv6 HTTP/3 超时。