网站测速怎么测？用CDNChart查出哪些地区访问慢

自己打开网站只需要一秒，并不代表所有用户都能得到同样的访问速度。

站长人在上海、使用电信宽带，访问的可能是上海附近的CDN节点；来自黑龙江的移动用户、广东的联通用户或者新加坡的海外用户，命中的节点、线路和响应IP都可能不同。只在自己电脑上刷新几次，最多能够证明“当前网络访问正常”，无法回答网站在全国哪些地区慢。

更有效的网站测速方法，是让不同地区、不同运营商的监测点同时请求同一个域名，再比较HTTP状态码、响应IP、解析时间、连接时间、下载耗时、总耗时和失败节点。

CDNChart的网站测速功能正是围绕这个场景设计的：输入域名后，可以分别查看中国电信、中国联通、中国移动以及港澳台和海外监测点的访问结果，并根据地区、运营商和响应阶段缩小问题范围。

网站测速到底要测什么？

“网站速度”不是一个单独的时间数字。

从用户输入网址到收到网站内容，中间至少会经历以下过程：

1. DNS把域名解析为IP地址；

2. 浏览器与目标IP建立网络连接；

3. HTTPS网站完成TLS握手；

4. CDN节点或源站处理请求；

5. 服务器开始返回内容；

6. 客户端下载响应数据；

7. 浏览器解析HTML并加载图片、CSS和JavaScript；

8. 页面完成渲染并可以交互。

因此，不同测速工具给出的“总耗时”可能不是同一种指标。

CDNChart当前的网站测速主要用于观察域名的HTTP访问链路，包括监测点、运营商、响应IP、IP位置、HTTP状态、解析时间、连接时间、下载耗时、总耗时、重定向和访问失败情况。它适合回答“哪个地区访问慢”“哪家运营商异常”“是否被调度到不同节点”等问题，但不等于完整浏览器页面渲染测试。

如果需要分析首屏图片、JavaScript执行、LCP或INP，还要配合浏览器开发者工具或真实用户监控。MDN对导航和资源加载时序的说明也将DNS查询、连接、请求、响应和浏览器加载拆分为多个阶段，说明页面性能不能只看一个总时间。

用CDNChart进行网站测速的实际步骤

第一步：确认要测试的域名

打开CDNChart网站测速工具，输入实际对外提供服务的域名，例如：

www.example.com

不要想当然地只测试裸域名 example.com。很多网站会把裸域名重定向到 www，或者把不同内容放在不同子域名：

www.example.com
static.example.com
img.example.com
api.example.com
download.example.com

这些子域名可能使用不同的CDN、缓存规则和回源配置。首页速度正常，不代表图片域名、API域名和下载域名也正常。

测试前最好先确定用户真正访问的是哪个域名。如果问题集中在图片加载，就测图片域名；如果用户反馈登录慢，就应检查登录页面及API所使用的域名。

第二步：选择与用户分布一致的监测范围

CDNChart当前提供中国电信、中国联通、中国移动以及港澳台、海外等监测类别。

如果网站用户主要来自中国大陆，不应只选一个“全国”平均结果，而要分别看三大运营商。一个网站可能出现：

• 电信访问正常，移动明显较慢；

• 华东地区较快，东北和西北较慢；

• 国内正常，海外部分国家超时；

• IPv4链路正常，部分网络的IPv6访问异常；

• 某些地区解析到不同的CDN或云服务商。

如果是出海网站，则应优先选择真实用户所在国家或邻近地区。目标用户在日本和新加坡，只测试美国节点，即使结果很好也不能代表实际用户体验。

第三步：启动测速，先看整体结果

测速完成后，不要马上盯着某个最快节点。先看四项整体信息：

• 最快节点；

• 最慢节点；

• 平均耗时；

• 访问失败节点数量。

最快结果只能证明网站在某个条件下表现较好。真正值得关注的，通常是最慢地区、连续失败地区以及同一运营商中明显偏离其他节点的结果。

平均耗时也可能掩盖问题。例如，大多数节点在1秒左右，少数节点超过8秒，平均值看起来可能仍然可以接受，但受影响地区的用户体验已经很差。

因此，网站测速更应该寻找“成片出现的异常”，而不是只比较一个最低数字。

怎样看出网站究竟在哪些地区慢？

测速结果出来后，可以按照“地区—运营商—响应IP—耗时阶段”的顺序判断。

先按运营商筛选

分别查看电信、联通和移动结果，比较同一运营商在不同地区的表现。

如果移动节点普遍慢，而电信和联通基本正常，问题可能与移动线路、移动用户的CDN调度或相关边缘节点有关。此时不能简单归因于服务器性能，因为同一服务器面对其他运营商并没有出现同样问题。

如果三大运营商在某个地区都慢，则更可能涉及：

• 该地区没有合适的边缘节点；

