[Cloudflare专题]关于Cloudflare节点链路情况的一些说明

当然各位站长对Cloudflare肯定是不陌生的，较低的使用门槛和高级的防御能力让它成为了不少站长初次使用的CDN服务，当然时至今日，Cloudflare也仍在以自己先进的技术为各个网站发光发热。

当然需要理解Cloudflare的话，先得知道他的一个特性

Anycast 任意播/泛播

在很久之前的一个帖子AnyCast泛播IP杂谈就已经有谈到过CF 节点anycast的体现了：不同地区同一IP的BGP路由不一，播到的服务器也不一样。因此CF的速度很大程度上跟CF与国内三大运营商的互联PEER有关。
下面将分运营商探讨当前（2022年7月份）CF到国内的一些链路情况，提供一些速度较快/稳定没有BAN的IP段。
总体情况上看，目前除了移动一些IP段会播到香港HKG外，电信联通均走美国洛杉矶LAX或圣何塞SJC.

一些分析方法

IP段列表来自于前人以及cloudflare官方公开，使用BlueSkyXN/CFIP 的优选工具进行测试，并通过besttrace/ipip.net获取路由状况。

ip一览

移动用户：广移/上移香港出口的受益者

我的心得：作为一个身处广东偏僻城市的移动用户，我能够确确实实的感受的CF香港直连节点的快。
比如说104.16.40.17，表现在所有的HK ip中中规中矩，在29次测试中平均ping延迟38ms，比百度的还低10多ms。

这当然是得以于地理位置优势，然而偶尔也有超时的现象出现，这也就能解释为什么有时会出现断流/无法访问的现象出现。通过路由跟踪我们可以明显观察到有广州移动到香港移动CMIAS58453。

我们通过优选工具在移动网络下进行测试，发现较低的延迟IP均集中在104.16.0.0/12 之中，测试结果如下

那是否该段104.16.0.0/12都是低延迟呢？

我们通过 besttrace的批量Ping功能发现这件事并没有这么简单，延迟的好坏取决于cf为它的ip宣告的BGP路由

简单来讲，良莠不齐、并且还有中间反复横跳的一些IP。
比如说像104.16.1.2这一个IP，就算是一个不错的IP，路由是固定的，这个由TTL只有一个值可以看出。

而同是104.16.1.0/24网段下的104.16.1.1就没有那么幸运了。

在多次ping测试下，可以看到延迟有明显不同，一些是在50ms上下，而还有的则是在180ms上下。
再看ttl，有两个不同的值，这就说明cf为这个ip设置了两种路由

一种是有香港移动跳到跳到hkix再到香港CLOUDFLAREanycast节点，还有一种就是由香港移动到美国的移动西雅图SEA西雅图的CF anycast节点。

104.16.0.1-104.16.15.255之中ip的路由分布较随意，没有什么规律特点，而后面的ip路由就是成段的同样分布了

美国圣何塞SJC节点

一sjc节点的路由

延迟基本200左右ms。
还有更多的是美国圣何塞sjc节点，在104.16.16.0/19（104.16.16.0-104.16.31.255），104.16.48.0-104.16.79.255，104.16.128.1-104.16.143.255……上可以看到明显的存在。当然，如果想了解更多，可以看我们下方提供的结果

香港HKG节点类型

1.经由HKIX（cloudflare1-lacp-100g.hkix.net，123.255.90.246）
一个常见的路由

这类节点延迟一般50-60ms，不错很大程度上受HKIX，因此比直连节点要多30+ms。
2.移动直连Cloudflare

这里的ip段有104.16.32.0-104.16.47.255、104.16.80.0-104.16.127.255（不错，为上方美国ip和一些没有规律的ip段的补集）

另外据我观察，即使南方地区某些IP的路由指向了香港，但北方地区也可能指向了美国节点，当然指向香港的节点也由as9808到达广州出口。并且跟CF香港节点有互联的就是上海、广州出口。

（北方示例，辽宁沈阳移动云）

（上海移动云）

小结：104.16.0.0/16段的IP还都不错，建议自己通过工具筛选.

141.101.64.0/18段中 141.101.113.0-141.101.115.155，141.101.90.1-141.101.90.255 也有HK的，延迟在60-70ms
还有172.64.147.0-172.64.159.255，198.41.192.0-198.41.199.255，

联通&&电信

这个没什么好说，普遍美国节点了。
1.电信方面

（北京天翼云）

（上海电信）

（广州电信）

除了……您是尊贵的CN2宽带的拥有者，那前面的话当我没说，你可以享有经由香港ntt到香港cloudflare节点的优越体验，如同大多数的移动用户一般!

2.联通

（天津联通）

（深圳联通）

（杭州联通）
线路经由att/gtt，延迟普遍200ms+

当然同时如果您是as9929，那么您经由东京ntt到达TKY的cloudflare节点。

ping延迟并不能代表实际访问速度

然后我们又用17ce测试各个ISP到访问CloudflareIP默认界面(Direct IP access not allowed | Cloudflare)，除了一些因不名原因而访问失败的节点，绝大多数电信/联通访问美国CF节点的时间在0.3s-0.4s/0.5-0.6s，不错，是一个太平洋的往返的速度。


移动方面，一些快的点速度可以达到0.1s及以下，当然也有一些路由到美国的节点就没有那么好运了。

附：如果判断访问到的CF节点？

Cloudflare（加速？）的网站你可以在访问页面的中看到cf-ray这一响应头，在响应头的内容中横杠后面的字母代表了CF节点机房的缩写，比如下面示例中HKG就是香港节点。
字母具体对应的地方机房可以通过查看这个文档中找到答案：Cloudflare 边缘节点 数据中心列表

To Sum Up

学会了以科学的方式探究问题，懂得控制单一变量法，敢于做出假设

为了是您的网站到您的用户的速度最优化，用户体验最好，我们需要考量的是用户到访问节点，节点再到源站的速度。尽管大多数情况下CF机房回源到源站的速度不会差，但也有例外。（比如说你的源站在国内，并且是联通/电信机房，那么联通电信的访问您的网站，相当于饶了两圈太平洋，您的源站到cf回源节点，cf节点到您的用户各一圈，这样的体验就是最不友好的了。所以我们需要做的是尽力缩短这三者之间的两段距离。