主动探测与真实用户监控哪个好？CDN性能评估方法

评估CDN时，经常会遇到两组相互矛盾的数据：测速平台显示大部分节点响应很快，真实用户却不断反馈页面打开慢；或者真实用户监控看起来一切正常，主动探测却连续发现某个国家或运营商访问失败。

这并不一定是谁测错了。主动探测和真实用户监控观察的是两个不同的问题：

• 主动探测回答的是：在设定好的地区、网络和测试条件下，这个URL能否稳定、快速地访问？

• 真实用户监控回答的是：实际访问网站的用户，在真实设备、浏览器和网络环境下获得了什么体验？

如果正在进行CDN初筛、上线前验证、跨地区对比或故障告警，主动探测更合适；如果需要了解核心用户的真实体验、定位受影响人群和衡量业务改善，真实用户监控更有价值。

完整的CDN性能评估通常不是二选一，而是先用主动探测建立可比较的基线，再用真实用户监控验证实际效果。

主动探测与真实用户监控到底有什么区别？

主动探测也叫合成监控、拨测或Synthetic Monitoring。它由预先部署的测试节点，按照固定时间、固定URL和固定测试规则发起请求。即使网站还没有真实流量，也可以持续获得结果。

真实用户监控通常简称RUM，即Real User Monitoring。它通过网页中的监控脚本、浏览器性能接口或者客户端SDK，采集真实访问过程中产生的性能数据。

Google在关于实验室数据与现场数据差异的说明中，将受控环境中的测试称为实验室数据，将真实用户、设备和网络条件下收集的数据称为现场数据。前者强调一致性和可复现性，后者反映实际用户体验。

哪些CDN评估任务更适合主动探测？

主动探测最大的价值不是“模拟得和每个用户完全一样”，而是让不同测试对象处于尽量一致的条件下。

CDN选型和厂商横向比较

如果要比较两家CDN，必须尽量控制变量。例如使用相同大小的文件、相同测试时间、相同地区和运营商节点，分别观察：

• HTTP状态码和请求成功率

• DNS解析时间

• TCP连接时间

• 下载耗时和总耗时

• 响应IP及其变化

• P50、P95等延迟分位值

• 不同地区和运营商的失败节点

• 中等或大文件的实际吞吐量

如果一家厂商在北京电信测试，另一家在广州移动测试，两组平均时间没有直接可比性。完整的CDN性能比较指标还应区分延迟、可用性、吞吐量以及区域覆盖，不能只比较一次测试中的最低耗时。

上线前验证和CDN迁移

新CDN尚未承接真实流量时，RUM没有足够数据。主动探测可以提前检查：

• 域名能否正常解析

• HTTPS请求是否成功

• 不同地区是否返回预期节点

• 是否出现301、302重定向异常

• 是否存在403、502、503或超时

• 中国大陆三网与海外地区表现是否符合预期

迁移完成后，还可以使用同一组URL和测试节点重复检测，减少测试条件变化带来的干扰。

发现区域性和运营商故障

用户只说“网站打不开”时，很难判断问题来自本地网络、DNS、CDN还是源站。多地区主动探测可以迅速判断故障范围：是所有地区失败，还是只有某个国家、某个运营商或少数节点异常。

Google Cloud对合成监控的说明也强调，这类监控会定期发起模拟请求，并记录可用性、延迟和请求结果，适合持续检查页面、API及关键业务流程。

在CDNChart的网站测速工具中，可以输入域名或URL，从不同地区和运营商节点观察HTTP状态码、响应IP、IP位置、解析时间、连接时间、下载耗时、总耗时、重定向和失败节点。这类结果适合用于发现区域差异，也能为后续排查提供明确方向。

真实用户监控更适合回答哪些问题？

主动探测可以告诉你“测试节点访问正常”，但不能据此推断所有真实用户都快。用户可能使用低端手机、移动网络、公司代理、家庭宽带或者跨境线路，页面还可能包含大量JavaScript、图片、广告和第三方服务。

这些因素正是RUM擅长观察的部分。

哪些用户真的受到了影响？

RUM可以按照国家、地区、运营商、设备、浏览器、页面类型和网络条件拆分数据。例如，全站P75加载时间看起来正常，但进一步分组后可能发现：

• 东南亚移动网络用户明显较慢

• 某个运营商的失败率持续升高

• 低端Android设备的LCP表现较差

• 商品详情页比首页慢很多

• 未命中缓存的访问明显慢于缓存命中

• 登录用户和匿名用户的性能差异较大

