把博客、图床、独立站放在 Cloudflare 后面，是国内站长这几年最普遍的操作。但很多人接入 CF 后会发现一个尴尬的事实：三大运营商访问 Cloudflare 的速度差异巨大——电信 80ms、联通 150ms、移动直接 300ms 起跳并伴随大量丢包，体感比没上 CDN 还慢。
问题不在 Cloudflare 本身，而在它的默认调度。Cloudflare 在全球有 300+ 城市的边缘节点，但通过 Anycast + GeoDNS 给你分配的那个节点，未必是对你最快的那个。"Cloudflare 优选 IP"，就是用工具找出对你这条网线最快的那个 CF 节点 IP，绕开默认调度，直接走过去。
这篇文章把优选 IP 的原理、三种实现方式、五步测速流程、自动化脚本，以及 12 个最常见的踩坑点全部讲清楚。看完之后你能独立完成从筛选到落地、再到长期维护的整条链路。
一、先搞清楚：什么是 Cloudflare 优选 IP
要理解优选 IP，先理解 Cloudflare 的网络结构。
Cloudflare 用的是 Anycast（任播）架构。简单说，它在全球 300 多个城市部署了边缘节点（PoP），所有节点都对外宣告同一组 IP 段。当你访问 example.com（接入了 CF 的域名），Cloudflare 的 DNS 会根据你 DNS 出口的位置，把你解析到"它认为离你最近"的那个 PoP 的 IP 上。
问题来了：
- "DNS 出口的位置" ≠ "你的真实位置"。很多用户用了公共 DNS（114、阿里、Google 8.8.8.8），出口可能在另一个城市甚至另一个省。
- "地理上最近" ≠ "网络上最快"。从国内访问 CF 的香港节点理论上最近，但中国移动到香港的链路可能比到日本还差。
- 同一个 IP 段里的不同 IP，落地的 PoP 可能不一样。这是 Anycast 路由抖动的特性。
所谓"优选 IP"，就是跳过 CF 的默认 DNS 调度，自己测一遍 CF 公开 IP 段里哪些 IP 对你这条线路最快，然后直接用那个 IP 去访问。
核心机制：Cloudflare 是基于 SNI 和 Host 头分发请求的。也就是说，只要你最终请求里带的 SNI / Host 是你的域名，无论你连到 CF 的哪个 IP，它都能正确把流量转给你的源站。这就是优选 IP 能成立的根本原因——你换 IP，但服务还是你的服务。
二、CF 默认调度为什么不够好
三大运营商在 CF 默认调度下的常见痛点，按经验大致是这样：
1. 电信：相对最稳，但西南、西北分区会绕
电信用户大概率被分到 CF 的洛杉矶、圣何塞或者香港节点，整体可用。但西南（成都、重庆）和西北用户，被调度到圣何塞的概率更高，回程经常走 163 普通网，晚高峰拥堵。
2. 联通：日韩好、欧美一般、香港随机
联通到 CF 的日本东京节点延迟通常很漂亮（50-80ms），但默认未必把你分过去。访问欧美内容时经常被分到圣何塞或者达拉斯，绕路且延迟拉满。
3. 移动：默认调度的最大受害者
中国移动到 CF 的链路一直是三网里最不稳定的。默认经常被分到圣何塞甚至阿姆斯特丹，跨太平洋一来一回 300ms+ 是常态，晚高峰丢包 10%+ 也不少见。优选 IP 对移动用户的提升最显著，从 300ms 优化到 80ms 的案例不在少数。
关于三网线路差异的底层原因，可以参考本站文章 《CN2、CMI、9929、CMIN2 等，一文讲透国内三大运营商所有线路名词》。
三、优选 IP 的工作原理
用一个完整的请求链路把这件事彻底讲透。
正常访问 blog.example.com（接入了 CF）的流程：
- 浏览器 DNS 查询
blog.example.com - CF 的权威 DNS 返回一个"它认为合适"的 IP，比如
104.16.x.x - 浏览器建立 TCP 连接到这个 IP
- TLS 握手，客户端发送 SNI =
blog.example.com - CF 边缘节点根据 SNI 找到对应的 zone，拿到回源配置
- 从边缘节点回源到你的源站，拿数据返回
优选 IP 改变的是第 2 步——你不再让 CF DNS 给你 IP，而是自己指定一个 CF IP 用。最常见的实现是改本地 hosts：
104.16.123.45 blog.example.com这样浏览器查 DNS 时直接拿到 104.16.123.45，跳过 CF 的 GeoDNS。后面的 SNI 还是 blog.example.com，CF 边缘节点照样能正确路由请求到你的源站。换 IP 但服务不变，这就是优选 IP 的全部魔法。
四、优选 IP 的三种实现方式
| 方式 | 实现难度 | 影响范围 | 适合场景 |
|---|---|---|---|
| 本地 hosts 文件 | 极低 | 仅当前设备 | 个人电脑/单机访问 |
| 路由器 hosts / 自建 DNS | 中 | 整个内网 | 家庭网络、小办公室 |
| Workers 反代 / 自建 CDN 入口 | 较高 | 所有访客 | 对外服务的网站，给用户加速 |
方式一：本地 hosts
Windows 位置：C:\Windows\System32\drivers\etc\hosts；macOS / Linux：/etc/hosts。直接追加一行：
104.16.123.45 blog.example.com www.example.com cdn.example.com保存后浏览器刷新 DNS 缓存即可生效。优点是零成本，缺点是只对自己生效，对你网站的其他访客没用。
方式二：自建 DNS / DoH
在路由器上跑 AdGuardHome、SmartDNS、或者 dnsmasq，把目标域名的解析改写到优选 IP。整个家里的设备都会受益。SmartDNS 还能同时维护多个候选 IP，按延迟自动切换，是这一档的优选方案。
方式三：Cloudflare Workers 反代或自建 CDN 入口
这个方向略复杂，本质是把"换 IP 这件事从客户端搬到服务端"：用一台国内可访问性好的服务器（或者用 Workers）做反向代理，对外发布一个独立的入口域名 / IP，所有访客访问这个入口，由它再去回源 CF。优点是对所有访客生效，适合面向用户的网站；缺点是要维护一台中转、成本不低。
五、实战：怎么找到适合自己的优选 IP
核心五步流程，所有工具组合都是为这五步服务的。
Step 1：拿到 Cloudflare 官方 IP 段
CF 公开了自己所有的 anycast 段，地址在 https://www.cloudflare.com/ips-v4。常见的几个段：
| IP 段 | 常见特征 |
|---|---|
104.16.0.0/13 | CF 主力段，覆盖广 |
172.64.0.0/13 | 较新的段，部分节点表现优秀 |
162.159.0.0/16 | 较老段，部分国内回程较好 |
141.101.64.0/18 | 欧洲方向常见 |
108.162.192.0/18 | 北美方向常见 |
173.245.48.0/20 | 北美方向常见 |
注意 CF 的 IP 段会增减，以官方公布的最新列表为准。
Step 2：批量存活与基础延迟扫描
整个 CIDR 段里有大量 IP，不可能手测。这一步用 BiuPing FindPing 做整段高并发扫描，快速筛掉不通的 IP 和延迟离谱的 IP，留下候选集（一般保留前 20-50 个）。
FindPing 的优势在于从国内多线路同时发起扫描，你不只能看到"通不通"，还能看到"对电信/联通/移动分别通到什么程度"。这是单机命令行扫不出来的维度。
Step 3：多节点延迟测试
把候选 IP 拿到 BiuPing 多节点 Ping 跑一遍，看每个 IP 从全国不同省市、不同运营商出去的延迟和丢包。重点关注：
- 平均延迟：越低越好，但不是唯一指标
- 丢包率：必须接近 0，1% 以上的就直接淘汰
- 抖动（Jitter）：标准差大说明链路不稳，对视频、游戏、WebSocket 致命。关于抖动的影响可以看本站 《Ping 值很低游戏却卡顿？真正的元凶可能是网络抖动（Jitter）》
- 三网均衡度：如果你的访客覆盖三网，要找三网都不差的 IP，而不是只对一家好
Step 4：HTTP 真实下载速度测试
这一步是最多人漏掉的，也是判定一个 IP 真正能不能用的关键。延迟低不代表带宽好——CF 给国内的某些节点会被限速到 500KB/s 以下，ping 再漂亮下载也是龟速。
用 BiuPing 网站测速 测一个真实的下载场景：
- 用候选 IP 替换 DNS 解析（hosts 或工具配置）
- 访问你站上的一个真实大文件（图片、JS、CSS、或者一个 1MB 测试文件）
- 看完整瀑布流：DNS / TCP 握手 / TLS 握手 / TTFB / 下载耗时五段
- 多节点同时测，看一致性
实战经验：一个延迟 80ms 但 TTFB 是 600ms、下载速度 200KB/s 的 IP，不如一个延迟 130ms 但 TTFB 180ms、下载速度 5MB/s 的 IP。
Step 5：长时间稳定性观察
CF 的 anycast 路由是动态的，同一个 IP 早上的归属 PoP 和晚上未必一样。光测一次就上线是大忌。建议候选 IP 选定后，连续 3 天、覆盖早中晚三个时段各跑一次完整测试，挑出"全时段都不差"的 IP，而不是"某一刻最快"的 IP。
六、自动化脚本：CloudflareSpeedTest 与替代方案
对追求效率的用户，社区有一个广泛使用的开源工具 CloudflareSpeedTest，能从本地一次性完成 IP 段扫描 + 延迟测试 + 下载测速，输出排序后的 TOP IP 列表。基本用法：
# 下载对应平台的二进制
# Linux 示例
./CloudflareST -n 200 -t 4 -dn 10 -tl 200 -tll 40 -tp 443
# 关键参数：
# -n 200 并发数
# -t 4 ping 测试次数
# -dn 10 保留前 10 个做下载测速
# -tl 200 延迟上限 200ms
# -tll 40 延迟下限 40ms（避免落地节点过近）
# -tp 443 测试端口 443它有两个局限要注意：
- 从你本地一台机器测，只代表这台机器所在的线路。如果你的网站访客遍布三网，本地测出来的"最优 IP"对其他用户可能不适用。
- 下载测速默认走 CF 提供的测速文件，跟你站上的真实资源（受你回源配置、缓存命中率影响）会有差异。
所以推荐的玩法是：本地用 CloudflareSpeedTest 做粗筛 → BiuPing 多节点工具做精筛 → 真实业务回归验证。三步组合下来，找出来的 IP 才是真正"对你网站所有访客都不差"的 IP。
七、按运营商优选：电信 / 联通 / 移动的偏好规律
虽然 CF 是 anycast，每个 IP 落到哪个 PoP 随时间和路由变化，但长期观察下来三网对 CF 不同段确实存在统计意义上的偏好（仅供参考，以你实测为准）：
| 运营商 | 表现较好的常见段 | 典型落地 PoP |
|---|---|---|
| 电信 | 104.16 / 104.17 / 172.64 部分 | 洛杉矶、圣何塞、香港 |
| 联通 | 104.16 / 162.159 / 172.64 | 东京、香港、洛杉矶 |
| 移动 | 172.64 / 104.18 / 141.101 部分 | 东京、新加坡、阿姆斯特丹（偶尔） |
重要提醒：上表只是经验性的"起点"，不是固定结论。CF 的路由策略每几个月可能就会调整一次，真正的优选 IP 必须每次自己跑一遍测试，照搬别人的列表往往不准。
八、避坑清单：12 个最常见的误区
下面这些坑，是我和不少站长在做 CF 优选时都踩过的。一条一条对照检查，能省下大量返工时间。
1. 只测延迟不测下载速度
前面强调过：CF 部分节点对国内有带宽限制，延迟漂亮但下载慢。必须做 HTTP 下载测速，看完整瀑布流。
2. 用国外 VPS 测国内访客用的优选 IP
测速点必须和你的访客在同一张网。从美国 VPS 跑 CF IP 测出来的"最优"，跟你电信用户实际访问没有半点关系。
3. 不区分三网，只测一家
很多人手头只有电信，测完直接全网推。结果联通、移动用户体验更差。一定要三网都覆盖。
4. 测完一次就当一劳永逸
CF 的 anycast 路由是动态的，一个月前最优的 IP 现在可能已经被分到很远的 PoP。建议每周复测一次，至少每月一次。
5. 把 CF 的某个 IP 当作"固定常量"硬编码
CF 偶尔会下线某个段或者调整宣告策略。脚本要有 fallback：优选 IP 不通时自动回退到 CF 默认解析。
6. SNI / Host 头没配对
用某些代理工具自定义 IP 时，如果忘了带正确的 SNI，CF 边缘节点会返回 HTTP 403 或者 SSL 错误。检查 TLS 客户端配置确认 SNI = 你的域名。
7. 在主路由上写死 hosts，影响家人
主路由上的 DNS 改写会影响所有设备。如果家人/同事访问你的目标域名时拿到了你优选的 IP，但他们用的是不同运营商，反而可能变慢。建议只在你自己的设备或子网做。
8. 错把非 CF 的 IP 当成 CF IP 用
CF 的官方 IP 段是公开的，但很多用户从论坛抄来的"优选 IP"实际是别人 Workers 反代出来的、或者干脆是某个住宅 IP。这种 IP 用上去：第一不稳定，第二可能涉及别人的服务被你蹭流量。认准 CF 官方 IP 段。
9. 测速时段过于单一
白天 14:00 测的 IP 是好的，到了晚 21:00 高峰可能丢包飙到 10%。必须覆盖早中晚三个时段。
10. 优选了 IP，但 TLS 证书域名对不上
这种情况通常发生在你优选 IP 后访问 https://104.16.x.x（直接用 IP 访问），证书是发给域名的，IP 访问当然校验失败。正确用法是改 hosts，让浏览器以为这个 IP 就是你的域名，用域名访问，不是用 IP 访问。
11. CF 节点禁用了非 443/80 端口
CF 部分 IP 出于 DDoS 防护，会禁用 8080 / 2052 等非标准端口。如果你跑 WS+TLS 之类的服务用了非标端口，优选 IP 之后可能完全打不通。优先用 443，要么换段。
12. 把 CF 优选 IP 当作"加速一切"
优选 IP 只能加速你站在 CF 上的资源。源站如果跨境（比如源站在美国），优选 IP 把你和 CF 之间的延迟降下来了，但 CF 回源到美国源站那一段你管不到。真正的加速要同时优化"客户端 → CF" 和 "CF → 源站" 两段。
九、动态维护：好 IP 会变，怎么做长期方案
一次性筛出 IP 写死，几周后效果就会衰减。成熟的玩法是把"优选 + 应用"做成自动化流水线：
1. 定时任务每天复测
cron 跑 CloudflareSpeedTest，输出排序后的 TOP 5 IP。把结果落到一个文件里供后续步骤消费。
# 每天凌晨 4 点跑一次
0 4 * * * /path/to/CloudflareST -dd -o /var/log/cf_best.csv2. 自动更新 DNS 解析
如果你的域名 DNS 在 Cloudflare 上托管（很常见），那其实不需要你改 DNS 自己的 A 记录——你改了也没用，因为访客查 DNS 还是会经过 CF 调度。这种情况下你只能控制"你自己设备/服务器"侧的解析。
如果你的 DNS 在第三方托管（阿里、DNSPod、CF DNS only 模式等），可以用脚本通过 API 把昨晚测出来的最优 IP 写入 A 记录。注意 TTL 设短一点（60-300 秒），方便快速切换。
3. 客户端侧用 SmartDNS / mosdns 做动态切换
更优雅的方案是在路由器或者本地跑 SmartDNS / mosdns，维护一个 CF IP 候选池，由 DNS 服务自己实时测延迟选最快的返回。访客端啥都不用改，自动享受最优。
4. 监控 + 告警
给优选后的 IP 加一个外部监控，最优 IP 一旦丢包率超过阈值（比如 2%）或者延迟突增 50%，自动报警并触发重新筛选。
十、写在最后
把这一整套讲完，本质上就是一句话：
Cloudflare 优选 IP 的本质，是用工具补 CF 默认 GeoDNS 调度的盲区——你比它更了解你和你访客所处的真实链路。
这套方法不限于 Cloudflare。Fastly、Akamai、Bunny CDN、甚至自建 CDN 的入口选择，都可以套同样的流程：拿到入口段 → 多线路扫描 → 多节点测延迟 → 真实下载验证 → 长期监控复测。所谓 CDN 加速，从来不是"接上就完事"，而是一套需要持续维护的工程。
BiuPing 的所有工具——多节点 Ping、TCPing、网站测速、路由追踪、FindPing 段扫描、DNS 查询——本质上都是为了把这套流程里的每一步从"靠运气"变成"靠数据"。如果你正在做 CF 优选或者更广义的 CDN 接入优化，可以把这几个工具收藏起来配合使用。
祝你的网站从此对三网都能跑出漂亮的数字。
📚 相关推荐
CN2、CMI、9929、CMIN2 等，一文讲透国内三大运营商所有线路名词 网站国外访问很慢？一文讲透跨境网络问题排查与优化方法 Ping 值很低游戏却卡顿？真正的元凶可能是网络抖动（Jitter） 丢包率多少算正常？网络丢包判定标准与排查完整指南
🔧 试试这些工具
📡 在线 Ping 🔌 在线 TCPing 🌐 网站测速 🗺️ 路由追踪 🔍 FindPing 段扫描 🏷️ IP 归属查询