Cloudflare Tunnel IPv6 访问超时问题分析与解决报告

一、问题背景

在服务器上部署了基于 Cloudflare Tunnel（cloudflared） 的反向代理，用于通过 Cloudflare 网络公开本地服务（Alist）。

服务器使用 IPv6 + DDNS 提供外网访问。该配置在过去运行正常，后期出现部分 IPv6 访问请求超时的问题。

二、问题现象

通过 直接访问 IPv6 + DDNS（未经过 Cloudflare Tunnel）时，服务正常可访问。
通过 Cloudflare Tunnel 域名访问时，IPv6 请求出现超时（timeout）。
IPv4 用户访问一切正常。
Cloudflare Tunnel 状态显示为 HEALTHY，连接正常。

示例命令输出：

cloudflared tunnel info alist-tunnel
ORIGIN IP: 120.230.250.124
EDGE: 1xlax01, 1xlax06, ...

其中 ORIGIN IP 为 IPv4 地址。

三、问题分析

经过排查，确认问题不在 DDNS、服务进程（Alist）或网络层，而是由 Cloudflare Tunnel 的出口协议选择机制变化 引起。

1. 原始配置

protocol: h2mux

旧版 cloudflared 使用 h2mux (HTTP/2 Multiplexed) 协议建立隧道。

该协议基于 TCP/HTTP2，自动支持 IPv6，无需显式配置。

2. 新版配置与变化

在新版 cloudflared 中，默认推荐：

protocol: auto

该模式会优先启用 QUIC (HTTP/3 over UDP)。

新的 QUIC 实现默认优先使用 IPv4 出口，仅在显式配置时才启用 IPv6。

因此，在未配置 edge-ip-version 的情况下：

Tunnel 出口始终为 IPv4；
Cloudflare 边缘节点与 IPv6 客户端通信时无法回传流量；
导致 IPv6 访问超时。

3. 验证结论

运行 cloudflared tunnel info 显示 ORIGIN IP 为 IPv4，验证了隧道未使用 IPv6 通道。

而 Alist 实际监听在 *:5244（双栈），可确认问题与服务端口无关。

四、问题根因

Cloudflare 在新版本 cloudflared（2024 年起）中修改了 Tunnel 出口协议族的默认行为。

旧版 h2mux：自动 IPv6 优先。
新版 auto / quic：默认 IPv4 优先。
未显式设置 edge-ip-version 时，IPv6 路径不启用。

五、解决方案

1. 修改配置文件 `/etc/cloudflared/config.yml`

原配置：

protocol: auto

修改后：

protocol: auto
edge-ip-version: auto   # 自动启用 IPv6，如果可用则优先使用 IPv6

ingress:
  - hostname: alist.050626.xyz
    service: http://localhost:5244
  - service: http_status:404

2. 重启 cloudflared 服务

sudo systemctl restart cloudflared

3. 验证结果

执行：

cloudflared tunnel info alist-tunnel

应出现：

ORIGIN IP: 2409:xxxx:xxxx::xx
EDGE: ...

说明隧道已通过 IPv6 建立连接，IPv6 外部访问恢复正常。

六、结论与建议

项目	结果
问题根因	Cloudflare Tunnel 新版默认仅启用 IPv4 出口
影响范围	IPv6 外部访问请求全部超时
临时解决	使用旧协议 `h2mux`（不推荐，未来将弃用）
推荐解决	添加 `edge-ip-version: auto` 并保留 `protocol: auto`
建议措施	后续保持 cloudflared 更新，并监控官方变更日志

七、附录

cloudflared 版本：2025.10.1
Tunnel ID：d2e4cdb7-6efb-411b-b95f-ecefe9f88091
操作系统：Linux (amd64)
服务监听端口：5244 (IPv4/IPv6 双栈)

总结一句话：

Cloudflare Tunnel 由 h2mux 切换至 QUIC 后，默认仅使用 IPv4 出口，需手动添加 edge-ip-version: auto 以恢复 IPv6 支持。