网站速度测试：换了CDN，怎么确认访问真的变快了？

更换CDN后，很多人会打开网站刷新几次，感觉页面比以前顺畅，就认为迁移成功了。

这种判断很容易出错。

浏览器可能复用了DNS、连接和本地缓存；新CDN的边缘缓存可能还没有预热；你的电脑只代表当前城市和运营商；DNS切换期间，还有一部分用户仍在访问旧CDN。即使连续刷新十次，也无法说明全国或海外用户是否真的变快。

确认更换CDN是否有效，关键不在于“切换后测一次”，而在于建立一组条件尽量一致的迁移前后数据：

使用相同域名、相同资源、相同地区和运营商，在相近业务时段重复测试，再比较成功率、响应IP、解析时间、连接时间、下载耗时、总耗时以及真实用户体验。

只有这样，才能把CDN带来的变化与缓存、流量、源站负载和网络波动区分开。

为什么换了CDN，自己打开更快也不能说明成功？

一次本地访问至少受到以下因素影响：

• 当前网络是电信、联通还是移动；

• 所在城市距离CDN节点有多远；

• DNS是否仍然缓存旧结果；

• 浏览器是否复用了已有连接；

• 页面资源是否已经进入本地缓存；

• CDN边缘节点是否命中缓存；

• 源站在测试时是否处于高负载；

• 页面是否发生重定向；

• 当前访问的是旧CDN还是新CDN。

例如，站长在上海使用电信宽带，新CDN刚好在华东电信线路表现较好，本地访问确实会变快；但东北移动、西南联通或海外用户可能被调度到更远的节点，整体体验反而下降。

因此，CDN迁移后的第一个问题不应该是“我打开快不快”，而应该是：

• 核心用户所在地区是否变快？

• 原本慢的运营商是否得到改善？

• 最慢的一批访问是否缩短？

• 失败率和错误状态码有没有上升？

• 动态页面、图片和下载资源是否都改善？

• 新CDN是否牺牲了某些地区来换取整体平均值下降？

更换CDN之前，先保存一份旧CDN基线

如果DNS已经全部切换，再想测旧CDN，往往只能依赖之前保存的截图或监控数据。正确顺序是先测旧CDN，再实施迁移。

基线测试至少要包含四类对象。

测试资源不要临时更换。旧CDN测的是一张200KB图片，新CDN却测另一张3MB图片，两组结果没有可比性。

还要记录当时的：

• 测试日期和时间；

• 域名与具体资源；

• DNS记录和CNAME；

• 响应IP；

• HTTP状态码；

• 解析、连接、下载和总耗时；

• 重定向次数；

• 失败节点；

• 缓存状态；

• 网站当时的访问量和源站负载。

如果条件允许，迁移前至少覆盖一次白天、一次晚高峰和一次业务正常时段。流量波动明显的网站，还应覆盖工作日与周末。

用CDNChart建立迁移前后的多地区对照

在切换CDN之前，把实际业务域名放入CDNChart网站测速工具，分别查看中国电信、中国联通、中国移动以及港澳台、海外监测结果。

当前测速结果可以展示监测点、响应IP、IP位置、HTTP状态、解析时间、连接时间、下载耗时、总耗时、重定向和失败节点，并提供最快、最慢和平均结果，适合发现地区及运营商差异。

测试时建议保留以下几组数据：

旧CDN测试时间：
测试域名：
中国电信平均结果：
中国联通平均结果：
中国移动平均结果：
核心海外地区结果：
失败节点数量：
主要响应IP：
异常状态码：
最快节点：
最慢节点：

新CDN接入完成后，在相近时间段使用相同域名重新测试，并按照同样的地区和运营商分类记录。

CDNChart当前主要提供单次多节点观察结果，因此迁移项目中应主动保存每轮数据或截图。不要默认一次测速就能代表迁移前后的长期表现。

切换后先确认：用户访问的真的是新CDN吗？

DNS修改完成，不等于所有用户立即进入新CDN。

本地DNS、运营商递归DNS、浏览器和系统都可能继续缓存旧记录。某些地区已经访问新CDN，另一些地区可能仍然连接旧节点，这时把所有结果放在一起计算平均值会造成误判。

切换后应先比较：

• CNAME是否已经指向新CDN；

• 响应IP是否发生变化；

• 不同地区是否仍返回旧CDN节点；

• IPv4和IPv6是否同时切换；

• 裸域名与www是否使用相同入口；

• 图片、静态资源和API子域名是否全部完成迁移；

• HTTP响应头是否仍带有旧CDN特征。

如果测速结果中同时出现新旧两组响应IP，说明迁移仍处于传播期。此时可以继续观察，但不宜立即得出“新CDN变快了”或“新CDN更慢”的结论。

