Cloudflare Tunnel由cloudflared从内网主动连接边缘，因此通常不需要把本地Web端口直接暴露公网。但链路仍有两段：cloudflared到Cloudflare边缘，以及cloudflared到本地Origin。Tunnel状态Healthy，只能证明第一段基本可用。
Tunnel的两段路径
| 路径 | 方向 | 重点检查 |
|---|---|---|
| cloudflared到边缘 | 主动出站 | DNS、QUIC/TCP、企业代理与Token |
| cloudflared到Origin | 内网请求 | 服务地址、端口、Host、TLS和应用状态 |
QUIC为什么容易被企业网络阻断
QUIC基于UDP，传统HTTP正向代理只能处理TCP上的HTTP或CONNECT，不能直接转发UDP QUIC。防火墙或出口不允许UDP时，cloudflared可按产品能力使用TCP类传输。具体协议选项应以当前版本为准，不要用未知UDP隧道规避网络政策。
HTTP/2回退需要什么
TCP传输仍需DNS、TLS和到边缘端口的出站连接。若经过企业HTTP代理，还要确认cloudflared版本是否支持相应代理方式，以及CONNECT、认证和证书策略。407与Cloudflare Tunnel Token错误属于不同层。
Token和凭据如何保护
远程管理Tunnel常使用Token或凭据文件。它们应保存在systemd EnvironmentFile、容器Secret或权限受限文件中，不出现在公开命令、截图和日志。泄露后应立即轮换，并检查是否出现未知Connector。
Healthy为什么仍返回502
边缘把请求交给Connector后，cloudflared无法连接Origin会返回502。常见原因包括Origin未监听、地址写成错误localhost、容器网络不通、协议写错、证书不受信任或Host头不符合应用路由。
容器中的localhost指向哪里
cloudflared运行在容器时，localhost指该容器自身。Origin在另一个容器或宿主机时，应使用明确服务名或受控宿主地址，并配置容器网络。不要为了省事让Origin监听所有网卡且无认证。
Origin使用HTTPS时检查什么
cloudflared需要验证Origin证书。自签或企业CA应通过受支持方式提供信任，证书主机名应与连接目标一致。跳过Origin TLS验证会削弱第二段身份保障，只适合短时隔离诊断。
负载均衡和多个Connector怎么验证
生产Tunnel通常运行多个Connector，以避免单实例故障。实例可能位于不同主机、子网或配置版本。应记录Connector ID、地区、连接协议和Origin健康，模拟单实例退出并确认流量继续。
DNS错误发生在哪侧
cloudflared需要解析Cloudflare边缘相关域名，也可能需要解析内网Origin服务名。两者DNS来源可以不同。企业代理可达不代表DNS正确；容器的resolv.conf和搜索域也可能与宿主不同。
真实客户端IP和代理头如何处理
Origin看到的直接来源通常是cloudflared。应用若使用Cloudflare提供的客户端IP头，应只信任来自受控Tunnel或反向代理的请求，并防止外部直连伪造。Origin最好限制为仅受控网络可达。
排查顺序
- 记录cloudflared版本、Connector与传输协议；
- 验证DNS、UDP或TCP出站和代理认证；
- 区分边缘连接、Token和Origin 502；
- 从cloudflared运行环境访问Origin；
- 核对Origin协议、Host和证书；
- 测试多个Connector的故障切换；
- 轮换测试Token并清理详细日志。
QUIC受阻后切换TCP传输的协议背景，可参考QUIC、CONNECT与HTTP/2回退。
结论
Cloudflare Tunnel代理故障需要拆分边缘出站和Origin内网两段。QUIC与HTTP代理协议不同，第一段Healthy也不代表第二段可用；结合Connector日志和Origin测试才能准确定位。
