Cloudflare国内速度怎么测？分地区和运营商看结果

“Cloudflare在国内到底快不快？”

这个问题经常有人问，但它没有一个固定答案。北京联通打开很快，不代表广州移动也快；上海电信命中了缓存，不代表成都电信这一次也会进入同一个节点；同一个网站上午测试正常，晚高峰又可能出现明显波动。

所以，测试Cloudflare国内速度，不能只在自己电脑上打开一次，也不能只看一个全国平均值。

正确的方法是把城市、运营商、响应节点、缓存状态和请求阶段拆开，分别观察P50、P95、成功率和下载速度。

一套有判断价值的测试至少要回答以下问题：

如果只说“我这里延迟180毫秒”，仍然无法判断Cloudflare对真实用户的表现。

测速前先分清：普通全球网络和China Network不是一回事

谈Cloudflare国内速度时，最容易混淆的是两种不同的网络条件。

普通Cloudflare全球网络

大多数个人站长和普通套餐用户接入的是Cloudflare全球网络。

中国大陆用户的请求会根据网络路由、运营商互联和Cloudflare流量调度进入相应机房，但这不等于域名已经使用中国大陆境内的Cloudflare节点。

如果入口位于境外，访问路径会受到跨境网络、运营商路由、晚高峰拥塞和入口位置影响。

即使两个网站都显示“使用Cloudflare”，国内速度也可能完全不同，因为源站位置、缓存命中率、页面大小和业务配置并不相同。

Cloudflare China Network

Cloudflare另外提供China Network。根据Cloudflare当前的China Network官方说明，这项服务通过其合作伙伴京东云在中国大陆的数据中心运行部分Cloudflare性能和安全能力，仅向Enterprise套餐客户提供，并且需要单独订阅。

接入China Network还需要为要接入的顶级域名提供有效的ICP备案或许可证，并不是开通普通Cloudflare账号后自动拥有的能力。具体要求可查看Cloudflare的ICP说明。

因此，测速报告中应该先注明测试对象属于哪一种：

如果不先区分这两种情况，拿普通免费套餐网站的结果去代表Cloudflare China Network，或者反过来比较，结论都会失真。

第一步：确认域名流量是否真的经过Cloudflare

先查看响应头：

curl -sS -D - -o /dev/null https://www.example.com/ \
  | grep -Ei '^(server|cf-ray|cf-cache-status|age):'

可能看到：

server: cloudflare
cf-ray: 9f1234567890abcd-NRT
cf-cache-status: DYNAMIC

Cloudflare在慢速网站排查文档中说明，经过Cloudflare提供的响应会包含 cf-ray。

如果没有这个字段，需要继续确认：

• DNS记录是否开启了Cloudflare代理；

• 当前测试的是否是正确主机名；

• 页面是否跳转到了另一个未经过Cloudflare的域名；

• 前面是否还叠加了其他CDN或反向代理；

• 当前请求是否直接访问了源站IP。

不要只看 server: cloudflare。HTTP响应头可以被修改或保留，最好结合 cf-ray、CNAME、响应IP和ASN等多项证据判断。

可以先使用 CdnChart CDN检测，查看域名解析、响应IP和Cloudflare相关特征。

第二步：查看国内用户进入了哪个Cloudflare机房

对于已经经过Cloudflare代理的域名，可以访问：

curl -sS https://www.example.com/cdn-cgi/trace

返回内容可能包含：

fl=...
h=www.example.com
ip=198.51.100.20
ts=...
visit_scheme=https
colo=NRT
http=http/2
loc=CN
tls=TLSv1.3

其中 colo 是本次请求所连接Cloudflare数据中心的三字母代码。

Cloudflare的/cdn-cgi/端点说明也将 /cdn-cgi/trace 列为识别请求所经过数据中心的排查工具。

这里有三个细节需要注意。

colo只代表这一次请求

