CDN 加速效果测试：怎样做一组可信的前后对照

要判断 CDN 有没有加速，必须比较同一个问题。开启前测源站冷缓存，开启后测边缘热缓存，或者把桌面改成手机，都无法单独说明 CDN 带来的变化。可信的 CDN 加速效果测试，需要先设计对照条件。

把准备验证的收益写清楚

静态资源下载、主文档响应和首屏显示不是同一件事。你可以验证目标地区下载图片是否改善，也可以验证匿名页面的缓存响应；动态接口则应单独检查。测试前选定核心指标，并同时验证内容正确。

不要只用 Ping 比较 CDN。边缘地址的 ICMP 响应无法说明缓存命中、HTTPS 页面或源站处理。关于页面加载应观察什么，可参考从导航到首屏的时间线。

对照条件必须能够复现

• 使用相同页面或相同资源版本，保留内容与响应大小。
• 位置、网络、设备、协议和测试方法保持一致。
• 首访、回访及边缘缓存状态分别记录。
• 在相近时间安排多组对照，保留全部结果与错误。

生产环境不适合为了测速频繁切换全站 DNS 或清空全部缓存。可以使用经过批准的测试入口、灰度配置，或者在可验证的网络与证书条件下对自有源站做受控比较。路径不同是对照的一部分，也需要写进记录。

需要比较源站时，保持域名语义

直接请求 IP 可能改变 Host 和 TLS 主机名，得到的不是相同网站。curl 的 --resolve可以为指定主机与端口提供地址，同时保留 URL 中的域名语义，具体见官方手册。只对自己有权管理的源站使用，并确认防火墙和证书允许这种访问；不要关闭证书验证来制造成功结果。

若源站仅允许 CDN 回源，直接访问失败可能是正确的保护策略。此时可用服务商日志、受控测试环境等证据，不必临时开放生产源站给所有地址。

缓存状态是分组条件，不是结果装饰

同一 URL 也可能因 Cookie、参数和缓存规则进入不同缓存键。观察服务商响应头，把命中、未命中与不缓存请求分开。Cloudflare 的 HIT、MISS、DYNAMIC 等定义只是该服务的口径，不能直接套给所有 CDN。

报告可以同时保留：有效请求数、失败数、成功请求耗时范围、缓存状态和页面视觉指标。样本少时，不要把一个漂亮的百分比包装成稳定收益；若必须计算相对变化，要明确基线、指标与样本条件。

先通过正确性，再讨论速度

比较正文、资源版本、登录隔离和业务操作。缓存返回了旧内容、把用户页面错误共享，或者验证码拦住真实用户，都不能用“更快”验收。结果只改善静态下载时，就如实说明范围，不扩大为整站体验全面改善。

如果效果不明显，先看主要等待是否仍在动态回源、资源晚发现或浏览器执行。可按缓存、回源与动态请求的检测步骤继续缩小范围。