不修改公共DNS，怎样提前测试新CDN？

在新CDN已经配置好域名和HTTPS证书、但公共DNS尚未切换时，可以使用curl的--resolve指定新CDN测试IP：

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

这条命令把www.example.com临时连接到文档示例地址203.0.113.10。实际测试时应替换为新CDN为该域名提供的测试IP。

与直接访问IP不同，--resolve会保留URL中的域名，因此HTTP Host和TLS SNI仍然是www.example.com，更适合验证HTTPS站点。curl官方的HTTP请求脚本说明也将--resolve用于在开发或测试场景中把指定主机名连接到特定IP。

需要注意：

• 新CDN必须已经绑定该域名；

• 边缘节点必须安装匹配的证书；

• 指定IP必须能够承载该域名；

• 单个IP测试不能代表CDN的真实DNS调度；

• 这种方法适合验证节点和配置，不适合代替全国多地区测速。

确认网站真的变快，要比较哪些指标？

1. 成功率不能下降

速度提升必须建立在请求成功的前提下。

如果新CDN平均耗时下降，但403、502、503、504、TLS失败或超时节点增多，就不能认定迁移成功。对电商、API、登录和支付业务来说，成功率通常比平均速度更重要。

至少要对比：

成功节点数
失败节点数
HTTP 4xx数量
HTTP 5xx数量
TLS或连接失败数量

某个节点偶发失败可能是临时网络抖动；同一地区、同一运营商连续多轮失败，则应优先处理。

2. 不要只比较最快节点

最快节点通常代表最理想的访问条件，却不一定代表主要用户。

更有价值的是比较：

• 中国电信、联通、移动分别有什么变化；

• 核心用户省份是否改善；

• 最慢节点是否缩短；

• 失败节点是否减少；

• 海外目标国家是否改善；

• 慢节点是否集中在某个响应IP；

• 多轮测试的波动范围是否收窄。

如果条件允许，可以把多轮结果汇总为中位数和P95。中位数用于观察典型访问，P95用于观察较慢的一批请求。CDNChart的测速页面能够提供节点级结果、最快、最慢和平均数据；中位数和P95可以根据迁移期间保存的多轮数据另外统计，不应把单次平均值误认为完整分位数。

3. 解析时间是否发生变化

更换CDN通常会修改CNAME和DNS调度链。

如果新CDN的节点连接更快，但CNAME链变长、权威DNS不稳定，最终总耗时未必下降。应检查：

• 解析时间是否整体增加；

• 某个运营商的解析是否明显偏慢；

• CNAME是否出现不必要的多层跳转；

• 新旧DNS TTL是否影响切换；

• IPv4与IPv6解析是否一致；

• 海外递归DNS能否稳定获得结果。

迁移刚完成时，DNS缓存命中情况不同，解析时间可能出现短期波动。应等待传播相对稳定后，再进行正式对比。

4. 连接时间是否在目标地区下降

连接时间更能反映用户到CDN边缘节点之间的网络距离、路由和丢包情况。

如果换CDN后华东电信连接时间下降，但东北移动明显上升，说明新方案并不是简单的“更快”或“更慢”，而是地区覆盖和运营商线路发生了变化。

此时应回到真实用户分布：如果东北移动占业务流量很高，这种退化不能被全国平均值掩盖；如果该地区几乎没有用户，则可以降低其决策权重，但仍应关注是否出现大面积失败。

5. 下载耗时和吞吐是否改善

图片站、下载站、视频和软件分发业务，不能只看连接是否快。

小文件的总时间可能主要消耗在DNS、连接和服务端等待；大文件则更依赖节点出口带宽、线路拥塞和持续吞吐。

迁移前后应使用同一个文件，确保：

• 文件内容和大小一致；

• 压缩方式一致；

• Range请求策略一致；

• 没有一个版本命中缓存、另一个版本回源；

• 没有被WAF、鉴权或防盗链返回不同内容。

如果新CDN首字节更快，但大文件下载速度下降，对下载业务来说未必是改善。

6. 总耗时下降发生在哪个阶段

只知道总耗时减少了还不够，还要知道变化来自哪里。

CDN性能改善不是把所有时间都归功于“节点更快”，而是识别DNS、连接、缓存、回源和下载分别发生了什么变化。

冷缓存和热缓存必须分开测

旧CDN运行时间较长，热门资源通常已经在边缘缓存中。新CDN刚切换时，缓存还没有建立，大量请求可能需要回源。

如果直接用旧CDN热缓存结果对比新CDN首次访问，结果天然对新CDN不利；反过来，只在新CDN预热完成后测试，又可能看不到真实冷缓存和回源能力。

建议分别记录：