同一运营商在不同城市可能进入不同机房；同一城市在不同时段也可能因为路由和容量调整而变化。

不能查一次 colo，就认为全国用户都从这里访问。

Cloudflare官方排查文档也提到，请求没有进入地理距离最近的数据中心，不一定是错误，可能与ISP路由、流量工程和可靠性优先策略有关。

cf-ray后缀不能在所有架构下简单当作用户入口

cf-ray 的三字母后缀通常能提供处理请求的数据中心线索。

不过Cloudflare在HTTP响应头说明中指出，使用Argo Smart Routing或Argo Tiered Caching时，Ray ID中的机房代码可能反映连接源站的数据中心，而不是用户最初进入的数据中心。

所以，复杂架构下应同时查看 /cdn-cgi/trace、Cloudflare日志和账户分析数据。

不要看到某个机房代码就直接判断快慢

物理距离很重要，但并不是全部。

实际速度还取决于运营商路由、丢包、拥塞、缓存是否命中，以及该节点到源站的回源路径。

一个看起来更近的入口，不一定在所有时段都比另一个入口稳定。

speed.cloudflare.com能不能用来测自己网站？

可以用，但它只能回答一部分问题。

speed.cloudflare.com主要测试当前设备到Cloudflare网络的下载、上传、延迟、抖动和丢包。Cloudflare的AIM指标说明也列出了这些网络质量指标。

它适合判断：

• 当前宽带或移动网络本身是否不稳定；

• 当前设备到Cloudflare网络的基础质量如何；

• 下载、上传、延迟、抖动和丢包有没有明显异常。

但是，它不能代替测试你的实际域名。因为实际网站还多了：

• 自己的DNS与CNAME配置；

• 域名实际被调度到的入口；

• Cloudflare缓存规则；

• Workers或WAF处理；

• Cloudflare到源站的回源链路；

• 源站响应时间；

• 页面资源和第三方脚本。

因此，比较实用的方法是把它当作一组“本地网络基线”：

如果speed.cloudflare.com和自己的网站同时变慢，优先怀疑本地网络或ISP路径；如果前者正常、自己的域名明显慢，则应继续检查域名路由、缓存、回源和页面本身。

第三步：选择三类测试对象

Cloudflare国内测速不能只测首页。建议准备三个固定URL，分别解决不同问题。

1. 页面HTML

https://www.example.com/

用于观察真实入口、重定向、动态处理和首字节时间。

但Cloudflare默认并不会把所有HTML都当成普通静态文件缓存，实际行为还会受到Cache Rules和源站响应头影响。

2. 小型静态资源

https://www.example.com/assets/app.css

可以选择Logo、CSS或JavaScript文件。

小文件适合观察DNS、握手、TTFB和缓存命中，因为下载本身占用的时间较短。

3. 固定大小的大文件

https://static.example.com/test/10mb.bin

大文件适合比较持续下载速度。测试文件应该公开、内容固定、允许缓存且没有隐私信息。

不同测试节点必须使用完全相同的URL和文件大小。不要让北京测试5MB文件、广州测试一张图片，然后把总时间放在一起比较。

第四步：按地区和运营商建立测试矩阵

国内测速至少要把地区和运营商拆成两个维度。

一个基础测试矩阵可以这样设计：

这不是要求每次都把所有城市测一遍，而是根据用户分布选择代表性节点。

例如，网站80%的用户位于华东和华南，就应该优先增加上海、杭州、广州和深圳的采样，而不是为了“全国覆盖”平均分配测试次数。

如果网站同时支持IPv4和IPv6，也应分开记录。两个协议可能进入不同路由和入口，把结果混在一起会掩盖问题。

可以使用 CdnChart网站测速，从不同地区和网络观察同一Cloudflare域名的响应情况。

测试完成后，应按地区和运营商分组，而不是只看全国最快、最慢或者总平均值。

第五步：每个节点连续测，不要只测一次

