CDN测速网怎么选？先检查节点、指标和结果记录

把域名输入CDN测速网，等几十秒，页面上出现一片绿色，平均响应时间看起来也不高——这是不是说明CDN速度很好？

未必。

如果测试页面没有告诉你请求从哪里发出、使用哪家运营商、解析到了哪个IP、文件有多大、返回什么状态码以及是否命中缓存，那么这个“平均速度”很难解释。

它可能真的代表网站很快，也可能只是少数节点请求了一个很小的文件，或者所有慢节点都被平均值藏了起来。

选择CDN测速网，重点不是界面上有多少个亮点，而是先检查三件事：节点能不能代表你的用户，指标能不能定位慢在哪里，结果能不能保存并重复验证。

先确定这次测速要回答什么问题

同样是“测网站速度”，目的不同，应该选择的工具和测试对象也不一样。

CDN测速更关注请求从不同网络到达边缘节点后的网络和交付表现；网页性能测试还会把浏览器渲染、JavaScript执行、图片布局和第三方脚本计算进去。

两种结果都重要，但不能用一个结果替代另一个。

Google对PageSpeed Insights的说明也明确区分了实验室数据和真实用户数据：实验室测试适合在受控条件下诊断，真实用户数据更接近实际体验，但指标和样本范围有限。详见PageSpeed Insights数据说明。

因此，在找“哪个CDN测速网站好用”之前，先把问题说具体。否则很容易拿页面性能分数评价CDN线路，或者拿一个静态文件的下载速度判断整个网站体验。

第一项先看测速节点：数量多，不等于覆盖有效

测速节点决定了结果代表谁。北京联通节点测出来的成绩，不能代替广州移动；新加坡云服务器的结果，也不能代表印度尼西亚普通家庭宽带用户。

一个适合做CDN测试的网站，至少应该公开以下节点信息：

• 国家、地区和城市；

• 接入运营商或网络类型；

• 节点是否在线以及最近检测时间；

• 节点数量和实际参与本次测试的数量；

• 失败、超时和未返回结果的节点；

• 如果条件允许，提供节点ASN或网络归属信息。

中国大陆用户为主，至少要交叉看地区和运营商

如果网站主要服务中国大陆用户，不能只按“北京、上海、广州”选点，还要在核心城市分别覆盖中国电信、中国联通和中国移动。

例如，北京电信访问快，并不能证明北京移动也快；杭州移动表现不错，也不能代表成都移动没有绕路。

同一个地区的跨运营商比较，往往比同一家运营商测很多城市更容易发现线路短板。

测试范围可以先包含：

• 用户量或订单量最高的省市；

• 华北、华东、华南、华中、西南、西北、东北的代表点；

• 每个核心区域中的电信、联通、移动；

• 用户确实较多时，再增加广电、教育网或其他网络。

具体地区权重不必平均分配，应参考自己的访问日志、订单和用户价值。相关方法可以继续阅读《中国大陆用户为主，选CDN应该重点看哪些地区和运营商？》。

海外用户为主，不要只看一个“海外节点”分类

海外不是一个网络环境。东京、洛杉矶、法兰克福和圣保罗之间的距离、运营商互联与跨境路径差异很大。

出海网站应根据真实用户国家选择节点。例如用户集中在东南亚，就优先覆盖新加坡、日本、印度尼西亚、泰国、越南等主要市场，而不是因为北美节点容易获得，就用大量美国测试结果计算“全球平均速度”。

同一国家有多个主要网络时，也应尽量交叉测试。

无法覆盖当地家庭宽带和移动网络的云服务器节点，只能作为一个合成探测视角，不能完全代替当地真实用户。

还要看本次究竟有多少节点成功返回

页面写着“全球300个节点”，本次真正完成测试的可能只有其中一部分。

如果测速网只计算成功节点，不展示超时和失败，最后的平均值自然会显得很好看。

因此要同时检查：

• 总计划节点数；

• 实际启动节点数；

• 成功、失败和超时数量；

• 哪些地区没有返回数据；

