网站有时快有时慢，CDN测速应该怎么测？

上午打开只用了半秒，下午同一个页面却转了三四秒；自己办公室访问很快，客户换一条运营商线路就说卡；测速工具第一次显示正常，刷新一次，结果又差了一大截。

网站明明接入了CDN，为什么速度还是忽快忽慢？

先别急着换CDN。当问题本身是“有时快、有时慢”时，一次测速几乎没有结论价值。

正确做法是固定测试对象和条件，从多个地区、运营商、时间段重复采样，并把首次访问与缓存访问分开。结果不能只看平均值，还要同时看P50、P95、成功率、响应节点和缓存状态。

一套能用于排查的CDN测速，至少要回答下面五个问题：

如果只记录一句“网站打开用了2秒”，上面五个问题一个也回答不了。

为什么同一个网站的测速结果会变化？

一次网站访问，并不是用户直接从CDN“拿到一个速度数字”。它中间要经过域名解析、节点调度、网络连接、TLS握手、CDN缓存查询、可能的回源，以及内容传输和浏览器渲染。

其中任何一段发生变化，最终时间都会变化。

1. 每次可能进入不同的CDN节点

CDN会根据DNS、Anycast路由、运营商网络、节点健康状态和调度策略，把用户导向不同节点。

即使是同一个城市，两次请求也不一定连接相同的IP；IPv4和IPv6还可能进入不同网络。一个节点线路通畅，另一个节点当时拥塞，用户感受到的速度自然不同。

因此，测速时必须记录响应IP或节点标识。否则你只知道“这次慢了”，却不知道慢请求是否集中在某个节点。

2. 一次缓存命中，一次发生回源

同一个URL在CDN节点已有缓存时，可能直接返回；缓存不存在、过期或被绕过时，CDN还要向上游或源站取内容。

于是你可能看到：

# 第一次请求
CF-Cache-Status: MISS

# 再次请求
CF-Cache-Status: HIT
Age: 12

第二次更快并不奇怪。反过来，如果每次测速都添加随机查询参数，也可能不停制造新的缓存键，让每次结果都像首次访问。

所以必须把“冷缓存测试”和“热缓存测试”分开，不能混在同一组数据里求平均值。

3. 源站和应用负载在变化

如果HTML、API或缓存未命中的资源需要回源，源站CPU、数据库、磁盘、连接池、第三方接口和跨区域回源线路都会影响TTFB。

白天访问正常，业务高峰变慢；静态文件很快，首页HTML很慢；CDN显示 MISS 时慢，HIT 时正常——这些现象更像源站或回源链路问题，而不是简单的“CDN节点不行”。

4. 用户网络本身在变化

Wi-Fi信号、移动网络切换、运营商出口拥塞、跨网互联、丢包和路由变化，都会让相同网站在不同时刻表现不同。

只在公司宽带或自己的云服务器上测试，最多能代表这一个位置，不能代表目标用户。

5. 浏览器缓存和连接复用影响了结果

第二次刷新时，浏览器可能直接使用本地缓存，也可能复用已经建立的TCP、TLS或HTTP/2连接。此时DNS查询、握手和部分资源下载都会减少。

因此，“第一次打开”和“刷新后打开”测的不是完全相同的场景。前者更接近新访客，后者更接近连续浏览用户。

6. 页面里的第三方资源不稳定

页面主HTML和本站静态资源可能都很快，但广告、统计脚本、客服组件、字体、地图或外部API卡住了，浏览器里的整体加载时间仍会变慢。

这也是为什么CDN单文件测速和完整网页测速不能互相替代：前者更适合检查网络与内容分发，后者才会暴露资源依赖、JavaScript执行和渲染问题。

CDN测速到底应该测哪些指标？

不要只盯着一个“总耗时”。把总时间拆开，才知道应该找谁解决。

Chrome DevTools的网络请求时间说明把单个请求拆分为DNS Lookup、Initial connection、Waiting（TTFB）和Content Download等阶段。

其中TTFB包含一次网络往返，以及服务器准备响应所花的时间。因此，TTFB高并不能自动证明“源站计算慢”，网络距离、CDN边缘处理和回源路径也可能包含在内。