Cloudflare路由、缓存状态和网络条件都会变化。一次结果只能代表那个瞬间。

建议：

• 快速检查：每个节点连续测试5次；

• 配置验证：每个节点测试10次，分开记录首次与重复请求；

• 波动排查：每15～30分钟测试一次，持续至少24小时；

• 晚高峰问题：在高峰前、高峰中和高峰后分别多轮采样；

• 长期观察：保留每日或每周P50、P95和成功率趋势。

测试频率应根据文件大小和业务成本控制。不要对不属于自己的网站发起高频、大文件或并发压力测试。

第六步：用curl记录Cloudflare请求耗时

下面这条命令可以输出一次HTTPS请求的主要时间：

curl -sS -o /dev/null \
  -w 'status=%{http_code}\nip=%{remote_ip}\ndns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nttfb=%{time_starttransfer}\ntotal=%{time_total}\nsize=%{size_download}\nspeed=%{speed_download}\n' \
  https://www.example.com/assets/app.css

示例输出：

status=200
ip=203.0.113.20
dns=0.021482
connect=0.083154
tls=0.162310
ttfb=0.238955
total=0.301226
size=92560
speed=307279

这些数值只是演示，不代表任何真实Cloudflare节点。

size_download 的单位是字节，speed_download 默认表示平均每秒下载的字节数。如果要换算为MiB/s，可以将结果除以 1024 × 1024。

小文件的 speed_download 很容易受到握手和采样时间影响，因此比较吞吐量时应使用固定的较大文件。

各时间字段是从请求开始累计的时间，可以粗略拆分为：

DNS解析时间  = time_namelookup
TCP阶段      = time_connect - time_namelookup
TLS阶段      = time_appconnect - time_connect
首字节前等待 = time_starttransfer - time_appconnect
内容下载阶段 = time_total - time_starttransfer

如果使用HTTP而非HTTPS、发生重定向、经过代理或复用连接，部分字段的解释会不同。排查页面整体速度时，还要结合浏览器Network瀑布图。

连续测试并记录响应头

for i in $(seq 1 5); do
  printf 'request=%s ' "$i"
  curl -sS -o /dev/null \
    -w 'status=%{http_code} ip=%{remote_ip} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' \
    https://www.example.com/assets/app.css
  sleep 2
done

然后单独检查Cloudflare字段：

curl -sS -D - -o /dev/null https://www.example.com/assets/app.css \
  | grep -Ei '^(cf-ray|cf-cache-status|age|cache-control|server):'

不要在常规稳定性测试中给每次请求添加随机时间戳。不同查询参数可能形成不同缓存键，让结果持续显示为冷缓存或 MISS。

国内测速应该重点看哪些指标？

其中，成功率应该排在延迟之前。

一个节点平均延迟很低，但偶尔超时，真实用户体验可能比稍慢但稳定的节点更差。

Cloudflare缓存HIT和MISS要分开看

静态资源第一次请求可能是：

cf-cache-status: MISS

第二次变成：

cf-cache-status: HIT
age: 15

如果 HIT 明显快、MISS 明显慢，说明用户到Cloudflare边缘的链路未必有严重问题，慢的部分更可能发生在缓存未命中后的回源路径或源站处理。

如果已经 HIT，TTFB仍然在特定运营商或地区大幅波动，就更应该检查用户到Cloudflare入口的路由、连接质量、节点变化和边缘处理逻辑。

如果一直显示 DYNAMIC、BYPASS 或 MISS，要确认测试对象是否本来就不可缓存，以及Cookie、查询参数、Cache-Control和Cache Rules有没有影响结果。

Cloudflare的缓存排查说明列出了 HIT、MISS、DYNAMIC、BYPASS、EXPIRED和REVALIDATED等状态，并建议结合缓存规则、响应头和查询参数分析。

不要只看平均值：P50、P95和成功率更重要