• 失败结果有没有进入可用率统计。

缺失数据本身就是结果。某个运营商的大量节点全部超时，不能简单地从平均值里删掉。

第二项看测速指标：总耗时只能说明慢，不能说明为什么慢

一次HTTPS请求大致会经过DNS解析、建立TCP连接、TLS握手、发送请求、等待首字节和下载响应内容等阶段。

只显示一个“响应时间”，最多只能告诉你这个请求整体用了多久。想判断问题发生在哪里，需要看到更细的指标。

Chrome开发者工具的Network面板会展示请求状态、协议、远程地址、响应大小、总时间和瀑布图，并允许查看单个请求的详细Timing。

官方文档还特别说明，可以关闭浏览器缓存来模拟首次访问。详见Chrome DevTools Network参考文档。

一个测速网站不一定要提供浏览器工具的全部信息，但DNS、连接、TLS、TTFB、下载、状态码和解析IP越完整，越有利于定位问题。

为什么P50和P95比一次最快成绩更有用？

网络性能天然会波动。同一个节点连续测试几次，结果不同很正常。节点负载、网络拥塞、DNS缓存、TCP连接复用和源站状态都可能影响单次请求。

因此不要把下面这些结果直接当成结论：

• 本轮最快节点；

• 一次测试的全国平均值；

• 所有成功请求中最低的一次延迟；

• 没有样本量说明的“综合速度”；

• 不同时间、不同文件得出的厂商排名。

P50可以理解为比较典型的中间水平；P95更接近较慢的尾部请求。

一个CDN的P50很好、P95明显偏高，往往说明大多数时候很快，但部分地区、时段或请求存在不稳定。

选择CDN测速网时，最好确认它是否提供：

• 每个地区和运营商的样本数；

• P50、P90或P95等分位数；

• 失败率与超时率；

• 数据采集时间及统计周期；

• 是否允许按地区、运营商和时间筛选。

如果平台只有单次测试，也可以自己在多个时段重复执行并保存原始结果。

不要为了凑出“绝对准确”的小数而追求虚假的精确，测试的目的，是找到稳定差异和异常模式。

第三项看结果记录：不能复查的测速，很难用于决策

很多测速结果当时看了一眼，第二天就只剩一句“昨天好像挺快”。

等到CDN调整线路或者用户再次投诉，已经找不到当时测了哪个URL、用了哪些节点以及解析到了什么IP。

一个便于长期使用的CDN测速网，最好能够保存或导出以下内容：

测试时间和时区
测试URL及最终跳转URL
节点国家、城市和运营商
解析IP及网络归属
HTTP状态码和协议版本
响应大小或测试文件大小
DNS、TCP、TLS、TTFB、下载及总耗时
下载速度
缓存状态
失败原因和错误信息
本轮样本数

如果工具提供分享链接、历史记录、CSV或JSON导出，会更适合做接入前后比较。没有导出功能时，至少保存截图，并把测试条件另行记录下来。

200状态码不一定代表测试成功

有些网站被WAF拦截后会返回一个HTTP 200的验证页面；错误配置也可能把不存在的资源跳转到首页。

只看状态码，会把错误内容当成成功结果。

重要测试还应该核对：

• 最终URL有没有发生跳转；

• 响应体大小是否符合预期；

• Content-Type是否正确；

• 必要时比较文件哈希或内容特征；

• 有没有返回验证码、登录页或WAF挑战页面。

尤其是测试大文件时，应该确认完整内容确实下载完成，而不是服务器返回了一段很小的错误信息。

缓存状态不分开，CDN测速结果很容易看错

同一个URL第一次请求可能需要回源，后续请求可能直接从边缘缓存返回。两类请求走过的路径不同，不应该混在一起解释。

测试时可以把场景分成三组：

不同CDN使用的缓存响应头名称并不完全相同。常见的HIT、MISS和Age可以作为线索，但要结合厂商文档解释。

没有看到缓存头，也不能仅凭这一点认定没有使用缓存。