• 首次请求或缓存MISS；

• 连续请求后的缓存HIT；

• 缓存过期后的重新验证；

• 不允许缓存的动态请求；

• 大促或发布后新资源首次分发。

不要为了让数据好看而只保留最快的一轮。CDN迁移既要看热缓存交付速度，也要看缓存未命中时源站能否承受回源压力。

怎样避免迁移前后测试条件不一致？

最常见的误判，不是工具不准，而是测试条件已经发生变化。

迁移前后应尽量保持：

• 域名相同；

• URL和文件大小相同；

• 测试地区相同；

• 运营商相同；

• 测试时间段相近；

• 请求方法和Header相同；

• 缓存状态可区分；

• 源站版本与配置相同；

• 页面中第三方资源没有大规模变化。

如果迁移时同时修改了图片格式、开启压缩、升级服务器、调整数据库并重写前端代码，即使网站明显变快，也无法单独计算CDN贡献了多少。

可以优化，但要分阶段上线和记录，否则最后只能知道“整体变快了”，不知道是哪项改动产生了效果。

网站测速变快，真实用户就一定变快了吗？

不一定。

多节点主动测速可以建立统一、可重复的网络基线，却不能完整还原每个用户的设备、浏览器、移动网络、页面行为和本地缓存状态。

web.dev在实验室数据与现场数据的差异中指出，受控测试适合保持条件一致和定位问题，现场数据则来自真实用户的设备、网络与地理环境，两类数据都对性能评估有价值。

因此，正式迁移后还应观察真实用户数据：

• LCP是否改善；

• 页面加载失败率是否下降；

• 移动端与桌面端是否同时改善；

• 各国家和运营商的体验是否一致；

• API错误率和超时是否增加；

• 转化、跳出或关键业务完成率是否异常。

Google对核心Web指标的说明将LCP用于衡量加载性能、INP用于衡量交互响应、CLS用于衡量视觉稳定性。这些页面体验指标不能由一次HTTP请求测速完全替代。

主动测速告诉你“网络交付发生了什么”，真实用户监控告诉你“用户最终感受到了什么”。

一张可以直接使用的迁移对照表

下面这张表不要预先填写固定阈值，而应根据网站原有表现和业务要求记录。

如果还不清楚不同地区和运营商应怎样组织测试，网站测速怎么测的核心方法，就是先按用户分布选择节点，再从状态码、响应IP和分阶段耗时缩小范围。

CDNChart适合完成迁移前后的多地区主动探测和异常发现。平台数据的样本门槛、区域覆盖与已知限制，则可以通过CDN测试方法与评分标准核对。最终是否切换全部流量，仍应结合真实业务监控、CDN日志、源站负载、合同成本和POC结果决定。

常见问题

换CDN后应该等多久再测速？

可以在切换后立即测试配置和可用性，但正式性能结论应等主要地区的DNS传播相对稳定，并覆盖至少一个完整业务周期。流量差异明显的网站最好观察多个高峰与低峰时段。

新CDN平均速度更快，但部分地区更慢，应该换吗？

要看这些地区的真实用户占比和业务重要性。核心市场出现明显退化时，不能用全国平均值抵消；非核心地区的轻微变化则可以结合成本、稳定性和覆盖综合判断。

为什么新CDN刚切换时反而更慢？

常见原因包括边缘缓存尚未预热、DNS仍在传播、首次请求需要回源、新节点连接尚未复用，或者回源Host、HTTPS和缓存规则配置不完整。

只测试网站首页够不够？

不够。首页可能是动态页面，图片、JavaScript、下载文件和API可能使用不同域名、缓存规则与回源路径。至少应覆盖首页、静态资源、中等文件和关键动态接口。

Ping变低能证明CDN更快吗？

不能。Ping主要反映ICMP往返延迟，不包含DNS、TLS、HTTP处理、缓存回源和内容下载。部分CDN节点还可能限制或不响应ICMP。

是否应该清除浏览器缓存后再比较？

浏览器测试时可以分别记录首次访问和缓存访问，但更换CDN的网络对照应优先使用多节点HTTP测试或curl。只清理浏览器缓存仍然无法控制DNS、运营商和节点调度差异。

CDNChart能直接比较新旧CDN的历史结果吗？

当前网站测速主要提供单次任务的多地区和运营商结果。迁移前后应主动保存测试时间、节点结果和截图，再按照相同条件进行对照，不应假设平台自动完成长期历史对比。

什么情况说明更换CDN没有解决问题？

如果连接时间有所下降，但动态页面和API仍然慢，问题可能主要在源站处理、数据库或回源链路；如果所有CDN测试都正常而页面仍慢，则应继续检查图片、JavaScript、第三方资源和浏览器渲染。