Cloudflare Tunnels无法建立隧道的问题

2023 年那次故障里，cloudflared 容器一直报 QUIC 连接超时，网站随之掉线。指定 HTTP/2 后恢复了连接。这个处理可以作为诊断办法，但不能据此认定运营商屏蔽 UDP，也不能认为当前版本不会自动回退。

日志说明了什么

当时的关键报错是：

TEXT

Failed to create new quic connection
failed to dial to edge with quic: timeout: no recent network activity

它说明这次 QUIC 连接没有成功，不能单凭这两行断言一定是运营商屏蔽 UDP。主机防火墙、路由器、网络策略和当时的链路情况都可能需要排查。

QUIC 基于 UDP，cloudflared 使用 QUIC 时需要出站 UDP 7844；HTTP/2 使用出站 TCP 7844。当前 --protocol auto 是默认值，会尝试 QUIC，并在无法建立时回退到 HTTP/2。不要把持续的 QUIC 超时理解为软件不支持自动切换。

临时指定 HTTP/2

如果日志持续是 QUIC 超时，可以显式指定 --protocol http2，观察是否恢复。下面使用 token 文件，避免把 tunnel token 直接写在 Compose 命令里：

YAML

services:
  cloudflared:
    image: cloudflare/cloudflared:latest
    restart: unless-stopped
    command: tunnel --no-autoupdate --protocol http2 run --token-file /run/secrets/tunnel_token
    volumes:
      - ./tunnel-token:/run/secrets/tunnel_token:ro

--token-file 需要 cloudflared 2025.4.0 或更新版本。先准备包含自己 token 的真实文件，并设置仅必要账户可读的权限；还要确认容器运行用户能读取它，不能只对 root 可读却让非 root 容器来打开。不要把该文件提交到 Git 或同步到公开目录。

BASH

docker compose up -d
docker compose logs --tail=100 cloudflared

重建容器前确认自己有可用的管理入口。成功日志应能看到 Registered tunnel connection 以及所用协议；这是观察方法，不是本文新执行过的结果截图。

HTTP/2 也需要相应 TCP 出站连接。如果 TCP 7844 同样被阻断，换参数不能解决。Tunnel 不要求给家中路由器添加入站 7844 端口映射。

隧道在线，网站却仍打不开

cloudflared 到 Cloudflare 边缘的连接正常，只说明第一跳正常。还要检查 cloudflared 能否访问自己配置的源站。

如果 cloudflared 在 Docker 里，源站写 localhost 指向的是它自己的容器，不是 NAS。源站是另一容器时，放在合适的同一 Docker 网络并使用服务名；源站在局域网机器上时，使用从容器实际可达的地址与端口。再检查源站协议和证书，而不是直接关掉所有证书校验。

本文结合当年的故障经过说明当前默认协议行为、端口与凭据处理。配置示例经文档核对，未在真实 Tunnel 上实机测试。

参考：运行参数、防火墙要求。