这些问题很难通过少量固定节点完整还原。

页面慢是否真的由CDN造成？

用户感知到的是整个页面，而不是单独的CDN请求。页面速度还会受到源站处理、前端渲染、图片体积、JavaScript执行和第三方接口影响。

因此，RUM中的LCP或页面加载时间变差，并不能直接证明CDN出现问题。需要继续关联：

• 导航请求和静态资源的TTFB

• CDN缓存命中状态

• 响应IP和服务区域

• 页面版本与资源大小

• 前端错误和第三方请求

• 源站处理时间

• CDN访问日志和源站日志

如果静态资源响应很快，但LCP仍然很差，问题更可能在图片尺寸、渲染阻塞或客户端执行，而不是CDN传输本身。

CDN优化有没有改善业务体验？

切换节点策略、压缩资源或提高缓存命中率后，RUM可以观察真实用户的性能分布是否改变，并进一步分析错误率、跳出率或关键业务流程。

这里应比较同一用户群和同一页面类型，而不是简单比较优化前后的全站平均值。流量来源、促销活动、设备比例和地区构成都可能改变结果。

RUM数据也不是全部用户的完整记录

真实用户监控听起来很“真实”，但仍然存在采样边界。

如果监控脚本需要等页面加载后才执行，那么在脚本运行之前就放弃访问、断网或加载失败的用户，可能根本不会上报数据。这会造成幸存者偏差：数据看起来不错，是因为最差的一部分访问没有成功进入样本。

此外，RUM还会受到这些因素影响：

• 网站流量不足，分地区后样本量太少

• 广告拦截器或隐私设置阻止脚本运行

• 不同版本浏览器提供的性能字段不同

• 用户网络和设备结构不断变化

• 采样率调整导致前后数据口径不一致

• 隐私政策限制地理位置或用户标识的采集

Chrome的CrUX数据方法说明也指出，现场数据需要满足用户和站点资格条件，并不是所有浏览器、设备及访问都会进入数据集；页面或站点还需要具备足够访问量。

因此，低流量网站、新上线页面和小众国家通常不能只依赖RUM。

为什么主动探测正常，真实用户监控却很慢？

这种情况相当常见，通常说明测试节点没有覆盖真实用户遇到的全部条件。

可能原因包括：

• 主动探测使用数据中心网络，真实用户使用移动或家庭宽带

• 测试对象是缓存良好的静态文件，用户打开的是完整动态页面

• 真实页面包含大量第三方脚本和跨域请求

• 测试节点性能较高，真实用户使用低端设备

• 核心用户集中在主动探测未覆盖的地区

• 个性化内容、Cookie或登录状态导致缓存绕过

• 用户首次访问需要建立更多连接，探测请求可能复用了连接

• CDN本身正常，但源站、API或前端渲染很慢

遇到网站性能波动时，不宜只选择某一次最快或最慢的结果。网站有时快有时慢的CDN测速方法需要同时观察测试时间、节点分布、失败比例和延迟分位值。

为什么真实用户数据正常，主动探测却频繁失败？

反过来也可能发生：

• 探测节点所在地区不是网站的目标市场

• WAF或反爬策略拦截了固定频率的探测请求

• 测试URL不具备代表性

• 探测每次使用冷连接，而用户浏览器存在连接复用

• 真实用户集中访问已经预热的热门资源

• 探测请求缺少特定Cookie、Header或鉴权信息

• 部分地区实际没有流量，RUM中没有对应样本

如果主动探测在某个地区持续失败，而RUM没有该地区数据，不能直接认定故障“不影响用户”。用户也可能因为页面无法打开而没有完成监控脚本上报。此时应结合CDN日志、源站日志和DNS查询继续核对。

用浏览器查看一次导航请求的性能阶段

网站尚未部署完整RUM系统时，可以先利用浏览器Performance API查看当前访问的导航时序：

window.addEventListener("load", () => {
  const nav = performance.getEntriesByType("navigation")[0];

  const metrics = {
    dns: nav.domainLookupEnd - nav.domainLookupStart,
    connect: nav.connectEnd - nav.connectStart,
    tls: nav.secureConnectionStart > 0
      ? nav.connectEnd - nav.secureConnectionStart
      : 0,
    ttfb: nav.responseStart - nav.requestStart,
    download: nav.responseEnd - nav.responseStart,
    total: nav.loadEventEnd - nav.startTime
  };

  console.table(metrics);
});

输出单位通常为毫秒，重点观察DNS、连接、TLS、TTFB和下载阶段。某些阶段显示为0，不一定是异常，也可能是浏览器使用了DNS缓存、连接复用或预连接。