第一步：先固定测试对象，不要什么都混着测

建议至少准备三类URL。

1. 主页面HTML

例如：

https://www.example.com/

它能反映页面入口、重定向、HTML缓存和源站响应情况，但容易受到登录状态、个性化内容和应用逻辑影响。

2. 小型静态文件

例如一个几十KB的CSS、JavaScript或Logo：

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

小文件的总耗时主要受DNS、连接、TLS和TTFB影响，适合观察节点延迟和缓存是否稳定。

3. 固定大小的大文件

例如一个1MB、5MB或10MB的公开测试文件：

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

大文件更适合观察持续下载速度和吞吐量。文件太小，可能还没进入稳定传输阶段就下载完了；文件每次大小不同，又无法公平比较。

测试文件必须是公开、无敏感信息、内容固定并允许缓存的对象。不要拿用户文件、带签名的私有URL或后台接口做公开测速。

第二步：把首次访问和重复访问分开

如果想知道普通用户的实际体验，至少保留两组结果。

首次访问组

模拟一个此前没有访问过该页面的用户：

• 浏览器本地没有缓存；

• 没有可复用连接；

• CDN边缘缓存也可能是冷的；

• 可能需要完整DNS、TCP和TLS过程。

首次访问更容易暴露冷缓存、回源和连接建立成本。

重复访问组

在相同节点、相同URL和相近时间再次请求：

• CDN缓存可能已经填充；

• 浏览器可能使用本地缓存；

• 网络连接可能被复用。

如果首次访问慢、重复访问稳定变快，重点检查缓存状态、TTL和首次回源过程。如果首次与重复访问都慢，则需要继续看网络路径、CDN节点、源站和文件传输。

需要注意，浏览器本地缓存和CDN缓存不是一回事。

为了单独观察CDN，可以使用命令行发起普通GET请求，并丢弃响应正文，而不是依赖浏览器刷新结果。

第三步：用curl拆分一次请求的时间

下面这条命令可以快速查看一个URL的主要阶段时间：

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.018532
connect=0.051437
tls=0.102219
ttfb=0.168604
total=0.221740
size=86324
speed=389302

这里的时间单位是秒。

需要特别注意：time_connect、time_appconnect 和 time_starttransfer 都是从请求开始累计的时间，不是彼此独立的阶段耗时。

可以粗略这样理解：

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

如果发生重定向、连接复用、代理转发或非HTTPS请求，部分字段会有所不同。这个拆分适合快速定位，不应替代浏览器瀑布图、CDN日志和链路监控。

连续测试十次

for i in $(seq 1 10); 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

如果还要观察缓存状态，可以另外查看响应头：

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

不要为了“避免缓存”而默认给每次请求追加随机参数。那会改变缓存键，测出来的可能始终是冷请求。

只有在专门测试回源或冷缓存时，才应使用可控的不同URL，并将其结果单独分组。

第四步：多地区、多运营商分别测

本地电脑连续测十次，只能回答“你这里怎么样”。CDN是否稳定，需要从目标用户所在网络观察。

如果用户主要在中国大陆，至少应覆盖：

• 电信；

• 联通；

• 移动；

• 业务用户集中的省份；

• IPv4和IPv6，如果网站同时支持。

如果是出海业务，应按真实用户分布选择地区，例如：

• 中国香港、新加坡、日本；

• 美国东部和西部；

• 德国、英国等欧洲主要区域；

• 印度、巴西或中东等实际业务市场。

可以使用 CdnChart网站测速 从不同地区观察同一网站的访问结果。

测试时不要只截图一个“最快节点”或“最慢节点”，要记录每个节点的地区、运营商、响应IP、状态码和各项耗时。

如果不同地区解析到了不同厂商或网络，可以进一步使用 CdnChart CDN检测 查看CNAME、IP/ASN和响应头线索，避免把多CDN调度或厂商迁移误认为单一节点波动。

第五步：同一节点至少测几次？

没有一个适合所有场景的固定次数，但可以按问题严重程度安排。

测速频率不是越高越好。

