出海网站怎么选CDN？先按用户国家安排测速

出海网站选CDN时，很多团队会先打开服务商的全球节点地图：北美有多少节点，欧洲覆盖多少城市，亚太是不是也亮了一大片。

这张地图适合了解大致覆盖，却不能直接回答一个更重要的问题：你的用户访问起来到底快不快。

同样叫“东南亚用户”，新加坡、印度尼西亚、菲律宾和越南的网络环境并不一样；同样在美国，东西海岸的距离、运营商和回源路径也可能有明显差异。一个CDN在东京表现很好，不代表日本所有移动用户都稳定；法兰克福节点很多，也不等于整个欧洲体验都好。

所以，出海网站选择CDN的第一步，不是比较谁的全球平均延迟最低，而是先把自己的用户国家列出来，再按国家安排测速。

为什么“全球平均速度”容易把选型带偏

假设一个网站的用户分布是：美国40%、日本25%、德国15%、印度尼西亚10%，其他国家合计10%。

某个CDN可能在大量低成本测试节点上表现很好，全球平均值很漂亮，但在美国西海岸或日本移动网络上不稳定。另一个CDN的全球平均值稍高，却在前四个核心国家拥有更稳定的P95和更低的失败率。

对于这个网站，后者通常更有业务价值。

平均值还有一个问题：它会把慢请求藏起来。九次请求都在300毫秒内完成，一次请求花了5秒，算出的平均值可能仍然看得过去，但那一次5秒就是一位真实用户的体验。

出海CDN测试至少应该同时看：

• 成功率和HTTP状态码；

• P50、P75或P95耗时；

• DNS、TCP、TLS、TTFB和下载时间；

• 缓存HIT与MISS的差异；

• 不同国家、城市和网络的离散程度；

• 当地访问高峰时段是否恶化。

Google在Web Vitals说明中也强调，实验室测试不能替代真实用户数据，因为设备能力、网络条件和用户行为都会改变最终体验。

CDN主动测速适合比较网络与交付链路，RUM则更接近用户真实打开页面时的感受，两者应该相互补充。

第一步：先从业务数据里找出真正重要的国家

不要凭团队印象决定测试国家。先从最近30至90天的数据中整理：

• 各国家的访问用户数和会话数；

• 注册、询盘、购买或订阅转化；

• 收入和客单价；

• 主要页面、静态资源和API请求量；

• 各国家的错误率与性能投诉；

• 接下来计划投放或重点进入的市场。

如果网站还没有正式流量，可以使用市场计划、广告投放区域、客户名单和预注册数据，先建立一份目标国家清单，但要把它标记为“预估”，上线后再用真实数据修正。

不要只按访问量排序

某个国家只占5%的流量，却贡献了30%的收入，它在CDN选型中的权重不应该只有5%。

反过来，某地存在大量无转化爬虫流量，也不应因为请求数很高就自动成为最高优先级。

可以把国家分成三类：

一个实用做法，是先覆盖能够代表80%至90%真实用户或业务价值的国家，再加入未来半年准备重点投入的市场。

这个比例不是固定标准，目的是避免为了追求“全球覆盖”而把测试资源平均分给几十个并不重要的国家。

第二步：一个国家不能只安排一个测试点

国家只是第一层，国家内部还要考虑城市、运营商和接入方式。

美国用户可能分布在纽约、弗吉尼亚、芝加哥、达拉斯、洛杉矶和西雅图；印度用户可能集中在孟买、德里、班加罗尔；日本用户则可能主要来自东京、大阪及不同固定和移动网络。

如果只在首都或云数据中心测试，得到的往往是“机房到机房”的理想结果，不一定代表家庭宽带和移动用户。

每个核心国家至少考虑三种维度

城市或区域：覆盖用户集中的主要城市，并兼顾与源站距离不同的区域。

网络类型：至少区分当地主要固定宽带和移动网络。如果业务主要在App或移动网页中使用，移动网络权重应该更高。

