中国大陆用户为主，选CDN应该重点看哪些地区和运营商？

“我们在全国有很多CDN节点。”

这句话听起来很有吸引力，却回答不了一个更实际的问题：我的用户访问时，到底快不快？

中国大陆的网络环境不是一张均匀铺开的网。同一个网站，在上海电信访问顺畅，不代表在广州移动、北京联通或者成都电信也有同样的表现。即使两名用户身处同一座城市，因为接入运营商不同，也可能被调度到不同节点，走不同的网络路径。

因此，面向中国大陆用户选CDN，不能只看厂商总节点数，也不能只在自己办公室里打开一次网站。真正有用的选型方法，是先弄清楚用户在哪里、使用什么网络，再建立一张“地区 × 运营商”的测试矩阵。

先说结论：三大运营商都要测，地区按真实用户分布排序

如果网站的大部分用户位于中国大陆，电信、联通、移动通常都属于必测项。至于先测哪些城市，不应该照搬一张固定的“全国重点城市名单”，而要先看自己的访问日志或统计平台。

可以把测试范围分成三层：

如果预算或测试资源有限，宁可先在三个核心城市分别测试三大运营商，也不要只测十个城市的同一家运营商。

同城跨运营商对比，往往比同运营商跨很多城市更容易发现问题。

为什么同一个城市，三家运营商的结果也会不同？

CDN不会简单地把所有用户送到地理距离最近的节点。实际调度还会受到DNS解析、运营商网络、节点负载、线路互联以及CDN调度策略等因素影响。

例如，同在杭州的三名用户：

• 电信用户可能命中杭州或上海的电信节点；

• 联通用户可能被调度到另一个联通覆盖节点；

• 移动用户可能命中移动线路节点，也可能出现跨网访问。

节点的物理距离只是一个因素。节点离用户不远，如果中间存在跨运营商互联、绕路或拥塞，TCP连接和首字节时间仍然可能偏高。反过来，一个稍远但线路质量更好的节点，实际访问反而更稳定。

这也是为什么“节点数量多”不能直接等于“用户访问快”。节点部署位置、出口容量、运营商互联质量、调度准确度和高峰期负载，都会影响最终结果。

先画出自己的用户地图，不要拿全国平均值替代

在联系CDN厂商或开始试用之前，先从网站统计、服务端访问日志、订单数据或客户端监控中回答几个问题：

• 用户主要来自哪些省份和城市？

• 电信、联通、移动分别占多少？有没有较多广电或校园网用户？

• 用户主要使用固定宽带还是移动网络？

• 哪些地区贡献的只是访问量，哪些地区贡献了注册、订单或付费？

• 访问高峰在什么时候？晚间和工作日白天的表现是否不同？

• 用户主要访问网页、小图片、下载文件、视频，还是API接口？

这里有一个容易忽略的细节：流量占比不等于业务权重。

某个地区可能只占10%的访问量，却贡献25%的订单。如果仍按访问次数平均分配权重，最终选择出来的CDN可能对“人多但价值低”的区域表现很好，却拖慢真正重要的交易用户。

没有完整统计数据时，可以先使用最近30天的访问日志建立初版分布，再逐步补充真实用户监控。不要用CDN厂商给出的全国平均成绩代替自己的用户结构，因为平均值会把局部问题藏起来。

中国大陆应该选哪些代表地区？

下面这张表适合用来补齐全国覆盖，但它不是不可更改的标准答案。代表城市可以根据用户分布和测试节点可用性替换。

测试城市不是越多越好。更实用的做法是：先覆盖主要收入地区，再为没有覆盖到的大区增加代表点。如果某个省份持续出现投诉或较高超时率，再下钻到该省的不同城市和运营商。

对于用户高度集中的本地业务，测试范围还可以更窄。比如用户绝大多数来自广东，就应该先把广州、深圳及其他核心城市的电信、联通、移动测细，而不是为了看起来“全国覆盖”，把有限样本平均撒到几十个城市。

电信、联通、移动之外，还要不要测其他网络？

电信、联通、移动：通常是基础必测项

这三类网络覆盖了大多数常见访问场景。任何一家出现明显短板，都可能形成一批“别人都说快，我这里却打不开”的用户。