对生产网站做高频、大文件测试会产生带宽和请求成本，也可能触发防护规则。测试自己的网站时，应根据文件大小、费用和安全策略控制频率；测试第三方网站时，更不能进行高并发压力测试。

不要只看平均值，要看P50、P95和失败率

假设某个节点测了20次，其中18次在200毫秒左右，2次超过3秒。平均值可能看起来还能接受，但那两个慢请求正是用户抱怨“偶尔卡一下”的来源。

因此至少应记录：

下面是一组演示数据，不代表任何真实网站：

如果只看四个节点的平均值，广州移动和法兰克福的问题很容易被掩盖。

CdnChart测评方法使用P50、P95等分位数观察典型表现和尾部体验。对于“网站偶尔慢”的问题，P95通常比单次最好成绩更有诊断价值。

一套可以直接照着执行的测速方案

如果现在有人反馈网站忽快忽慢，可以按下面流程测。

第一轮：十分钟快速复现

1. 固定一个页面HTML、一个静态小文件和一个固定大文件；

2. 从本地分别连续请求5～10次；

3. 记录状态码、响应IP、DNS、TCP、TLS、TTFB和总时间；

4. 查看静态文件的HIT、MISS和Age；

5. 判断慢请求是否集中在首次访问、缓存MISS或某个响应IP。

第二轮：多地区交叉验证

1. 选择与真实用户相符的地区和运营商；

2. 所有节点测试完全相同的URL；

3. 每个节点执行多轮，而不是只测一次；

4. 区分IPv4和IPv6；

5. 汇总每个节点的P50、P95和成功率。

第三轮：跨时间观察

如果前两轮没有稳定复现，就把测试延长到24小时：

• 上午业务低谷；

• 中午；

• 晚间访问高峰；

• 用户集中投诉的时间段；

• 发布、清缓存或流量切换前后。

每次保持测试条件一致，并记录应用发布、缓存清除、DNS修改和CDN规则变更。

没有变更时间线，第二天看到一条慢数据时，很难知道它与什么事件有关。

第四轮：用日志确认责任层

客户端测速只能观察请求链路的结果。要确认问题发生在哪一层，还需要对照：

• CDN访问日志；

• 缓存命中与回源指标；

• 源站访问日志；

• 应用和数据库监控；

• 5xx、超时及连接错误；

• 节点、地区和运营商维度。

Google Cloud CDN的缓存日志与监控说明展示了如何从日志区分缓存命中、验证和未命中，并通过地区流量、缓存命中率、错误率以及P95 TCP往返延迟等指标持续观察CDN状态。

真正的稳定性判断应该来自一段时间的监控，而不是一次手动刷新。

看结果时，怎样定位到底慢在哪里？

可以先用下面这张表做初步判断。

这张表只能用于缩小范围。

比如“TTFB高且MISS”更值得怀疑回源，但并不能在没有日志的情况下直接认定源站有问题。

为什么测速工具和真实用户反馈不一样？

测速工具通常属于受控的合成测试：在指定设备、网络或节点下主动访问页面，适合复现问题和比较修改前后的差异。

真实用户数据则来自不同设备、网络、地区和使用环境，更适合判断一段时间内用户实际经历了什么。

Google在PageSpeed Insights说明中明确区分了实验室数据和真实用户数据：

• 实验室数据适合在受控环境里调试，但可能无法覆盖真实世界的瓶颈；

• 真实用户数据能反映实际体验，却提供较少的诊断细节；

• PageSpeed Insights中的CrUX真实用户数据代表过去28天的样本；

• 一次Lighthouse测试只代表特定模拟环境下的一次加载。

所以，当用户说网站慢、工具却显示很快时，不要简单认为用户网络差，也不要立刻否定测速结果。

更合理的做法是：

• 用多地区合成测试复现；

• 用真实用户监控确认影响范围；

• 再用CDN、源站和应用日志定位原因。

三类证据各自回答不同问题，不能互相替代。

CDN测速最容易犯的八个错误

1. 只测一次

一次结果可能正好遇到冷缓存、网络抖动或连接复用，既不能代表日常速度，也不能说明稳定性。

2. 只看平均值