假设下面是一组演示结果，不代表CdnChart或Cloudflare的真实数据：

P50接近大多数用户通常遇到的水平；P95用于观察较差的一部分请求。

如果P50正常而P95非常高，说明网站不是“整体都慢”，而是存在节点、路由、时段或缓存状态相关的长尾问题。

不同地区样本数必须尽量接近。上海测100次、成都只测1次，然后比较P95，没有实际意义。

CdnChart测评方法采用P50、P95等分位数观察典型表现和尾部体验。查看Cloudflare国内速度时，也应保留地区和运营商维度，不能用一个全国平均值掩盖局部问题。

不同测速结果分别说明什么？

这张表用于缩小范围，不是最终定责。

比如“移动慢、电信快”可以提示运营商差异，却不能在没有路由、丢包和节点日志时直接认定某一家网络故障。

要不要用ping和MTR？

可以用，但不要把它们当成完整的Cloudflare网站测速。

Ping主要观察ICMP往返延迟和丢包，不能反映DNS解析、TLS握手、HTTP处理、缓存和回源。有些网络设备还会限制或忽略ICMP，所以“Ping不通”不等于网站打不开。

MTR能连续观察路径上各跳的延迟和丢包，适合进一步检查某个运营商到Cloudflare入口的网络路径：

mtr -rw www.example.com

Windows可以使用WinMTR。

分析时重点看问题是否延续到后续节点和最终目标；只有中间一跳显示丢包、后续节点恢复正常，可能只是该设备限制了探测响应，不能直接当作真实业务丢包。

Cloudflare官方也建议在TCP连接或TLS握手时间偏高时，结合MTR检查路径延迟和丢包。

提交技术支持时，应一起提供发生时间、地区、运营商、目标URL、CF-RAY和慢请求结果，而不是只发一张Ping截图。

一套可以直接执行的Cloudflare国内测速流程

第一轮：确认接入和入口

1. 检查域名是否返回 cf-ray；

2. 查询DNS和响应IP是否属于预期网络；
   

3. 使用 /cdn-cgi/trace 记录当前 colo；

4. 分别测试IPv4和IPv6；

5. 确认是普通全球网络还是China Network。

第二轮：固定三个URL

1. 首页或业务HTML；

2. 一个公共小型静态文件；

3. 一个固定大小的大文件。

所有地区使用相同URL，不改变查询参数和文件版本。

第三轮：分地区和运营商采样

1. 华北、华东、华南、西南等重点区域分别选节点；

2. 每个重点城市覆盖电信、联通和移动；

3. 每个节点至少连续测试5次；

4. 记录成功率、响应IP、colo和各阶段耗时；

5. 区分首次请求与缓存命中请求。

第四轮：跨时间重复

在上午、下午、晚高峰和用户投诉时间段重复测试。

如果问题偶尔出现，可以持续24～72小时，而不是在速度恢复后就停止采样。

第五轮：按P50和P95汇总

分别计算：

• 成功率；

• P50和P95 TCP连接时间；

• P50和P95 TTFB；

• 大文件平均及P50下载速度；

• 每个 colo 出现次数；

• HIT、MISS和其他缓存状态占比。

最后把慢请求按地区、运营商、入口机房、缓存状态和时间段交叉查看，问题通常就会从“Cloudflare国内好像有点慢”，缩小到更具体的范围。

Cloudflare国内测速最容易犯的错误

只测自己的宽带

本地结果最多代表当前城市、当前运营商和当前时间。Cloudflare国内体验必须跨地区、跨运营商观察。

只看最快节点

最快结果只能说明理论上有一次表现很好，不能说明普通用户稳定获得同样体验。P95和失败率往往更接近真实投诉。

用speed.cloudflare.com代替目标网站

它可以评估本地网络到Cloudflare的基础质量，但不会替你测试域名自己的缓存、回源、Workers和页面资源。

看到Cloudflare就认为使用了大陆节点