但三家运营商也不应该只各测一个点。北京联通表现好，不代表东北或西北的联通用户一定相同；广州移动速度快，也不能代表西南移动。运营商维度需要和地区维度交叉起来看。

中国广电：按用户构成决定优先级

如果业务的家庭宽带、电视端或下沉市场用户较多，可以把广电网络加入试验范围。如果日志里相关用户很少，则不必在第一轮选型时给它过高权重。

教育网：校园用户多时必须单独看

在线教育、论文资源、开发工具、校园社区等业务，可能有较多教育网用户。此时只测试三大运营商不够。

教育网的访问路径和普通公众网络不完全相同，应当通过校园网络实测或真实用户数据验证。

企业专线、政务外网等：不要用公网测试结果代替

如果客户通过专线、办公网或受控网络访问，普通公网探测只能作为参考。更可靠的方式是在真实客户网络中做低风险验证，并检查代理、防火墙、DNS和出口策略是否参与了访问过程。

不同业务，地区和运营商相同，指标优先级也不同

选择CDN不能只问“平均延迟多少”。同样一组节点，对资讯网站可能很好，对大文件下载或动态API却未必合适。

游戏业务还需要区分资源分发与实时连接。CDN适合分发安装包、补丁、图片和静态资源，但实时对战连接通常需要专门的网络加速方案，不能用一个静态文件测速结果替代。

选型时，先看可用率，再看P95

一个测试点偶尔跑出很快的成绩，并没有太大意义。用户每天访问成千上万次，真正影响体验的是“多数时候有多快”和“最慢的那一部分有多糟”。

建议按下面的顺序观察：

1. 可用率、超时率和错误率：如果请求经常失败，平均速度再快也不应进入最终候选。

2. P95延迟：比单次最快成绩或简单平均值更容易暴露高峰拥塞和偶发慢请求。

3. P50延迟：用于了解日常、典型访问水平。

4. TTFB、TCP和TLS耗时：帮助判断慢在连接、握手、节点处理还是回源。

5. 下载吞吐量：对安装包、视频和大图比单纯TTFB更重要。

6. 缓存命中率和回源流量：决定用户是否真正从边缘节点获取内容，也会影响源站压力和成本。

7. DNS解析和调度结果：观察不同地区、运营商被分配到了哪个节点，是否存在远距离调度或跨网访问。

腾讯云CDN的官方监控文档也将带宽、流量、请求数、流量命中率、状态码等作为访问监控指标，并支持按地区或运营商筛选。这说明CDN评估本身就不应只剩下一项“延迟”。可参考腾讯云CDN访问监控说明。

阿里云CDN的实时监控同样提供地域、运营商等筛选维度，可参考阿里云CDN实时监控文档。

如果不熟悉P50、P95和样本量，可以先阅读CDNChart测评方法。看懂分位数以后，就不容易被一次很漂亮的测速结果带偏。

怎样给地区和运营商分配权重？

最简单的思路，是让选型分数接近真实业务：

综合结果 = 各“地区 × 运营商”测试结果 × 用户占比 × 业务价值权重

假设某网站的用户主要来自华东和华南，可以建立如下测试表。以下数字只是演示计算方法，并不是对任何行业或网站的推荐比例。

不要为了得到一个“89.7分”而制造虚假的精确感。权重的意义，是避免低价值地区的大量测试样本淹没核心市场，也避免某个厂商凭借少数优势节点赢得整体比较。

另外可以设置淘汰线：例如某个核心地区连续出现明显超时，或者关键运营商的可用率低于业务要求，即使综合得分尚可，也先不进入正式切换阶段。

具体阈值应根据自身SLA和历史基线确定，而不是照抄别人的数字。

一轮可执行的CDN试用测试怎么做？

先通过CDN排行榜和CDN厂商对比筛出2到4个候选服务，再申请测试或小流量试用。测试条件尽量保持一致，否则比较没有意义。

准备相同的测试对象

每家候选CDN使用相同的源站、缓存规则和文件：

• 一个真实页面或HTML文件；

• 一个常用的小型静态资源；