测试环境：数据中心探针适合稳定重复测试，住宅网络和移动网络更接近真实用户。条件允许时应组合使用。

可以按下面的方式建立测试矩阵：

表中的城市只是规划示例，不能代替你自己的用户数据。真正应该测试哪些地点，要以访问日志、RUM、订单和市场计划为准。

第三步：测试真实业务URL，不要只Ping域名

Ping测的是ICMP往返时间。它可以帮助发现基础网络延迟或丢包线索，却不能完整反映DNS解析、HTTPS握手、缓存、回源和文件下载。

有些CDN节点会限制或降低ICMP响应优先级，但HTTP服务仍然正常；也有可能Ping很快，网页却因为TTFB高、资源太大或缓存未命中而加载缓慢。

出海CDN选型建议准备四类测试对象。

代表真实入口的HTML页面

选择用户最常访问的落地页、商品页或内容详情页。它可以反映DNS、连接、TLS、HTML TTFB和重定向情况。

如果页面包含登录状态或个性化内容，不要为了测试而强制缓存。这里要观察的是实际交付链路，而不是人为制造一个好看的HIT。

一份稳定的静态小文件

例如压缩后的Logo、CSS或小型JavaScript文件。它适合检查节点调度、缓存状态和小对象访问延迟。

一份具有代表性的中等文件

可以选择真实业务中常见的产品图片、脚本包或下载对象，用于观察吞吐量和下载耗时。

不要专门创建一个业务中从来不会出现的超大测试文件，然后用它替代所有结论。

一条需要回源的动态请求

对于SaaS、API、电商和登录型业务，只测静态文件远远不够。

应选择一条无敏感数据、可重复访问的动态接口，观察CDN到源站的回源链路、连接复用和源站响应时间。

这样可以避免选出一个“静态图片很快，核心API却很慢”的CDN。

第四步：冷缓存和热缓存必须分开测

同一个URL第一次请求可能需要回源，后续请求则由边缘节点返回。把两种结果混在一起计算，会让厂商对比失去意义。

测试时至少标记：

• MISS：当前节点没有可用缓存，需要回源；

• HIT：当前节点直接返回缓存；

• Age：缓存对象在节点上已存在的时间；

• 回源后TTFB与命中后TTFB；

• 两次请求是否连接到同一个响应IP。

可以连续请求同一个公开静态文件查看响应头：

curl -sS -D - -o /dev/null \
  -w 'remote_ip=%{remote_ip}\ndns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nttfb=%{time_starttransfer}\ntotal=%{time_total}\n' \
  'https://static.example.com/assets/test.jpg'

重复执行时保持URL和请求头一致。不要每次增加随机参数，否则可能生成新的缓存键，让每次请求都像第一次访问。

不同CDN使用的缓存响应头并不统一，具体判断方法可以参考《CDN缓存命中怎么看？HIT、MISS和Age怎么理解》。

进行候选厂商对比时，还要保证缓存条件公平：要么都测试冷缓存，要么都完成预热后再测热缓存。不能拿A厂商的HIT结果去对比B厂商刚接入时的MISS结果。

第五步：按当地时间安排测速，而不是只按北京时间

很多出海网站的测速都在中国团队上班时间完成。对于美国用户，这可能是凌晨；对于欧洲用户，可能还没进入晚间高峰。

如果网络拥塞和运营商互联问题只在当地晚高峰出现，白天的一轮测试很容易把它漏掉。

每个核心国家建议覆盖：

• 当地工作日上午或下午；

• 当地晚间访问高峰；

• 工作日与周末；

• 业务活动、直播、发售或广告投放时段；

• 至少数天的连续采样。

不需要每分钟都测，但要保证不同候选CDN使用相同的时间窗口和测试频率。一次最快成绩适合证明“曾经很快”，不能证明长期稳定。

如果网站本身存在“有时快、有时慢”的问题，可以继续参考《网站有时快有时慢，CDN测速应该怎么测》，把时段、运营商、响应IP和缓存状态一起保留下来。

