Cloudflare Tunnel
优选 · 提速 · 网络与服务全景
一份给「从 0 开始」的整理稿
为什么大家都愿意把域名托管在 Cloudflare
以及「照教程配了优选，为什么还是不快」
官方文档 [DOC] 本机实测 [MEASURED] 社区素材 [COMMUNITY]
→ 方向键翻页 · O 概览 · F 全屏
开场这份材料回答三个问题
| 疑问 | 结论（本材料的立场） | 章节 |
|---|---|---|
| 「优选到底在优化什么？」 | 只优化用户 → CF 边缘这一跳；与 Tunnel 出站、回源、源站健康都无关 | §3 |
| 「为什么我优选了还是慢？」 | 四类成因：IP 根本不可用 / 域名没托管在 CF / IP 级抖动 / 只优化 ICMP·小包 | §3.3 |
| 「CF 到底提供哪些服务？」 | 网络与安全、Zero Trust、开发者平台、媒体与其它——且免费边界要逐项确认 | §8 |
核心原则：先把「慢」拆到跳数上，再谈优化手段。用错跳的手段，一定无效。
地基 1一次请求的四个角色
- 域名：你买的地址（注册商 ≠ 解析商）
- 解析（NS）：谁来回答「这个名字指向哪」
dig +short NS example.com - 边缘（anycast）：同一 IP 在全球多地宣告，BGP 决定你去哪
- 源站：真正装着内容的那台机器
看懂这四层，就能看懂后面所有「优化」到底改的是哪一层。
地基 2anycast 与 colo
anycast：一个 IP 在多地同时「宣告」，用户被路由到拓扑上就近的机房。
- 所以「同一个域名，在不同城市解析到不同边缘」是正常现象
- 机房的成绩单字段是
colo（三字码，如HKG/NRT/SJC） /cdn-cgi/trace能看落点，但——
⚠️ trace 绿 ≠ 站点健康：trace 由边缘生成，不经过源站。源站挂了，trace 照样 200。
地基 3小黄云 vs 灰云：决定一切
| 橙云（Proxied） | 灰云（DNS only） | |
|---|---|---|
| DNS 返回 | CF 边缘 IP | 你自己服务器的 IP |
| 流量是否经 CF | 是 | 否 |
| 优选是否可能生效 | 是 | 绝无可能 |
| 源站是否暴露 | 否 | 暴露 |
dig +short NS example.com # 是 *.ns.cloudflare.com 吗？
dig +short A example.com # 返回的是 CF 边缘还是你自己的 IP？实测里最容易被忽略的一步：「域名在 CF」≠「记录被代理」。
Tunnel它是什么
cloudflared从你机器主动出站连到 CF 边缘，建立一条持久隧道- 源站不需要公网 IP、不需要开入站端口——这也是它流行的首要原因
- 反向代理的身份验证靠隧道凭据，不是源站证书
所以：给「走隧道的域名」配 Authenticated Origin Pulls 是无效操作（官方明确说明）。
Tunnelconnector 的连接模型（官方默认值）
| 项目 | 官方取值 |
|---|---|
| 每个 cloudflared 实例 | 4 条仅出站连接，连到至少两个不同数据中心的四台服务器 |
| 增加 replica | 每个 replica 再 +4 条 |
| replica 间负载策略 | 官方不提供 round-robin / hash steering |
--ha-connections | 不存在这个参数（社区教程里的属于不可照抄） |
要更稳 / 更高吞吐 → 加 replica，而不是找「调连接数」的开关。
全篇最重要的一张图四跳链路：谁优化哪一跳
[用户] ─①──> [CF 边缘 / colo] ──②──> [connector(cloudflared)] ──③──> [本机服务]
└──────④ 回源 ──────┘| 跳 | 链路段 | 优化手段 | 章节 |
|---|---|---|---|
| ① | 用户 → 边缘 | 优选 IP / 优选域名、平台侧缓存与协议 | §3 §4 §7 |
| ② | 边缘 → connector | replica 数量、--region/--edge-ip-version | §6 |
| ③ | connector → 本机服务 | 通常是回环，几乎无优化空间 | §6 |
| ④ | 回源认证 | 走隧道时 AOP 无效 | §2.4 |
「用户慢」看 ①；「源站慢 / 超时」看 ③ 与源站本身。两者不能用同一套手段解决。
优选 · 前提它为什么能生效，什么时候一定不生效
- 边缘按 SNI / Host 路由 → 这是优选能成立的根本原因
- 前提条件：目标域名托管在 Cloudflare，且该记录是橙云
| 情况 | 优选效果 |
|---|---|
| 域名 NS 不是 Cloudflare | 不生效 |
| 记录是灰云 | 不生效 |
| 橙云 + 托管在 CF | 生效（但要看下面四类成因） |
优选 · 方法判据必须是 HTTPS 结果，不是延迟
curl -s -o /dev/null -w 'code=%{http_code} conn=%{time_connect} ttfb=%{time_starttransfer}\n' \
--resolve www.example.com:443:<候选IP> https://www.example.com/cdn-cgi/trace| 结果 | 含义 | 处置 |
|---|---|---|
200 + colo=XXX | 可用 | 记录 colo 与 TTFB |
403 + error code: 1034 | 受限 IP 空间，非授权账户不可用 | 剔除，别重试 |
403 + 1003 | Direct IP Access Not Allowed | 检查 Host / SNI |
000 | 超时 / 连接失败 | 按成功率剔除 |
525 | 边缘连上源站但回源 TLS 失败 | 源站问题，不是优选问题 |
优选 · 成因为什么它「时灵时不灵」
| 成因 | 机制 | 判据 |
|---|---|---|
| 一：IP 不可用 | 受限 IP 空间（专用 IP / BYOIP）返回 403 + 1034 | 必须看错误码 |
| 二：前提不成立 | 域名没托管在 CF，或记录是灰云 | dig NS + dig A |
| 三：IP 级抖动 | 同一 IP 前一刻失败、后一刻 200 | 多次采样 + 成功率 |
| 四：只优化 ICMP / 小包 | ping 好看、大流量走劣质线路；晚高峰 QoS 降级 | 用 HTTPS 测，分时段复测 |
排序用最快 TTFB 或中位数，不要用平均值（实测：均值 2.506 s 的 IP 最快只要 0.493 s）。
优选 · 落地三种架构，一种禁止
| 架构 | 做法 | 适用 |
|---|---|---|
| A 全量 CNAME | 业务域名 CNAME 到优选域名 | 简单，但第三方可随时改路 |
| B 分地区解析 | 分线路解析到不同优选目标 | 有明确地区差异时 |
| C 本机落地 | hosts 或本地 DNS 优选（smartdns） | 验证阶段首选；不动生产 DNS |
| D | 把优选 IP 直接写进 A 记录 | 禁止：官方明确不支持 |
优选的本质是「要有人持续测」：IP 会失效，必须定期重跑。
优选 · 官方契约Cloudflare for SaaS 的标准链路
客户自定义主机名 ──CNAME──> 你的 SaaS target ──> fallback origin（回退源）- 官方做法：客户的域名 CNAME 到你的 target
- 社区「优选」做法常与此有偏差 → 属于自担风险，本材料只陈述差异，不替你下结论
另一个常被忽略的事实：走自定义主机名后，客户 zone 无法控制 Argo / Early Hints / Page Shield / Spectrum / 通配 DNS。
优选 · 必读踩坑两个会让人通宵的坑
① 优选与 Access 应用策略的账号级冲突
社区实测：同一账号下，SaaS 回源优选与 Access 应用策略不能同时生效 → 需把「被访域名」与「回源域名」分到不同账户。
② 回源域名能被人直连访问
用户 → 业务域名（经优选，受 Access 保护） ← 正常路径
攻击者 → 回源域名（直连，绕过 Access 与优选） ← 必须「阻止」正解：在安全规则里对回源域名下「阻止」——优选依旧生效，同时挡掉直连与恶意流量。
提速 · connectorcloudflared 能调的只有这些
| 参数 | 默认 | 作用 |
|---|---|---|
--protocol | auto | 自动 QUIC；UDP 建连失败回退 HTTP/2（QUIC=UDP:7844，HTTP/2=TCP:7844） |
--edge-ip-version | 4 | 出站地址族（auto/4/6） |
--region | global | 当前只有 us，全走美国数据中心（专用主机名/IP） |
--post-quantum | — | QUIC 默认 PQC 且可回退；显式指定则只允许 PQ；HTTP/2 不支持 PQ |
--autoupdate-freq | 24h | ⚠️ 自动更新会重启且不等新连接就位 → 连接中断 |
🔴 纠正社区说法：官方没有「QUIC 被限速必须切 http2」。官方只说了两种可测 http2 的情形：UDP 建连失败、UDP 空闲超时致长连接掉线。
提速 · 平台各项到底优化哪一段
| 能力 | 优化对象 | 免费边界 |
|---|---|---|
| Argo Smart Routing | 边缘 → 源站（不是第一跳！） | 付费 |
| Tiered Cache | 缓存未命中时的上层回源 | Free 亦可用 |
| Cache Reserve | 长期占用边缘存储 | 付费 |
| China Network | 境内节点 | 企业版 + 备案要求 |
「过了 CF 就不存在优化」是错的；「免费也能做到专线级」也是错的。
服务全景Cloudflare 提供哪些服务
- 网络与安全：DNS、CDN、WAF、DDoS、Spectrum、Magic Transit、Bot Management…
- Zero Trust / One：Access、Gateway、WARP / One Client、Browser Isolation、Mesh 组网…
- 开发者平台：Workers、Pages、R2、D1、KV、Queues、Durable Objects、AI Gateway、Vectorize…
- 媒体与其它：Stream、Images、Calls、Zaraz、Turnstile、Radar、Logpush、Registrar…
- Tunnel / Argo / Load Balancing / Waiting Room / Cache Reserve…
教程里所有「免费能做 / 不能做」的判断，都必须在定价与边界处逐项确认，不靠记忆下结论。
WARP它解决的问题，和它最大的陷阱
- 它把设备的出站流量接入 CF 网络的加密出口；消费者版 与 Cloudflare One Client（企业版）是两条线
- 正当用途：出口 IP、给只有 v4/v6 的主机补另一栈、防出站泄露源站、容器化给应用注入代理
⚠️ 最大陷阱：默认排除模式 ≈ 全局代理。正确做法是改成包含模式，只让
100.96.x（CF 私网段）走隧道；否则它会把你的出站流量整体改道。另外：WARP ≠ 干净 IP——IP 定位异常（“送中”）会让很多服务直接不可用；与 Tunnel 同机部署还可能因路由改写导致断连。
排错五条判据，先取证再改配置
/cdn-cgi/trace绿 不代表站点健康525= 回源 TLS 失败（源站问题）403+1034= 受限 IP，剔除- 连接建立后立即被重置 = SNI/Host 阻断特征，不是配置错误
- 「配好了却 404」先看隧道面板的 CatchAll
traceroute -A <IP> # 看 ASN
traceroute -T <IP> # ICMP 被屏蔽时用 TCP
mtr -r -c 100 <IP> # 丢包率一目了然结语三句话记住这份材料
- 拆跳：先说清是哪一跳慢，再选手段
- 取证：判据落在状态码与成功率上，不落在 ping 上
- 留痕：每条结论标注来源等级，被证伪的推断也留在台账里
想继续读 → 知识库（从 0 小白入手，14 章）
想看我们整理了哪些东西 → Thanks / Reference