平均值会掩盖少数极慢请求。“有时慢”本身就是尾部问题，应该重点看P95、最大值和失败率。

3. 只在自己电脑上测

自己快不等于客户快。CDN的价值本来就与地区和运营商有关，单一位置无法代表全国或全球。

4. 每次使用不同URL

随机参数、不同协议、不同主机名和不同文件版本都会改变请求路径或缓存键，最终比较的不是同一个对象。

5. 把浏览器缓存当成CDN缓存

刷新后变快，可能只是浏览器本地已经有文件，不能据此证明CDN边缘缓存命中。

6. 用小文件判断下载带宽

小文件适合看响应延迟，不适合准确判断持续吞吐。测试下载能力应使用固定大小、足够大的公开文件。

7. 只看ping值

Ping测试的是ICMP往返，不能完整反映DNS、TLS、HTTP处理、缓存、回源和内容下载。有些节点还会限制或不响应ICMP。

8. 不记录状态码和缓存结果

一个返回 403 的请求可能非常“快”，一个CDN错误页也可能迅速返回。

只记录时间、不记录响应是否正确，容易把失败当成性能优秀。

常见问题

CDN测速需要测多少次才准确？

快速检查时，每个节点建议至少连续测5次；排查波动时，可以增加到10次，并跨多个时间段持续观察。

比次数更重要的是保持URL、地区、运营商和测试条件一致。

为什么第一次测速慢，第二次就快了？

可能是CDN缓存刚完成填充，也可能是DNS、本地缓存或TCP/TLS连接被复用。

需要同时查看缓存状态、Age、响应IP以及是否清除了浏览器缓存。

为什么本地访问很快，外地用户却很慢？

不同地区和运营商可能进入不同CDN节点和网络路径。

应从用户所在地区、运营商和IP协议重新测试，不能用本地结果代替对方的访问条件。

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

小文件和网页入口更应该关注连接时间与TTFB，大文件下载、视频和软件分发还要关注持续吞吐。

两者解决的问题不同，不能只选一个数字。

P50正常、P95很高是什么意思？

说明大多数请求速度正常，但少部分请求明显更慢。

这正是用户所说“多数时候快，偶尔很卡”的典型表现，需要检查慢样本是否集中在特定节点、时间、运营商或缓存状态。

测速时要不要给URL加随机参数？

日常稳定性测试不要随意添加，因为随机参数可能形成新的缓存键。

如果需要测试冷缓存或强制回源，应单独设计测试组，并明确与正常缓存访问分开。

网站测速结果多少毫秒才算快？

没有脱离用户地区、文件大小、业务类型和缓存状态的统一答案。

与其套用一个固定阈值，不如先建立自己网站的稳定基线，再观察P50、P95、成功率和不同地区之间是否出现明显退化。

怎么判断慢的是CDN还是源站？

先看缓存状态和TTFB：缓存命中时正常、未命中时明显变慢，问题更可能与回源有关；所有请求都慢，则需要继续检查节点、网络和源站。

最终应使用CDN回源日志和源站日志确认，不能只凭一次客户端测速下结论。

总结：测“快不快”容易，测“稳不稳”才有价值

网站有时快有时慢，最怕的不是没有测速工具，而是拿一次结果解释所有用户。

真正有效的CDN测速需要做到：

1. 固定页面、小文件和大文件，避免把不同测试对象混在一起；

2. 区分首次访问、重复访问、缓存HIT和MISS；

3. 从目标用户所在地区、运营商和IPv4/IPv6分别测试；

4. 每个节点进行多轮采样，并覆盖不同时间段；

5. 同时看DNS、TCP、TLS、TTFB、下载时间、P50、P95和成功率；

6. 用CDN与源站日志确认慢请求最终发生在哪一层。

如果只是想快速确认问题分布，可以先使用 CdnChart网站测速，对同一URL进行多地区观察；如果测试结果连接到不同网络或出现多家CDN线索，再使用 CdnChart CDN检测 复核域名解析、响应IP和厂商特征。

不要急着追求一张“全绿”的测速截图。能把偶发慢请求稳定复现、找出它集中在哪个地区和哪个阶段，才是一次真正有用的CDN测速。