第六步：优先看成功率和P95，再看平均值

出海网站常见的测速指标包括：

先看成功率，是因为“快但经常打不开”没有业务价值。随后看P95，可以发现平均值掩盖的长尾请求。P50则适合观察大多数用户的典型表现。

Google对Core Web Vitals的评估也使用分位数思路，并建议以第75百分位观察多数用户体验；同时明确指出真实用户数据能反映设备和网络条件的差异。查看Google Web Vitals说明

这并不意味着CDN测速必须照搬LCP或INP指标，而是说明一个共同原则：不能只用平均值代表所有用户。

第七步：建立按国家加权的比较表

假设三个候选CDN分别是A、B、C，可以先在每个国家独立评分，再按照业务权重汇总。

国家权重可以来自：

• 真实用户占比；

• 收入或转化贡献；

• 未来市场投入；

• 故障带来的业务影响。

一个简单的计算方式是：

总评分 = Σ（国家评分 × 国家权重）

例如：

美国权重 40%
日本权重 25%
德国权重 15%
印度尼西亚权重 10%
其他目标市场权重 10%

国家内部也可以继续按城市和网络加权。移动端占日本业务流量的70%，就不应该让数据中心探针和固定宽带结果各占一半。

每个国家怎么评分

可以根据业务性质设置不同权重。以下只是一个供团队讨论的示例：

电商可以提高成功率与动态请求权重；视频和下载业务可以提高吞吐、Range请求和流量成本权重；纯文档站则可以更关注缓存命中与静态文件速度。

不同指标单位不同，不能直接把毫秒、百分比和价格相加。应先在候选厂商之间进行标准化或分档，再按权重计算。

第八步：别忘了CDN以外的三项成本

回源距离和源站架构

CDN节点离用户很近，但节点MISS后仍要访问源站。

源站只部署在中国香港，而用户集中在巴西、德国和美国时，首次请求和动态API仍可能跨越很长距离。

如果动态业务比例高，应考虑区域源站、对象存储复制、分层缓存或源站加速，而不是单纯增加边缘节点数量。

按地区计费与回源费用

CDN流量单价可能因地区不同，源站云厂商还可能收取公网出口、跨区域传输、日志和请求费用。

同一家CDN在北美便宜，不代表在南美、印度或大洋洲也便宜。选型时应把各国家预计流量代入官方价格，而不是拿一个“最低单价”乘以全球总流量。

价格和套餐变化较快，正式决策应以候选厂商当期官方报价、合同和账单模拟为准。

合规、内容和数据边界

CDN可能处理IP地址、请求头、Cookie、日志以及安全事件数据。不同国家和行业对数据处理、跨境传输、日志保存和内容分发可能有不同要求。

这部分不能仅凭节点地图判断。应让法务、安全和合规人员核对厂商合同、数据处理条款、日志区域、证书与密钥管理方式，以及业务所适用的当地要求。

第九步：主动测速之后，还要用真实用户数据复核

主动探针的优势是条件可控：不同CDN可以在相同地点、相同URL和相同时段重复比较。

但探针无法完全代表用户的手机性能、家庭Wi-Fi、浏览器缓存和页面交互。

上线后应继续按国家收集RUM数据，至少包括：

• 页面或资源URL；

• 国家和区域；

• 网络类型；

• DNS、连接、TTFB和页面加载指标；

• 设备与浏览器类别；

• HTTP状态与错误类型；

• CDN或响应节点标识；

• 采样时间。

Google的Chrome用户体验报告会汇总符合条件的真实Chrome用户体验，但低流量页面或国家可能因为样本不足无法单独出现。

Google的CrUX方法说明也指出，国家级细分如果达不到样本要求，可能不会单独提供。因此，中小型出海网站最好建立自己的RUM，不要完全依赖公共数据集。

主动测速负责在上线前筛选和持续巡检，RUM负责验证真实用户是否确实变快。这两类数据方向一致时，选型结论才更可靠。

