§3 「CF 优选」到底在优化哪一跳

状态：已可用（证据全部来自本机实测 E-01 ~ E-08，见 notes/research/local-measurements.md）

3.0 先立结论

优选优化的是「用户 → Cloudflare 边缘」这一跳，与 Cloudflare Tunnel 的出站链路无关。

这句话是全篇最重要的分界线。它直接决定了两件事：

Tunnel 用户做优选是有意义的：用户访问你的域名时先要连到 CF 边缘，这一跳的质量由"你被解析/指向到哪个边缘 IP"决定。
优选不能替代任何 Tunnel 侧配置：源站回源、隧道连接数、协议选择、区域归属，都是另一条链路的事，优选一个字节都优化不到。

3.1 为什么"优选 IP"在技术上成立

Cloudflare 边缘是 anycast，且按 SNI / Host 路由：请求打到哪个边缘 IP 不重要，重要的是 TLS SNI 和 HTTP Host 是哪个站点。

实测（E-01）：把 www.tagzxia.com 硬指向 5 个跨网段的 CF 边缘 IP，全部正常返回该站点响应。

curl -s --resolve www.tagzxia.com:443:172.64.144.199 https://www.tagzxia.com/cdn-cgi/trace

输出里 h=www.tagzxia.com、colo=HKG 说明边缘认了这个 Host 并把请求交给了对应的配置。

但有前提（E-02）：只有托管在 Cloudflare 的 zone 下的 Host 才享受这个待遇。

curl -s -o /dev/null -w 'code=%{http_code}\n' --resolve www.baidu.com:443:104.16.148.10 https://www.baidu.com/cdn-cgi/trace
# → code=000   非 CF 站点，边缘直接拒绝

3.2 优选真正在挑的是「落点（colo）」，不是"更快的域名"

实测（E-01）同一个客户端、同一个目标域名，只换边缘 IP：

边缘 IP	观测到的落点
`172.64.144.199`	`colo=HKG`
`104.18.42.163`	`colo=HKG`（`sliver=050-tier1`）
`104.26.12.54`	`colo=SEA`

40 个候选 IP 的完整扫描（E-06）结果：本机（中国大陆电信出口）绝大多数落在 HKG，少量 SEA。

所以「优选」的实际含义是：在一堆候选 IP 里，找出那些把你这台机器送到较近 / 较健康边缘的 IP。这也是为什么它因运营商、因地区、因时间而完全不同——脱离测速谈"哪个优选域名最好"没有意义。

3.3 「优选域名时灵时不灵」的两个真实成因

社区里普遍把原因归结为"域名被封了"。实测表明至少还有两个更基础、更常见的成因：

成因一：DNS 解析答案 ≠ 站点实际接入点（E-04）

tagzxia.com 的实测记录结构：

dig +short NS tagzxia.com            # → macy.ns.cloudflare.com. jaziel.ns.cloudflare.com.   zone 在 CF
dig +short A  tagzxia.com            # → 121.199.28.231     阿里云源站，灰云(DNS only)记录
dig +short A  tagzxia.com @macy.ns.cloudflare.com   # → 121.199.28.231   权威一致
dig +short A  www.tagzxia.com        # → 172.67.177.44 104.21.80.101      橙云(代理)

「zone 在 Cloudflare」不等于「这条记录被 Cloudflare 代理」。灰云记录会把真实源站 IP 直接交给客户端，而 --resolve 类优选测速针对的是橙云记录。把这两种记录混在一起测，就会得到"有时通有时不通"的结果。

这条在我的排查过程中真实发生过：我最初把它的成因推断为"本机 DNS 被污染"，随后用权威 NS + 5 个独立解析来源（本机 / 223.5.5.5 / 119.29.29.29 / AliDNS DoH / Cloudflare DoH）交叉验证，推翻了该推断——五个来源完全一致。记录在此，作为"先做对照实验再下结论"的范式。

成因二：候选清单里混着根本不提供 HTTP 反代的 IP（E-07）

扫描中 cf.008500.xyz 解析出的 4 个 IP 全部 0/2：

dig +short -x 173.245.58.242    # → zelda.ns.cloudflare.com.
dig +short -x 162.159.25.237    # → ns4.supercp.com.
curl -s -o /dev/null -w 'code=%{http_code} conn=%{time_connect}\n' \
  --resolve www.tagzxia.com:443:162.159.15.183 https://www.tagzxia.com/cdn-cgi/trace
# → code=403 conn=0.000538      ← 连接极快但被 HTTP 403 拒绝，不是超时

403 而不是超时是关键判据：IP 是活的、边缘也响应了，但它不服务普通 HTTP 代理流量（173.245.58.242 的 PTR 直接是 Cloudflare 权威 DNS 服务器 zelda.ns.cloudflare.com）。

这类 IP 在 ping / TCP 握手测速里表现极好，在真实 HTTPS 请求里必然失败——只测延迟不测 HTTP 成功率的脚本一定会把它们选进来。

成因三（次要但真实）：单 IP 的成败本身有随机性（E-08）

扫描中 104.16.149.3 成功率 0/2，紧接着复测 code=200。中国大陆出口下单个 IP 的成败带有随机性，因此：

必须多次采样并报告成功率
不能用平均值排序（E-06：104.19.54.2 平均 2.506 s、最快 0.493 s，均值被抖动污染）
结果必须定期重跑

成因四（中国大陆特有）：线路可能只优化 ICMP、或只优化小包

这是国内环境的结构性陷阱：ping 与 traceroute 走 ICMP，而真实 HTTP 流量的待遇可以与之不一致。

现象	机制	后果
`ping` 很漂亮，实际下载很慢	存在仅对 ICMP 优化的线路	用延迟排序会系统性选错
路由看着很好，一到大流量就劣化	商家只优化小包（ping / 路由好看），大流量走劣质线路	小文件测试通过、真实业务崩
白天正常，晚高峰骤降	国际出口拥堵；QoS 优先保优化网、普通线路被降级	“时灵时不灵”的另一个成因

（来源：M-022 线路科普 + M-024 术语表“大小包 / 竞技场 / 晚高峰”；[COMMUNITY]，与 E-06 / E-08 的实测抖动互为印证。）

因此判据必须落在 HTTPS 结果，并且分时段复测：单次的“延迟好看”在任何一条上都会被推翻。

3.4 一章速记

问题	答案
优选优化哪一跳	用户 ↔ CF 边缘（第一跳）
优选不能优化什么	Tunnel 出站、回源、源站健康
优选到底在挑什么	把你送到较近 / 较健康 colo 的 IP
判定手段的硬门槛	必须测 HTTPS 成功率，不能只看延迟
排序指标	最快 TTFB 或多次采样中位数，不要用单次/平均
合法性前提	目标 Host 必须托管在 Cloudflare 且为橙云记录

关于 /cdn-cgi/trace 各字段的官方语义：见 §1.3——只有 colo 有官方定义，sliver / loc 等属于社区经验解读，教程不得当作官方契约。