我们通常默认：把网站接入 Cloudflare 就会更快。但当我把自己的一台网站放到 Cloudflare 上之后，遇到的却是相反的情况。于是我决定做一系列系统性的测试，弄清楚到底发生了什么。
这篇文章会完整记录我在自己网站上用 Cloudflare Free、Pro、Pro + Argo 三种方案所做的实验，也会分享对一批 Cloudflare Business 和 Enterprise 网站做的测试，并说明如果你的访客主要来自印度，这意味着什么。
1. 我最初观察到的问题
我的其中一个网站托管在 DigitalOcean 位于印度班加罗尔的服务器上，在迁移到 Cloudflare 之前已经稳定运行了几个月。
我用另一座城市、距离源站约 1500 公里的 Jio 光纤网络做了一次简单的延迟测试，结果如下：
迁移到 Cloudflare 后，延迟从大约 47 毫秒上升到了 159 毫秒。而且，连本该被 Cloudflare CDN 缓存的静态资源（JS、CSS、图片）也出现了同样的情况。
把网站迁移到 Cloudflare 后，延迟从约 47 毫秒上升到约 159 毫秒（其他条件均未改变）。
2. 初步实验：测量延迟
看到延迟不降反升，我决定连续 3 天、每天测试两次，以排除网络流量波动带来的偶然误差。
2.1. 基线：不使用 CDN
我先回到不使用 Cloudflare 的状态，测量源站服务器在无 CDN 情况下的延迟。
可以看到这台 DigitalOcean 服务器对应的 IP 地址：
然后从我的笔记本 ping 这个 IP，获取延迟：
从结果可以看出：
- 请求到达服务器并返回，平均耗时约 47 毫秒（RTT 延迟）。
- 延迟波动很小。
基线：到源站约 47 毫秒，波动很小。
2.2. Cloudflare Free 方案
我把网站切换到 Cloudflare Free 方案，重复上述测试进行对比。
切换后，“Remote Address”里的 IP 变成了 Cloudflare 的 IP：
在讨论延迟之前，先注意上面响应里的 Cf-Ray 头。Cloudflare 文档说明，Cf-Ray 包含处理该请求的数据中心位置。也就是说，这个来自印度、源站也在印度的请求，竟然由 AMS（阿姆斯特丹）数据中心处理。
根据以上结果：
- 我与处理请求的 Cloudflare 节点之间的 RTT 延迟约为 159 毫秒。
- 标准差约 4%，波动程度与基线（无 CDN）相近。
总体来看，这次测试表明：接入 Cloudflare CDN 反而增加了约 112 毫秒的 RTT 延迟。
那么，这个问题是 Free 方案独有，还是付费方案也会遇到？
Free 方案：由阿姆斯特丹节点服务，延迟约 159 毫秒（慢了 112 毫秒）。
2.3. Cloudflare Pro 方案
我升级到 Pro 方案（按年付费约 20 美元/月），等待约一小时后重复测试，看看行为是否有变化。
此时 Cf-Ray 头返回的值以 SIN 结尾，说明请求改由新加坡数据中心处理。这仍然不是最优结果，因为 Cloudflare 的网络页面显示，它在印度有二十个数据中心/边缘节点，其中两个距离我做实验的地点不到 500 公里（约 300 英里）。
Cloudflare Pro 方案的测试结果如下：
- 我与 Cloudflare 边缘节点之间的 RTT 延迟约为 207 毫秒。
- 标准差约 29%，本次测试的延迟波动明显更大。
Pro 方案：由新加坡节点服务，延迟约 207 毫秒（波动明显）。
2.4. Cloudflare Pro 方案 + Argo 路由
我在 Pro 方案上加了 Argo 智能路由（前 1 GB 收费 5 美元，之后每 GB 0.10 美元），看看来自印度的请求处理方式是否会改变。
Cf-Ray 响应头仍然显示请求由新加坡数据中心处理。
延迟测试有一些改善：
- 我与 Cloudflare 边缘节点之间的 RTT 延迟约为 138 毫秒。
- 标准差约 23%，延迟数值仍有较大波动。
看起来 Argo 路由改善了我的平均延迟（我多次测试确认过），但并没有改善延迟波动。
Argo 路由改善了延迟（约 138 毫秒），但没有改善波动。
3. 进一步检查：解读 Cloudflare 路由
此前的延迟测试结果都高于预期，于是我尝试更深入地理解 Cloudflare CDN 的路由方式。
3.1. 其他印度 ISP 的 Cloudflare 路由
我做了额外测试，看看从其他 ISP 访问我的网站时，会由哪个 Cloudflare 数据中心处理。
| 访问方式 | 路由行为 |
|---|---|
| Jio 移动网络 | 由 Cloudflare 新加坡数据中心处理 |
| Airtel 移动网络 | 由 Cloudflare 新加坡数据中心处理 |
| AWS 孟买数据中心 | 由 Cloudflare 孟买数据中心处理 |
这说明 Cloudflare 的路由异常在其他印度网络上也存在，但并非所有印度网络都会遇到。
3.2. Cloudflare 上其他网站的路由
接着，我从自己的位置对 15 个使用不同 Cloudflare 方案的网站做了延迟测试：
| 网站 | Cloudflare 方案 | 服务节点 |
|---|---|---|
| playbooks.com | Free plan | 新加坡数据中心 |
| remoteok.com | Free plan | 新加坡数据中心 |
| judge2020.com | Free plan | 新加坡数据中心 |
| superblog.ai | Pro plan | 新加坡数据中心 |
| www.jsdelivr.com | Pro plan | 新加坡数据中心 |
| cdnjs.com | Pro plan | 新加坡数据中心 |
| unwomen.org.au | Business Plan | 孟买数据中心 |
| www.thetrevorproject.org | Business plan | 孟买数据中心 |
| decisiondeskhq.com | Business plan | 孟买数据中心 |
| www.canva.com | Enterprise plan | 孟买数据中心 |
| {无法披露} | Enterprise plan | 孟买数据中心 |
| {无法披露} | Enterprise plan | 孟买数据中心 |
以上检查表明，Cloudflare 的路由异常并非发生在所有网站上。它似乎主要存在于 Cloudflare Free 和 Pro 方案的网站上。
4. 为什么 Cloudflare 会这样路由？
到这一步，对于观察到的 Cloudflare 路由行为，有两个可能原因：
4.1. 因容量原因重新路由
Cloudflare 承认，他们会根据各数据中心的容量消耗情况重新路由流量。要验证这是否是原因，我需要跨多天甚至多周进行测试。
4.2. 与某些 ISP 缺乏对等互联
在深入细节之前，先简单说明什么是对等互联：
什么是对等互联
对等互联是指两个网络（例如一个 ISP 和一个 CDN）达成协议，直接在彼此之间交换流量。如果没有这种协议，流量就必须经过多个中间网络转发。
在这种情况下，我的 ISP 与 Cloudflare 之间缺乏对等互联，可能导致流量被路由到新加坡或阿姆斯特丹。
印度 ISP 与 Cloudflare 之间的对等互联协议
我找不到一份明确列出哪些 ISP 没有与 Cloudflare 签订对等互联协议的清单。但像这里、这里和这里的论坛讨论表明，印度最大的两家 ISP——Jio 和 Airtel——可能没有与 Cloudflare 签订对等互联协议。截至 2025 年 1 月，这两家 ISP 合计占据印度移动网络市场超过 75% 的份额。
缺乏对等互联是否导致 Cloudflare 从远端数据中心提供服务？
Cloudflare 的对等互联协议条款，很可能导致部分网站由较远的数据中心提供服务。但这似乎并不适用于所有 Cloudflare 网站。Business 或 Enterprise 方案上的网站，似乎被排除在这种行为之外。
5. 更大规模的 Cloudflare 延迟测试结果
综合以上信息，我编写了一套自动化延迟测试套件，在两周（10 个工作日）的白天时段每 30 分钟运行一次。以下是从我办公室（印度）通过 Jio 光纤连接进行的 150 次延迟测试结果：
| 网站 | Cloudflare 方案 | 延迟（越高越慢） |
|---|---|---|
| punits.dev | 无 CDN（源站 @DigitalOcean，班加罗尔） | 47 毫秒 |
| crawlably.com | 无 CDN（源站 @DigitalOcean，班加罗尔） | 47 毫秒 |
| playbooks.com | Free plan | 186 毫秒 |
| remoteok.com | Free plan | 166 毫秒 |
| judge2020.com | Free plan | 174 毫秒 |
| superblog.ai | Pro plan | 159 毫秒 |
| www.jsdelivr.com | Pro plan | 160 毫秒 |
| cdnjs.com | Pro plan | 152 毫秒 |
| unwomen.org.au | Business Plan | 66 毫秒 |
| www.thetrevorproject.org | Business plan | 44 毫秒 |
| decisiondeskhq.com | Business plan | 65 毫秒 |
| www.canva.com | Enterprise plan | 60 毫秒 |
| {无法披露} | Enterprise plan | 54 毫秒 |
| {无法披露} | Enterprise plan | 37 毫秒 |
6. 如何解读这些结果
从各项测试中，我得出以下结论：
- 来自部分印度 ISP 和移动网络的流量，访问 Cloudflare Free 和 Pro 网站时，会由新加坡/阿姆斯特丹节点服务，导致延迟增加。
- 存在这一问题的印度 ISP/移动网络，合计占据超过 75% 的市场份额。
- Cloudflare Business 和 Enterprise 方案上的网站，不会遇到这种重新路由或延迟增加的情况。
7. 其他 CDN 的对比
我对以下 CDN 上的其他网站做了同样的延迟测试：
- AWS CloudFront
- Google Cloud CDN
- Akamai
从 Jio / Airtel 网络访问时，这些 CDN 上的网站都没有出现 Cloudflare Free / Pro 方案上观察到的路由或延迟行为。
8. 网站所有者应该怎么做
如果你的受众主要来自印度，不要想当然地认为 Cloudflare 会提升网站速度。相反：
- 亲自测试效果：分别测量使用和不使用 Cloudflare 时的网站速度，并与 AWS CloudFront、Google Cloud CDN 等替代方案对比。
- 关注不同方案的表现差异：Cloudflare 的路由行为似乎因方案而异，在决定投入前，先评估你打算使用的方案。
Cloudflare 的产品实力毋庸置疑，但在印度，它的 Free 和 Pro 方案可能会拖慢你的网站。所以，先测量，再选择。
暂无评论内容