这段代码只查看当前浏览器的一次访问，不能代替完整RUM。正式采集还要处理采样、数据上报、跨域资源时序、异常值和用户隐私，不应收集与性能分析无关的个人信息。

一套更可靠的CDN评估流程

如果需要为真实业务选择或验证CDN，可以按下面的顺序组织测试。

1. 先定义用户和业务对象

明确主要国家、地区和运营商，以及网站类型。图片站、下载站、视频、API和电商页面关注的指标并不相同。

同时选择有代表性的URL：

• 
  一个小型静态文件，用于观察连接和基础延迟
  

• 
  一个常用图片或前端资源，用于观察缓存交付
  

• 
  一个中等大小文件，用于观察下载和吞吐
  

• 
  一个动态页面或API，用于观察回源链路
  

2. 用主动探测建立对照基线

从相同节点、相近时间测试不同候选CDN，记录状态码、响应IP、DNS时间、连接时间、下载时间、总耗时以及失败率。

不要只保存平均值。P50反映典型访问，P95更容易暴露长尾问题；失败节点则能揭示平均值掩盖的区域性故障。

CDNChart公开的测试方法与评分标准说明了主动探测的数据来源、覆盖条件和样本限制。主动探测覆盖的是实际参与测试的观察节点，并不等同于厂商完整节点清单；样本不足时也不应把短期结果当成长期结论。

3. 让候选CDN承接一部分真实流量

进入试用或POC阶段后，再部署RUM并进行灰度流量验证。为了减少偏差，候选组应尽量保持相似的地区、设备、页面类型和流量来源。

4. 按用户群拆分RUM结果

全站平均值往往不够。至少应观察：

• 
  国家、地区和运营商
  

• 
  桌面端与移动端
  

• 
  页面类型和资源类型
  

• 
  浏览器与设备性能
  

• 
  缓存命中与未命中
  

• 
  P50、P75、P95等分位值
  

• 
  成功请求、超时和错误请求
  

5. 用日志确认问题属于哪一层

主动探测和RUM发现异常后，需要进一步核对CDN访问日志、缓存状态、DNS记录、源站日志和前端性能。

只有多类证据指向同一个环节，才能较有把握地判断问题来自CDN。最终决策还应包含费用、合同、技术支持、安全功能和运维复杂度，不能只依靠测速结果。

常见问题

主动探测与真实用户监控，哪一种更适合CDN选型？

初步筛选和候选厂商横向比较更适合主动探测，因为测试条件可以保持一致。进入试用或POC阶段后，应使用真实用户监控确认目标用户是否真正获得改善。

小流量网站有必要部署RUM吗？

可以部署，但分地区、运营商或页面后的样本可能不足。小流量网站应以主动探测为基础，将RUM作为长期补充，而不是等待少量真实访问得出确定结论。

RUM中的TTFB可以直接代表CDN性能吗？

不能。TTFB还可能包含DNS、连接、TLS、CDN处理、缓存回源和源站响应等因素。需要结合缓存状态、响应IP、服务端日志和主动探测结果拆分判断。

主动探测节点越多，结果就一定越准确吗？

不一定。节点数量之外，还要看地区和运营商是否与真实用户匹配、节点是否健康、测试是否使用相同URL、样本是否持续稳定。大量重复或与业务无关的节点未必提高决策质量。

可以直接用CrUX代替网站自己的RUM吗？

CrUX适合了解符合条件站点的聚合用户体验，但它有覆盖范围、资格和数据粒度限制。需要分析具体页面、业务版本、CDN线路或自定义维度时，仍然需要网站自己的RUM数据。

RUM数据需要收集多长时间？

至少应覆盖完整的业务周期，避免只看几小时或单个工作日。流量波动明显的网站通常需要覆盖工作日、周末和活动时段，并确保各关键地区具有足够样本。

主动探测会不会被WAF误判为攻击？

固定频率、高并发或请求特征单一的探测可能触发限速和机器人防护。应使用合理频率，识别探测来源，并区分真实CDN故障与安全策略拦截，但不应为了测速长期关闭WAF。

两种数据发生冲突时应该相信哪一个？

先判断它们是否测试了相同地区、URL、时间和访问条件。主动探测用于确认网络与交付链路是否异常，RUM用于确认实际用户是否受影响。两者冲突通常不是选一个“相信”，而是提示需要检查用户分布、缓存状态、页面资源、WAF规则和数据采样范围。