如果需要进一步判断，可以先阅读《CDN缓存命中怎么看？HIT、MISS和Age怎么理解》，或使用CDNChart CDN检测查看域名的CNAME、节点IP及可能使用的CDN。

测首页、静态文件还是下载文件？答案是分别测

只测试首页有一个明显问题：页面可能同时请求广告、统计代码、字体、图片和第三方接口。慢的是CDN、源站还是第三方资源，很难从首页总耗时里直接判断。

只测一个小静态文件也不够。它可以观察连接和首字节，却很难代表持续下载能力。

比较完整的测试对象可以包含以下几类。

一个页面文档

用于观察HTML访问、跳转、动态回源和页面入口是否正常。

测试时记录最终URL，避免把重定向耗时忽略掉。

一个固定的小型静态文件

例如真实业务中的CSS、JavaScript或图片，用于观察节点连接、TTFB和缓存命中。

文件应保持不变，避免测试期间内容和大小变化。

一个固定的大文件

根据业务准备数MB到数十MB的公开测试文件，用于观察持续吞吐和传输稳定性。

文件过小，下载可能刚开始就结束，计算出来的速度容易受连接建立和计时误差影响。

一个关键动态接口

仅测试无需敏感参数、不会修改数据、允许公开访问的接口。

不要把登录凭据、用户Token、内部地址或带私人信息的URL提交到第三方测速平台。

这几类URL应该分别统计，不能把小文件TTFB、页面总耗时和大文件下载速度混成一个“综合平均值”。

用相同条件比较两个CDN，结果才有意义

假设要比较CDN A和CDN B，至少保持以下条件一致：

• 使用相同源站或内容副本；

• 测试文件内容和大小相同；

• 缓存规则、压缩和Range设置相同；

• 选择相同地区和运营商节点；

• 使用相同超时标准和并发设置；

• 在接近的时间窗口内测试；

• 热缓存和冷缓存分别比较；

• 每个测试单元使用相近样本量。

如果A使用20MB文件，B使用200KB文件；A在晚高峰测试，B在凌晨测试；或者A全部是缓存HIT，B多数需要回源，最后的数字无法公平比较。

需要筛选候选厂商时，可以先使用CDNChart厂商对比查看统一口径下的数据，再用自己的域名和业务文件进行验证。

排行榜适合缩小范围，不能代替真实业务试用。

一套可以直接执行的CDN测速流程

测试前：把条件固定下来

准备页面、小文件、大文件和必要的动态URL，记录文件大小、缓存规则、源站位置、测试日期以及CDN配置版本。

先通过DNS或CDN检测工具确认域名当前解析状态，避免CNAME尚未生效或部分地区仍在访问旧节点。

第一轮：快速发现地区与运营商异常

使用CDNChart网站测速或其他多节点工具，覆盖主要地区和运营商，先看成功率、状态码、解析IP、TTFB和总耗时。

这一轮不是为了直接评选最快CDN，而是找出明显异常：哪些地区超时、哪家运营商偏慢、是否被调度到意外节点。

第二轮：用固定资源重复测试

针对正常和异常区域，在不同时间重复测试相同URL。

至少覆盖一个业务低峰和一个业务高峰；用户主要在晚间访问时，就不要只在工作日上午测试。

分别统计P50、P95、失败率和下载速度。若测速平台没有分位数功能，可以导出原始记录后自行计算。

第三轮：结合浏览器和服务端日志定位

多节点结果显示某地TTFB高时，再检查浏览器Network瀑布图、CDN日志和源站日志：

• DNS慢：检查权威DNS、解析链和本地解析差异；

• TCP或TLS慢：检查调度IP、网络路径和协议配置；

• TTFB慢且多为MISS：检查回源线路与源站处理；

• HIT仍然慢：检查边缘节点、线路和响应体大小；

• 大文件吞吐低：持续测试并排除源站、限速和业务带宽问题。

第四轮：保留基线，用于以后复测

把正常时期的结果保存下来。