怎么用CDNChart安排一轮国家测速

可以先在CDNChart网站测速输入真实业务域名或具体资源URL，查看当前可用的中国及海外监测位置、响应IP、状态码和各阶段耗时。

使用结果时注意三点：

1. 只把平台当前实际提供的监测国家和节点纳入结论，不要把没有探针覆盖的国家推测成“表现相同”；
   

2. 同一个国家有多个节点时，分别看结果分布，不要只保留最快值；

3. 发现不同地区连接到不同网络或厂商时，可以再用CDNChart CDN检测核对CNAME、响应IP、ASN和响应头线索。

如果平台暂时没有目标国家探针，可以用邻近地区结果作为线索，但不能把它替代目标国家的正式验收。

此时应补充当地云主机探针、住宅网络测试、真实用户监控或供应商提供的试用环境。

CDN测速与完整网页测试的边界，可以继续参考《CDN测速和网站测速有什么区别？分别能测出什么》。

如果不同国家的最佳CDN不一样怎么办

这其实很常见。

一个CDN可能在北美和欧洲表现好，另一个在东南亚更稳定，还有一家在特定国家的成本明显更低。

可以先判断差异是否大到值得增加架构复杂度。如果只是几十毫秒差距，而多CDN会增加DNS调度、缓存一致性、日志汇总、证书、刷新和故障排查成本，单一CDN可能更合理。

如果核心市场之间存在持续、显著的成功率或P95差异，可以考虑：

• 按业务子域使用不同CDN；

• 按地区进行DNS或流量调度；

• 主备CDN故障切换；

• 重要市场使用多CDN，长尾地区保持单一方案。

多CDN不是“多接一家就更快”。判断解析结果和多家厂商并存方式，可以参考《一个网站能用多个CDN吗？多家检测结果怎么看》。

常见问题

出海网站选CDN，先看节点数量还是测速结果？

节点数量适合初筛，真实国家测速更适合决策。

节点多不代表目标国家的调度、运营商互联和高峰期表现一定更好。至少要用自己的域名、业务URL和目标用户网络验证。

每个国家测一个首都节点够不够？

通常不够。

核心国家应覆盖主要用户城市、固定宽带与移动网络，面积较大的国家还要考虑东西部或南北区域差异。长尾市场可以先用区域代表点观察。

测速应该持续多久？

一次测试只能看到当时状态。

正式选型最好连续覆盖数天，并包含目标国家的工作日、周末和当地晚高峰。业务有促销、发售或直播时，还应在类似负载下验证。

海外服务器离用户已经很近，还需要CDN吗？

要看用户是否集中、内容是否可缓存以及对安全和可用性的要求。

用户只集中在源站所在城市、流量很小且动态请求为主时，CDN收益可能有限；用户跨国家分布、静态资源较多或需要隐藏和保护源站时，CDN仍可能有明显价值。

为什么静态文件很快，登录和API还是慢？

静态文件命中边缘缓存后可以直接返回，登录和API通常需要回源处理。

应继续检查CDN到源站的链路、源站区域、数据库与应用耗时，而不是只增加缓存时间。

能不能直接选择全球平均延迟最低的CDN？

不建议。

全球平均值没有体现你的用户国家权重，也容易掩盖区域失败和P95长尾。更合理的做法，是先在每个目标国家比较成功率和分位数，再按用户、收入和战略价值加权。

什么时候值得使用多CDN？

当不同核心国家长期由不同厂商占优，或者业务必须具备厂商级故障切换能力时，多CDN才更有价值。

如果性能差距很小、团队运维能力有限，增加一家CDN可能带来的复杂度会超过收益。

真正适合出海网站的CDN，不一定在所有国家都排名第一，但应该在最重要的用户国家里稳定、可解释、成本可控。先让国家名单来自真实业务，再让测速结果决定选型，通常比从一张全球节点地图开始更接近正确答案。