• DNS将用户调度到了较远地区；

• 当地节点回源路径较长；

• 当前域名没有在该区域获得有效覆盖；

• 网站本身或源站在测试期间发生波动。

再按地区观察异常是否集中

一次测速中某个节点偶尔慢，不一定代表整个地区都有问题。家宽线路、测试节点负载和临时网络抖动都可能造成异常。

更值得排查的是以下现象：

• 同一省份多个节点同时较慢；

• 相邻地区出现类似延迟；

• 某个运营商在多个省份持续较慢；

• 同一地区连续多轮测试都出现超时；

• 慢节点集中命中同一个响应IP；

• 工作日晚高峰明显比白天慢。

遇到这种情况，应在不同时间重复测速，而不是凭单次结果更换CDN。

CDNChart公开的测试方法与评分标准也说明，网站测速结果会受到目标站点波动、限流和临时网络抖动影响。测速数据适合发现问题和建立对照，但需要结合样本量、测试时间以及真实业务监控理解。

测速结果中的每个指标怎么看？

HTTP状态码：先确认网站是否真的访问成功

速度再快，返回错误页面也没有意义。

常见状态包括：

• 200：请求正常返回；

• 301、302：发生重定向；

• 403：可能被WAF、访问控制或地区策略拦截；

• 404：请求内容不存在，也可能是回源Host配置错误；

• 429：请求频率受到限制；

• 502、503、504：可能涉及CDN节点、回源链路或源站异常。

如果只有某些地区返回403，而其他地区返回200，应检查WAF地区策略、Bot防护和访问白名单。若多个地区集中出现5xx，需要进一步核对CDN日志和源站状态。

响应IP：判断用户被调度到了哪里

响应IP能够帮助判断不同地区是否连接到相同节点或网络。

例如，华南、华东和东北节点全部解析到同一个响应IP，可能意味着调度范围过于集中；某个慢速地区命中了与其他地区不同的IP，则可以继续检查该IP对应的网络、线路和节点状态。

但要注意，IP数据库显示的位置不能直接等同于服务器机房的精确物理位置。Anycast、IP广播、注册地址和实际流量入口之间可能存在差异。

更可靠的判断方式，是把响应IP与解析时间、连接时间、运营商和多次测速结果放在一起观察。

解析时间：域名在连接之前就已经慢了

解析时间较高，通常说明等待DNS结果耗时较长。可能原因包括：

• CNAME链过长；

• 权威DNS响应不稳定；

• 递归DNS缓存未命中；

• DNS跨境查询；

• DNSSEC验证或上游查询耗时；

• 不同地区使用了不同的递归解析器；

• DNS调度策略过于复杂。

如果很多地区的解析时间都高，应优先检查DNS和CNAME链；如果只有个别运营商较高，则可能与当地递归DNS或调度结果有关。

连接时间：重点看节点距离和网络质量

连接时间主要反映客户端到响应IP之间建立网络连接的成本。

连接时间普遍偏高，可能表示：

• 用户被调度到较远的节点；

• 跨运营商或跨境访问；

• 路由绕行；

• 网络丢包导致握手重传；

• 边缘节点连接处理能力不足；

• IPv4与IPv6访问路径存在差异。

如果解析很快，但连接时间在某个地区明显升高，排查重点就不应该继续停留在DNS，而应转向响应IP、节点位置和网络线路。

下载耗时：不仅与服务器速度有关

下载耗时受到响应大小、网络吞吐、节点负载和缓存状态共同影响。

小文件下载慢，可能是连接质量差、节点处理慢或回源等待；大文件下载慢，则更需要检查持续吞吐、业务带宽、拥塞和限速策略。

比较下载耗时时，应使用相同域名、相同资源和相近测试时间。不能拿一个3KB图标与一个20MB安装包直接比较。

总耗时：用于发现异常，不能代替阶段分析

总耗时最直观，但它只能告诉你请求整体快不快，无法单独说明慢在哪里。

重定向、重复连接、DNS查询、网络传输和服务端处理都可能进入总耗时。出现总耗时高时，要继续查看：

• 解析时间是否异常；

• 连接时间是否异常；

• 下载阶段是否占比过高；

• 是否发生一次或多次重定向；

• HTTP状态是否正常；

• 是否命中了与其他节点不同的响应IP。

不要强行要求各阶段数字简单相加后必须与总耗时完全一致。工具统计边界、重定向和协议处理过程可能有所不同。

常见测速结果应该怎样判断？

这张表只能用于确定排查方向，不是最终故障结论。比如所有地区都慢，可能是源站性能问题，也可能是测试资源本身很大，或者请求发生了多次重定向。

用curl在本地补测一次访问链路

多地区测速找到问题区域后，可以在自己的电脑或目标地区服务器上使用curl补充检查：

curl -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\nredirects=%{num_redirects}\n' \
  https://www.example.com/