普通全球网络和China Network是不同产品与接入条件。需要结合账户配置、备案情况、节点和官方日志确认。

把MISS和HIT混在一起平均

两类请求经过的链路可能不同。混合以后，既看不清边缘访问质量，也看不清回源性能。

每次给URL添加随机参数

这可能不断制造新缓存键，让正常缓存无法复用。如果专门测试冷缓存，应单独建组并明确标注。

只看延迟，不看成功率

偶尔超时的“低延迟节点”，实际体验可能不如稍慢但稳定的节点。

用一次晚高峰结果决定是否更换CDN

一次异常可能来自本地网络、单个节点或临时路由。

更换服务前，应先通过多轮数据确认问题范围和持续时间。

常见问题

Cloudflare在中国大陆有节点吗？

Cloudflare提供单独的China Network服务，通过合作伙伴在中国大陆运行部分产品和网络能力。

但它是面向Enterprise客户的单独订阅，并要求接入域名具备有效ICP备案或许可证。普通Cloudflare全球网络用户不能自动等同于使用了China Network。

Cloudflare免费版国内速度怎么样？

没有一个适合所有网站的固定结论。

国内速度会受到城市、运营商、跨境路径、入口机房、源站位置、缓存命中和页面内容影响。应对自己的真实域名进行多地区、多运营商测试。

怎么知道访问进入了Cloudflare哪个节点？

可以访问自己域名下的 /cdn-cgi/trace 查看 colo 字段，并结合 cf-ray、响应IP和Cloudflare日志判断。

使用Argo或分层缓存时，不要只靠CF-RAY后缀判断用户入口。

为什么电信快、移动慢，或者反过来？

不同运营商到Cloudflare的互联、出口和路由不同，也可能进入不同机房。

需要对比相同城市、相同URL下的响应IP、colo、TCP、TLS和TTFB。

Cloudflare测速应该测延迟还是下载速度？

网页和小文件主要看连接、TTFB和稳定性；软件、图片、视频和大文件业务还要看持续下载速度。

两者应该分别测试。

Cloudflare的ping很低，网站为什么还是慢？

Ping只覆盖ICMP往返。网站还要经历DNS、TLS、HTTP处理、缓存、可能的回源和页面渲染。

Ping低不能证明页面一定快。

Cloudflare显示HIT为什么国内还是慢？

HIT只说明内容从Cloudflare缓存返回，不代表用户到入口节点的路径一定快速。

还需要检查TCP、TLS、入口机房、运营商路由、丢包和内容下载速度。

每个地区要测试多少次？

快速检查至少5次；正式比较建议10次以上，并覆盖不同时间段。

遇到偶发问题时，还应持续记录24小时以上，再比较P50、P95和失败率。

总结：Cloudflare国内速度必须拆开看

判断Cloudflare在国内快不快，不能只看一张测速截图，更不能用自己家里的宽带代表全国用户。

一套可靠的测试需要做到：

1. 先确认请求确实经过Cloudflare；

2. 区分普通全球网络和Cloudflare China Network；

3. 记录响应IP、colo、cf-ray和缓存状态；

4. 固定HTML、小型静态资源和大文件三个测试对象；

5. 按城市、电信、联通、移动及IPv4/IPv6分别测试；

6. 每个节点执行多轮，并覆盖不同时间段；

7. 同时比较成功率、DNS、TCP、TLS、TTFB、下载速度、P50和P95；

8. 使用Cloudflare和源站日志确认慢请求发生在哪一层。

可以先使用 CdnChart网站测速 对同一个Cloudflare域名进行多地区测试，再使用 CdnChart CDN检测 复核解析、响应IP和厂商特征。

真正有用的结论不应该是“Cloudflare国内快”或者“Cloudflare国内慢”，而应该是：

哪个地区、哪家运营商、在什么时间、经过哪个入口、哪一种缓存状态下出现了问题。