发现一个奇怪的 Cloudflare 优选 IP 列表，怎么还混进了 AWS？

最近在“冲浪”寻找能提升网络体验的 CF 优选 IP 时，无意间撞见了一个有点意思的列表：cf.os.kg。

初看下去，这玩意儿确实能跑，而且效果还不错。但仔细瞅了一眼节点归属，我当时就有点懵了——这真的是 Cloudflare 的 IP 吗？怎么里面混进去了一堆 AWS 的节点，甚至还有其他常见的 IDC（数据中心）机房 IP？

通常我们对 CF 优选 IP 的理解，就是挑那个延迟最低、丢包率最小的官方接入点。但这种“混血”阵容是怎么回事？今天来稍微扒一扒这里面的门道。

什么是 Cloudflare 优选 IP？

简单回顾一下，所谓“优选”，就是在面对 Cloudflare 这类全球CDN网络时，由于官方分配给我们的入站 IP 可能因为拥堵或者线路（如普通电信 vs CN2）原因导致体验不佳。大家通过扫描测速，寻找那些线路质量更好（比如走了高端专线）、路由更优的 CF 边缘节点 IP，强行指定连接这些节点，从而实现“加速”或降低丢包。

Cloudflare CDN 网络架构示意图

商业版？不对劲

回到这个 cf.os.kg，有朋友反馈这看起来像是“商业版”。CF 的商业版 IP 通常是指 Cloudflare 为企业客户提供的、包含更高级防护或特定功能的 IP 段，或者是那些 SaaS 类服务的专用 IP。这类 IP 的确往往网络质量更稳，但也有可能带有更严格的风控策略。

但让人困惑的是，AWS 的 IP 是怎么混进来的？

为什么会有 AWS 和其他 IDC？

这里可能有几种解释，我们可以一起分析分析：

1. 代理/中转架构（最可能的情况）： 你看到的这个优选列表，可能并不是直接的 CF 边缘节点 IP，而是某些“中转”或“前置代理”的 IP。搭建者可能购买了 AWS 或其他高性价比 IDC 的服务器，在上面搭建了代理服务，后端再对接 Cloudflare 的 IP。对于用户来说，虽然入口是 AWS IP，但流量最终还是要经过 CF。这种架构有点类似“前置中转”，目的是利用 AWS 等大厂的骨干网优势来优化第一段路程。

2. Cloudflare for SaaS 的特殊配置： Cloudflare 的 SaaS 模式允许用户通过 CNAME 接入，有时候会涉及到源站的保护。在某些复杂的配置下，外部看到的某些 IP 段可能会呈现出“非官方 CF 段”的特征，或者是使用了某些合作伙伴的基础设施。不过直接出现 AWS IP 的概率相对较低，这更像是人为搭建的架构。

3. 蹭 AWS 的带宽？ 有一种思路是利用 AWS 等云厂商的免费额度或极低价格机型做一个“跳板”。如果你测速发现连接这个 IP 很快，是因为你的网络到 AWS 的链路好（比如 AWS 刚好有对等互联）。但流量到了 AWS 后，再往外走（去 CF 源站）的路程变长了，虽然握手延迟低，但实际吞吐未必真的比直连 CF 好。

4. 识别错误或误导性命名： 还有一种可能，就是这个扫描脚本或者列表本身存在识别错误，把某些数据中心的 IP 错误地归类为了 CF 优选。或者是为了吸引用量，故意挂着羊头卖狗肉。

怎么验证这些 IP 到底靠不靠谱？

如果你手头有这种混杂的列表，不要盲目使用，建议简单测一下：

• Ping/Trace Route： 看看路由路径，是直接到了 CF 的 ASN（AS13335），还是先跑到了 AWS（AS1659）。
• 真实吞吐测试： 延迟低不代表网速快。一定要测一下下载速度或看视频的缓冲情况，特别是上行带宽。
• TTL 值判断： 如果 TTL 值很奇怪，或者经过了多重跳转，那大概率是经过中转的。

总结

发现这种混入 AWS 的“CF 优选”列表，大概率不是什么官方隐藏彩蛋，而是某种**“中转+优选””的混合方案**。它可能确实解决了部分人回源路由烂的问题，但也增加了中间环节的不可控性。

羊毛党和技术流玩家可以试一试，但如果是用来跑关键业务，还是得悠着点，搞清楚数据到底走了哪条路才是正经事。

大家最近有没有发现什么奇奇怪怪又好用的 IP 段？欢迎在评论区分享你的测试结果！