以后修改DNS、缓存策略、证书、HTTP版本或CDN厂商时，按照相同条件复测。

没有基线，就只能知道“今天是1.2秒”，却无法判断它比上周变快还是变慢。

本地用curl做一次辅助记录

多节点测速适合观察地域差异，本地命令则适合快速核对某个URL的连接阶段、远程IP和下载速度。

curl -L -o /dev/null -sS \
  -w 'status=%{http_code}\nremote_ip=%{remote_ip}\ndns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nttfb=%{time_starttransfer}\ntotal=%{time_total}\nspeed_download=%{speed_download}\n' \
  https://example.com/test-file.bin

需要注意，curl输出的这些时间多数是从请求开始累计到对应阶段的时间，并不是彼此独立、可以直接相加的分段耗时。

例如，time_connect已经包含此前的DNS时间，time_appconnect也包含前面的连接过程。

这个命令只能代表执行机器所在网络的一次结果。它不能代替全国或全球多节点测试，但很适合检查URL、状态码、远程IP和测试文件是否正确。

CDN测速网值不值得长期使用，可以这样评分

下面是一套选择工具时的示例评分，不是行业统一标准，可以根据业务调整。

如果只是临时检查网站能不能打开，工具不必具备全部能力；如果要比较CDN厂商、调整生产配置或形成月度报告，方法说明和原始结果记录就非常重要。

这些漂亮结果，看到后先别急着高兴

“全国平均只要几十毫秒”

先看平均值包含多少成功节点、失败节点是否被排除、测试的是哪个阶段。

如果只计算了成功请求的连接时间，这个数字不能代表完整的网站访问体验。

“最快节点只用了几毫秒”

最快节点可能恰好与CDN位于同一机房或同一网络。

它能证明这个节点的最好情况，却不能说明大多数用户的体验。

“所有地区都是HTTP 200”

继续检查响应大小、最终URL和内容。

200可能返回的是WAF验证页、默认首页或一段错误提示。

“下载速度特别高”

检查测试文件大小。

如果文件太小，连接刚建立就下载完了，瞬时结果不适合评价持续吞吐。

“A测速网说快，B测速网说慢”

先比较两边的节点位置、运营商、测试时间、URL、缓存状态、超时标准和统计方法。

两个工具观察的网络环境不同，结果不一致并不必然说明其中一个错误。

常见问题

CDN测速网站哪个好？

没有一个工具适合所有目的。

选择时优先看它是否覆盖你的用户地区和运营商，是否提供DNS、连接、TLS、TTFB、下载、状态码和解析IP，以及结果能否保存复查。页面是否漂亮反而不是主要条件。

CDN测速和网站测速有什么区别？

CDN测速更关注节点调度、网络连接、缓存交付和下载能力；完整的网站测速还会分析浏览器渲染、JavaScript、图片、字体和第三方资源。

排查实际问题时，两者通常需要结合。

测试节点是不是越多越准确？

不是。节点需要与用户分布匹配，并且标明地区、运营商和在线状态。

大量集中在非目标市场的节点，可能让样本更多，却让结论离真实用户更远。

CDN测速应该测试域名还是具体URL？

排查DNS和节点识别时可以从域名开始；评估性能时应使用具体URL，并分别准备页面、小型静态文件、大文件和必要的动态接口。

只输入首页域名，很难定位具体资源的问题。

为什么同一个网站每次测速都不一样？

网络拥塞、节点负载、DNS缓存、CDN调度、缓存HIT或MISS、源站状态都会带来波动。

应在相同条件下重复测试，并比较P50、P95、成功率和异常分布，而不是要求每次数字完全相同。

一次测速结果可以决定要不要更换CDN吗？

不建议。一次结果适合发现线索，不足以证明长期表现。

先在CDNChart网站测速中找出异常地区和运营商，再用固定文件覆盖多个时段重复验证，同时结合CDN日志、源站日志和真实用户数据。

当不同工具、多个时段和真实用户数据都指向同一个问题时，才更适合进入配置优化、厂商沟通或小流量切换测试。