重点查看：

• status：最终HTTP状态码；

• remote_ip：实际连接的响应IP；

• dns：从请求开始到DNS解析完成的累计时间；

• connect：从请求开始到TCP连接完成的累计时间；

• tls：从请求开始到TLS握手完成的累计时间；

• ttfb：从请求开始到收到首字节的累计时间；

• total：整个请求总耗时；

• redirects：重定向次数。

这些字段大多是累计时间。如果需要估算某个阶段，应进行相减，例如TCP连接阶段约为：

time_connect - time_namelookup

TLS阶段约为：

time_appconnect - time_connect

curl官方的--write-out文档列出了这些计时变量及输出方式，适合在不同服务器上使用相同命令建立对照。

CDNChart与curl的分工不同：CDNChart用于同时观察多个地区和运营商，curl用于复核某一台设备、某一条网络路径以及更细的协议阶段。

为什么还要关注TTFB和完整页面加载？

CDNChart当前结果可以帮助拆分解析、连接、下载和总耗时，但网站慢不一定全部发生在这些阶段。

TTFB表示从请求开始到收到第一个响应字节的等待时间，它可能包含DNS、连接、TLS、CDN处理、缓存回源和源站响应。web.dev也指出，TTFB是后续页面指标的基础，但不同网站架构下应结合内容交付方式理解，不能孤立地用一个固定阈值判断所有网站。

如果CDNChart显示各地区网络请求都很快，用户仍然觉得页面慢，应继续使用浏览器开发者工具检查：

• 首屏图片是否过大；

• JavaScript是否阻塞渲染；

• CSS和字体是否加载缓慢；

• 页面是否请求大量第三方域名；

• LCP元素是否很晚才被发现；

• 主线程是否长时间执行脚本；

• API返回后是否还有复杂的客户端渲染。

这时问题已经不只是“网站在哪些地区慢”，而是“浏览器拿到内容以后为什么迟迟不能显示”。

一次测速不够，怎样建立可信的结果？

网站测速至少要控制四个变量：测试对象、测试地区、测试时间和缓存状态。

建议按下面的方式保留记录：

测试时间：
测试域名：
测试资源：
目标用户地区：
运营商：
响应IP：
HTTP状态码：
解析时间：
连接时间：
下载耗时：
总耗时：
失败节点：
是否发生重定向：
当时是否处于业务高峰：

新接入CDN时，可以在切换前后使用相同域名或同等大小的测试资源，对比相同地区和运营商。网站出现波动时，则应覆盖白天、晚高峰和周末，而不是只选择一次表现最好的结果。

选择测速平台时，也应确认工具是否真正覆盖目标用户所在地区、是否区分运营商，以及能否显示响应IP和分阶段耗时。网站测速工具对比和CDN测速节点与指标选择的核心区别，也正在于不同工具回答的问题并不完全相同。

常见问题

网站测速怎么测才比较准确？

使用相同域名或资源，从不同地区和运营商重复测试，分别观察状态码、响应IP、解析时间、连接时间、下载耗时、总耗时和失败节点。至少覆盖真实用户所在区域和业务高峰时段。

自己打开很快，为什么测速结果显示外地很慢？

你和外地用户可能使用不同运营商、递归DNS、网络线路和CDN节点。自己的访问结果只能代表当前设备和当前网络，不能代表全国用户。

网站测速应该输入首页还是静态文件？

排查整体访问时可以先测主域名；排查CDN缓存和节点传输时，应再测试具有代表性的静态资源域名。图片、下载、API和主站使用不同子域名时，需要分别测试。

平均耗时正常，是不是网站就没有问题？

不一定。平均值可能掩盖少数地区的严重超时。应继续检查最慢节点、失败节点以及同一地区或运营商是否集中出现异常。

响应IP位置离用户很远，说明CDN调度错误吗？

不一定。IP数据库记录不等于节点精确物理位置，Anycast地址也可能在多个地点广播。需要结合连接时间、路由、运营商和多轮测试判断。

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

DNS缓存、CDN调度、缓存命中、网络拥塞、节点负载和源站波动都会影响结果。轻微变化正常，持续集中在同一地区、运营商或响应IP的异常才更值得排查。

CDNChart测速能测出页面的LCP和JavaScript执行时间吗？

当前网站测速主要观察域名HTTP访问、响应IP和网络阶段耗时，不等同于完整浏览器渲染测试。LCP、INP、脚本执行和页面资源瀑布图需要配合浏览器开发者工具或真实用户监控。

测出某些地区慢以后，是否应该立即更换CDN？

不建议。先确认问题是否能够重复出现，再判断慢在DNS、连接、下载、回源还是前端渲染。CDNChart适合发现区域差异和建立对照，但最终更换CDN前仍应完成真实业务URL测试、厂商试用或POC。