• 一个固定大小的公开测试文件，例如5MB到20MB；

• 业务需要时，再增加图片、视频分片或API接口。

不要只测首页。首页可能包含动态内容和第三方脚本，很难判断慢在哪里；也不要只测一个完全缓存的静态小文件，因为它无法代表回源和大文件吞吐。

把冷缓存和热缓存分开

首次请求发生回源，后续请求可能直接命中边缘缓存，两种结果不能混在一起平均。

• 冷缓存测试用于观察回源路径和首次访问；

• 热缓存测试用于观察边缘节点交付能力；

• 动态请求则要单独评估连接复用、回源延迟和错误率。

保持每个测试单元的样本量接近

“上海电信测了500次，成都移动只测3次”不适合直接比较。每个核心地区和运营商组合应尽量采用相近的采样频率，并覆盖工作日、周末以及业务高峰时段。

可以先用CDNChart网站测速观察不同地区与线路的访问差异，再结合服务端日志或真实用户监控验证。

公开探测适合横向发现问题，真实用户数据则更接近最终体验，两者不应互相替代。

每条测试记录至少保留这些字段：

测试时间、地区、城市、运营商、解析IP、节点ASN、HTTP状态码、
DNS耗时、TCP耗时、TLS耗时、TTFB、总耗时、下载速度、
缓存状态、文件大小、测试URL

进行测试时应控制请求频率，使用自有域名或已获得授权的测试目标，不要把测速变成未经许可的压力测试。

看到测速结果后，怎么判断问题在哪里？

如果某个域名在不同网络解析到了不同IP，这是CDN智能调度的常见现象，不应直接判定为故障。

可以使用CDN检测工具查看域名的CNAME、节点IP和可能使用的CDN，再结合各地解析结果判断是否存在异常调度。

性能之外，采购前还要确认这些条件

测速过关只是第一轮。正式选型时，还应把以下内容写进评估表：

• 服务区域以及中国大陆接入、域名备案和内容合规要求；

• SLA如何定义，可用率如何计算，未达到承诺如何处理；

• 按流量、带宽峰值、请求数和HTTPS等项目计费的实际成本；

• 缓存规则、刷新预热速度、回源策略和日志可见度；

• 是否支持按省份、运营商查看监控数据；

• WAF、DDoS防护、访问控制和证书管理能力；

• 故障时的技术支持响应速度；

• 是否需要多CDN调度或备用方案，以及切换是否足够可控。

尤其要问清楚日志和监控粒度。一个CDN即使当前表现不错，如果上线后不能按地区、运营商和状态码拆分问题，后续排障成本仍然会很高。

常见问题

国内用户为主，是不是一定要选择国内CDN厂商？

不一定。应该比较候选厂商在中国大陆的实际服务能力、接入条件、线路覆盖、合规要求、成本和支持能力，而不是只看品牌注册地。最终仍要以真实地区和运营商测试结果为准。

CDN节点越多，速度一定越快吗？

不一定。节点数量没有体现节点容量、部署位置、运营商互联、调度准确度和高峰负载。

与其问“有多少节点”，不如问“我的核心用户会被调度到哪里，高峰期P95和可用率是多少”。

为什么不能只看全国平均延迟？

全国平均值会把局部问题稀释掉。某个核心运营商很慢，可能被其他大量快速样本拉回一个看似正常的平均数。

至少要拆分地区、运营商，并同时观察P50、P95和可用率。

测试时需要覆盖所有省份吗？

第一轮通常不需要。先覆盖核心用户地区和七个大区的代表点，根据异常和投诉再扩大。

全省覆盖更适合上线后的持续监控，而不是每次初筛都平均投入同样资源。

预算有限，只能先测几个点，应该怎么选？

先从访问量或业务价值最高的三个城市开始，每个城市分别测试电信、联通、移动；然后增加一个距离核心市场较远的代表点，例如西北、东北或西南城市，用来观察跨区域调度和尾部表现。

如果连真实用户主要来自哪里都还不清楚，先整理最近30天的日志，再去做CDN厂商对比或使用CDN选型建议。这一步通常比多跑几十次没有方向的测速，更接近一个可靠的选择。