§1 Cloudflare 网络的物理模型
状态：基本可用。§1.3 的字段官方语义待
notes/research/optip-boundaries.md补入。 证据：官方文档 [DOC] + 本机实测 [MEASURED]（E-01、E-02、E-05、E-07）
1.1 anycast：为什么同一个域名在不同地方解析到不同 IP
Cloudflare 的每一个"边缘 IP"都不是某台机器的地址，而是一个 anycast 地址：同一个 IP 在全球多个机房同时被宣告，BGP 决定你的包走哪个机房。
对小白最直观的类比：
打客服电话
400-xxx，号码全国只有一个，但你人在北京接到的是北京坐席、人在上海接到的是上海坐席。
Cloudflare 官方公布的 IPv4 前缀（[DOC]，https://www.cloudflare.com/ips-v4 ）：
173.245.48.0/20 103.21.244.0/22 103.22.200.0/22 103.31.4.0/22
141.101.64.0/18 108.162.192.0/18 190.93.240.0/20 188.114.96.0/20
197.234.240.0/22 198.41.128.0/17 162.158.0.0/15 104.16.0.0/13
104.24.0.0/14 172.64.0.0/13 131.0.72.0/22一个重要但常被误解的点（实测 E-07）："IP 属于上面这些前缀" ≠ "这个 IP 会为你的网站代理流量"。实测 162.159.x / 173.245.58.242 都在公布前缀内，对站点请求却返回 403 + error code: 1034（受限 IP 空间）。挑选 IP 必须实测，见 §4。
1.2 边缘按 SNI / Host 路由（优选 IP 的合法性来源）
请求打到哪个边缘 IP 不重要，重要的是 TLS 握手里的 SNI 和 HTTP 的 Host 头指向哪个站点。
实测（E-01）：把 www.tagzxia.com 强行指向 5 个跨网段（104.16 / 104.18 / 104.21 / 104.26 / 172.64）的边缘 IP，全部正常返回该站点响应：
curl -s --resolve www.tagzxia.com:443:172.64.144.199 https://www.tagzxia.com/cdn-cgi/trace
# → fl=134f97 h=www.tagzxia.com ip=183.241.148.23 ts=… colo=HKG sliver=none http=http/2 loc=CN tls=TLSv1.3 sni=plaintext这就是"优选 IP"在技术上成立的原因：既然任意边缘 IP 都能服务你的域名，那么"选一个对我这条线路更快的边缘 IP"就成了纯收益操作。
但有两个硬前提（E-02 / E-07）：
| 前提 | 不满足时的现象 |
|---|---|
| 该 Host 必须托管在 Cloudflare 的 zone 下 | 非 CF 站点经 CF 边缘 IP → 连接被拒（000）。实测 www.baidu.com 即如此 |
| 该 Host 的记录必须是橙云（代理） | 灰云记录会把源站 IP 直接交给客户端，优选无从下手（E-04 是真实样本） |
1.3 落点观测：/cdn-cgi/trace
判断"我到底落到了哪个机房"，唯一可靠的自证手段是请求 /cdn-cgi/trace。实测响应（E-01）：
fl=134f97 h=www.tagzxia.com ip=183.241.148.23 ts=1789394638.000 visit_scheme=https
uag=curl/8.7.1 colo=HKG sliver=none http=http/2 loc=CN tls=TLSv1.3 sni=plaintext实测可读字段：
| 字段 | 实测观测值 | 含义 |
|---|---|---|
colo | HKG / SEA | 落点机房三字码（Hong Kong / Seattle） |
loc | CN | 客户端所在国家/地区（这里是本机出口） |
sliver | none / 050-tier1 | 边缘内部标识；不同优选 IP 会给出不同值（E-01） |
ip | 183.241.148.23 | Cloudflare 看到的客户端 IP |
http / tls / visit_scheme | http/2 / TLSv1.3 / https | 本次连接所用协议 |
sni | plaintext | SNI 状态 |
warp / gateway / rbi | off（本机未走 WARP/网关/隔离） | 是否经 WARP 接入 / Gateway 策略 / 远程浏览器隔离 |
kex | X25519 | TLS 密钥交换算法 |
fl / ts / h | — | 边缘实例标识 / 时间戳 / 命中的 Host |
本节最重要的结论（E-05）：/cdn-cgi/trace 绿 ≠ 站点健康。
它由边缘直接生成、不经过源站。实测同一个 Host：
curl -s -o /dev/null -w 'code=%{http_code}\n' --resolve tagzxia.com:443:104.16.148.10 https://tagzxia.com/cdn-cgi/trace
# → 200 ← 边缘活着
curl -s -o /dev/null -w 'code=%{http_code}\n' --resolve tagzxia.com:443:104.16.148.10 https://tagzxia.com/
# → 525 ← 边缘到源站的 TLS 握手失败所以正确的排错顺序是：先看 trace 确认"边缘可达 + 落点对不对"，再看真实路径确认"回源是否健康"。两者缺一不可，混为一谈就会得出"网络没问题，肯定是你服务器的问题"这类错误结论。
已结案（
F-012）：Cloudflare 只文档化了 trace 输出中的站点字段（如colo为落点三字码、loc为 IP 所属国家）；而sliver等路由/调度内部字段并非官方文档化接口——教程把它们一律按 「实测观测，非官方文档化字段」 标注，不作为契约使用。