Cloudflare 优选 IP v7：把江苏本地实测和网上三网排名合成一个综合值

我们在江苏的家宽（电信）上跑 Cloudflare 优选 IP 列表时，踩过一个坑：只按电信延迟排出来的最优 IP，在联通和移动上经常很不友好。同一批 IP，电信最快的几个，换到联通、移动的视角看延迟能差出几倍。原因不难理解：Cloudflare 的任播 IP 在不同运营商出口走的路径本来就不一样，单运营商的最优解换个运营商就失效了。
2026 年 11 月 9 日，我们把优选规则升级到了 v7：江苏段不再用单一电信值，改用一个综合值——网上微测三网江苏值与本地电信有效延迟，取可用者平均。这个综合值同时驱动三件事：江苏块 60 条的排序、综合分公式里的江苏段、以及 SG 置顶（XinYiTang / Tiancheng）的排名。
本地实测怎么做才可信：本地测量点是一台江苏家里的 Ubuntu 机器，没有公网 IP，内网地址 172.21.3.249，出口是江苏电信，公网 IP 221.226.22.114。机器上跑着 mihomo TUN，默认所有 TCP 会被 TUN 本地秒接，裸测 tcping 全是 0ms 的假数。绕法是不用 root 权限：Python socket 先 bind 源地址 172.21.3.249 再 connect，策略路由即走主表物理出口，测到的是真实值（验证：测 223.5.5.5 为 13ms，直连 8.8.8.8 超时，符合国内直连预期）。测量脚本在本地 ~/cf-js-measure/measure.py，对每个候选 IP 做 tcping 443 共 10 次，有效延迟 = 10 次中位数 + 抖动（10 次标准差）+ 每次丢包罚 500ms。约 1200 个候选一轮约 2 分钟。每天 06:25 和 16:25，SG 服务器经 Cloudflare 隧道 SSH 把 TSV 拉回来，存到 /var/lib/cf-select/js_latency.tsv；只有 TSV 新鲜（12 小时内且超过 500 行）才走新逻辑，否则自动回退旧逻辑。
网上三网值从哪里来：网上能拿到的江苏三网逐 IP 延迟目前只有微测一家，每轮只发布 15 个 IP（电信、联通、移动各 top5）。2026 年 11 月 9 日 07:00 那轮 US 名单 150 条里，只有 8 条带微测值。所以绝大多数 IP 的“综合值”实际仍只有本地电信一票，有微测值的才真正两边平均——这是 v7 已知的局限，先如实记下来。
v7 改了什么：江苏块不再分 30 条纯电信 + 30 条综合，整块 60 条按综合值升序排；综合分公式的江苏段改用综合值；SG 置顶仍按速度 /（1 + SG 延迟 + 江苏综合值）排，SG 侧速度 ≥1 MB/s 的门槛保留；US 侧 Sak 块内部排序本来就按综合分排，自动跟随；总数、门槛、定时不变：SG 146 条、US 150 条，生成仍是 07:00 / 17:00，本地数据仍 06:25 / 16:25 拉取。
首轮验证结果：2026 年 11 月 9 日 09:17 起手动各跑一轮验证：SG 发布 146 条（universe 141，江苏 / 综合分块 60 / 81，综合值覆盖 top 内 105，置顶 XinYiTang 2 + Tiancheng 10）；US 发布 150 条（universe 466，Sak / 江苏 / 综合分 = 21 / 60 / 60，余量由综合分补足）。公网核对：cf-sg.txt 146 行、cf-us.txt 150 行，两份明细头部均为 mode=local-js v7。
一个架构教训：优选必须从美国侧视角跑：此前在 SG 跑时，第一阶段 US / CA colo 只有 56 / 812 通过，候选宇宙只剩 3 个；移到 ohio-7（美国俄亥俄）后是 581 / 812，宇宙 516。节点落地美国，测量视角也得在美国，否则选出来的 IP 在美国侧根本不优。
小结：单运营商最优不等于多运营商最优。v7 的做法很朴素：本地实测给电信一票，网上三网值给另外三家一票，能拿到几票就平均几票；拿不到的，先承认局限，等数据源多了再补。规则改版的完整实施只花了一个上午，难的从来不是公式，而是先承认“纯电信最优”这个前提本身就是错的。