CF Tunnel 优选笔记

§2 Cloudflare Tunnel 的出站模型

状态：已可用。证据：官方 Tunnel 文档（[DOC]）+ 本机实测（[MEASURED]）。

2.1 一句话模型

源站不开放任何入站端口；隧道连接由 cloudflared 从内网主动"拨"到 Cloudflare。

官方原文（[DOC]）：Tunnel "provides you with a secure way to connect your resources to Cloudflare without a publicly routable IP address"，cloudflared "creates outbound-only connections to Cloudflare's global network"。 来源：https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/

这条性质带来三个直接后果（小白也能立刻理解）：

后果说明
不用公网 IP、不用在路由器上开端口家里宽带 / NAT 后的机器也能对外提供服务
攻击面收窄防火墙可以"只放行出站、拒绝全部入站"，绕过 CF 的直连被物理切断
回源认证方式变了见 2.4

2.2 术语：tunnel 是对象，connector 是进程

官方术语（[DOC]）：

这句话是理解 Tunnel 性能的基本盘：连接数（connector 数量）与落点（离源站最近的数据中心）是两件独立的事。源站侧能不能吃满带宽，取决于连接数；用户侧快不快，取决于用户到边缘那一跳。

2.3 文档分家（读者最容易迷路的地方）

官方现在把 Tunnel 文档拆成两个入口，内容侧重完全不同（[DOC]）：

入口覆盖范围
https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/私网 / Zero Trust 场景：VPN 替代、访问内网服务、SSH / RDP
https://developers.cloudflare.com/tunnel公开发布 Web 应用 / API 到互联网

教程读者按"Tunnel"搜索时经常落在前者，然后困惑"为什么找不到公开发布的配置"。这点必须显式提示。

2.4 一个官方明确的"反直觉"结论

"Because Cloudflare Tunnel does not use an inbound listener on your origin, [Authenticated Origin Pulls] has no effect on hostnames routed through Cloudflare Tunnel. Origin traffic is already authenticated using your tunnel's connector credentials." —— 官方原文（[DOC]）

即：给走隧道的域名配"源站证书认证（Authenticated Origin Pulls）"是无效操作。回源侧的身份验证靠的是 tunnel 的 connector 凭据（隧道 token / 凭据文件）。

2.5 四跳链路：谁在优化哪一跳

把一次请求拆成四跳，全篇的"优选 / 提速"都必须挂在这张图上，否则读者会把不同链路的优化手段混用：

[用户] ──①──> [Cloudflare 边缘/colo] ──②──> [connector(cloudflared)] ──③──> [本机服务]
                                └──────④ 回源（connector 到源站，通常 localhost）──────┘
跳链路段优化手段归属章节
①用户 → 边缘优选 IP / 优选域名（挑 colo）、平台侧缓存与协议§3 §4 §7
②边缘 → connectorconnector 数量（多进程/HA）、--region/--edge-ip-version 等出站选择§6
③connector → 本机服务极短、通常回环，几乎无优化空间§6 附注
④回源认证走隧道时 Authenticated Origin Pulls 无效（2.4）§2.4

关键判断：如果站点是"用户慢"，问题多半在 ①；如果是"源站慢/超时"，问题在 ③ / 源站自身。两者用同一套手段解决必然无效——这正是社区里"优选了但还是慢"的常见根因。

2.6 connector 的连接模型（官方默认值）

事实官方取值影响
每个 cloudflared 实例的出站连接数4 条仅出站（outbound-only），连到至少两个不同数据中心的四台服务器
增加 replica 时每个 replica 再 +4 条提高可用性的官方路径
replica 之间是否做负载策略不提供 round-robin / hash 流量 steering不要把它当“负载均衡”来设计
--ha-connections官方不存在该参数社区教程里出现的这个参数不可照抄

（来源：官方隧道可用性文档与 Run parameters，[DOC]；详见 §6.1 与 F-062。）

对读者的实际含义：单跑一个 cloudflared 就已经是“4 条连接 + 跨至少两个数据中心”。想更稳 / 更高吞吐，正确做法是加 replica（多进程 / 多机），而不是找“调连接数”的参数。

← §1 Cloudflare 网络的物理模型§3 优选到底在优化哪一跳 →