CDN加速有没有生效？接入后这样检查

后台显示“正常”，解析也照着教程改了，可网站打开时，好像并没有快多少。

刚接完CDN，这种不踏实很常见。钱花了，设置也做了，总得知道请求到底有没有经过CDN，缓存有没有用起来。

判断CDN加速是否生效，可以沿着四步检查：域名是否正确接入、请求是否经过CDN、该缓存的资源是否命中缓存、实际访问表现有没有改善。

这四件事要分别看。网站能打开，可能仍然在直连源站；某张图片显示缓存未命中，也可能只是当前节点第一次拿这份文件。只凭其中一个现象下结论，很容易改错地方。

先找一个具体资源，从头走一遍，比反复刷新首页更容易得到答案。

检查前，准备一张公开的静态图片。

可以选网站正在使用的一张普通图片，要求很简单：无需登录、内容稳定、文件不太大，而且按照你的配置，它本来就应该被CDN缓存。

把它的完整地址记下来，例如：

https://static.example.com/images/cdn-check.jpg

这是演示地址，操作时换成你自己的真实图片URL。

先在浏览器里打开一次，确认显示的是预期图片。别拿一个不存在的地址测试，否则后面看到的可能只是404页面或错误缓存。

暂时不要选购物车、用户中心、登录接口，也不要选每次都会更换签名的下载链接。这些请求有各自的缓存要求，用它们判断“整个CDN有没有生效”，容易绕进去。

接下来就围绕同一个域名、同一张图片检查，中途先不改文件名，不添加随机参数。

先看解析：用户访问的域名，接到了正确的位置吗？

回到CDN控制台，核对你添加的加速域名和网站实际使用的域名是否一致。

比如，控制台添加的是static.example.com，网页里的图片却还在请求www.example.com/images/。即使前者配置完全正确，这张图片也不会自动改走新域名。

这种情况看起来像“CDN没效果”，实际需要先检查页面引用或资源域名配置。

采用CNAME接入的产品，可以查询加速域名的别名记录。Windows命令提示符中执行：

nslookup -type=CNAME static.example.com

macOS或安装了dig的Linux环境，可以执行：

dig static.example.com CNAME +noall +answer

把查询结果与CDN控制台分配的CNAME目标核对。应当参考你正在使用的产品说明，不能只看返回值里有没有“cdn”几个字。阿里云的CDN CNAME配置文档提供了对应的接入和验证步骤。

如果刚改完解析，部分网络仍返回旧结果，先检查权威DNS上的记录是否正确，再考虑递归DNS和本地缓存的更新时间。反复删除、重建记录，会让后面的对照更难做。

也不是所有CDN都要求你在公开查询中看到一条CNAME。使用代理或CNAME扁平化的产品时，需要按照相应接入方式确认。

以Cloudflare为例，仅把DNS托管过去，并不能证明网站请求已经经过Cloudflare代理；还要核对目标记录的代理状态。橙云代理与仅DNS状态的区别，可以查看Cloudflare官方说明。

完成这一步，你确认的是域名接入配置。接下来，还要看一次真实请求。

再看请求：访问这张图片时，有没有经过CDN？

打开CDNChart的CDN检测工具，输入图片使用的域名，而不只是网站首页域名。

例如图片地址以static.example.com开头，就先检测这个域名。结合页面给出的厂商线索与判定证据，核对它是否与你接入的服务一致。

自动检测适合作为交叉检查。遇到“疑似”、证据不足或未识别到的结果，保留这个不确定性，再查看浏览器请求和厂商记录。

浏览器里可以这样操作：打开开发者工具的“Network／网络”面板，重新请求这张图片，点击对应记录，核对完整请求网址、远程地址和响应头。确认没有跳转到另外一个域名，也没有返回错误页面。Chrome网络面板文档说明了这些字段的位置和含义。

有些CDN会在响应中提供请求标识、缓存状态或节点相关字段。把这些线索与控制台、官方字段说明结合起来看，比只盯着IP是否变化更有用。

不过，一个Server字段或一条通用的X-Cache头，单独拿出来仍不足以确认厂商。它可能来自其他代理层，也可能经过改写。需要了解不同证据怎么配合，可以参考CDN服务商检测的CNAME、响应头与网络证据说明。

如果你有该CDN的访问日志权限，还可以按请求时间、域名和图片路径，核对这次请求是否被记录。日志可能有延迟，也可能没有开启完整记录；不能因为暂时没查到一条日志，就马上认定流量没有经过CDN。

到这一步，接入配置、实际请求和厂商侧记录如果能够相互对应，就有了判断请求经过CDN的依据。

接着看缓存：同一张图片，再请求几次。

确认请求经过CDN之后，再检查这张图片是否按预期缓存。

用curl发起普通GET请求，可以直接查看响应头。下面的命令适用于macOS和Linux：

curl -sS --connect-timeout 10 --max-time 20 \
  -D - -o /dev/null \
  'https://static.example.com/images/cdn-check.jpg'

Windows命令提示符中可以使用：

curl.exe -sS --connect-timeout 10 --max-time 20 -D - -o NUL "https://static.example.com/images/cdn-check.jpg"

命令会请求资源，输出响应头，并丢弃下载的正文。-D -负责显示响应头，--max-time 20限制本次请求最多运行20秒。参数含义见curl官方文档。

如果返回301或302，先检查Location指向哪里，再用最终图片URL继续测试。如果返回403、404或5xx，先解决对应访问问题，避免把错误响应当成图片的缓存结果。

在同一网络下，间隔几秒，重复执行两三次，记录每次响应。不要为了“刷新一下”给URL不断添加时间戳，那可能改变缓存键，变成不同对象。

以Cloudflare为例，下面是两次请求可能出现的响应头示意，并非本次实测数据。

一次请求可能看到：

HTTP/2 200
content-type: image/jpeg
cf-cache-status: MISS

后续请求可能看到：

HTTP/2 200
content-type: image/jpeg
cf-cache-status: HIT
age: 12

按Cloudflare的字段定义，MISS表示本次没有在其缓存中找到对象，需要回源获取；HIT表示从其缓存中找到了资源。一次MISS并不能说明接入失败，后续也不保证必然变成HIT，仍受缓存规则和请求条件影响。

Age可以作为辅助线索，但它的来源可能涉及其他缓存层，不能单独用来确认命中了哪一家的CDN。具体状态以Cloudflare缓存响应说明为准；其他厂商应查看各自文档。

这轮检查最值得保存的，是同一资源在相近条件下的连续响应记录。某一次测试成功，只能说明这次请求；还不能代表所有地区、所有资源都已经达到预期。

一直没有命中缓存，先找原因，不要急着把全站设成缓存。

如果选定的图片连续请求仍未命中，按下面的顺序检查：

• 完整URL是否保持一致，查询参数有没有变化。

• 该路径是否匹配了预期缓存规则，有没有被更具体的规则排除。

• 响应是否包含Cache-Control: private、no-store等指令。

• 请求是否带有登录Cookie、鉴权信息，响应是否设置了Cookie。

• 是否刚刷新缓存、资源是否超过产品限制，或者测试流量到达了不同缓存节点。
  

这些因素要结合具体产品和规则优先级判断，不能用一条响应头替代全部配置检查。

如果测的是首页或接口，还要先确认它们本来是否应该缓存。例如Cloudflare默认并不缓存HTML和JSON，这类请求没有命中缓存，并不等于没有经过它的网络。查看Cloudflare默认缓存行为。

另外，no-cache不能简单理解为“绝对不存储”。它通常涉及使用缓存前的重新验证，与no-store的含义不同。MDN的HTTP缓存指南对此有详细解释。

查到这里，可能会产生一个念头：干脆所有页面都强制缓存，总该快了吧？

先别这样做。用户中心、购物车、订单和个性化接口，需要保证不同用户看到正确内容。为了让检测结果变成HIT而破坏业务正确性，得不偿失。

验收的目标是让该缓存的公共资源正常缓存，让需要实时返回或隔离的数据保持正确。

最后再问：网站究竟有没有变快？

确认CDN接入和缓存行为之后，才适合评价加速效果。

打开CDNChart网站测速，对实际业务域名发起测试，查看主要用户所在地区和运营商的响应情况。注意使用本次任务的数据；页面中的模拟预览不能作为你的网站结论。

国内访客为主，就优先看国内实际用户覆盖的网络；海外业务则查看相关地区。某个离源站很近的监测点表现很好，不代表其他访客都能得到相同体验。

比较接入前后的结果时，尽量保持测试位置、目标内容、协议和缓存条件可比，记录测试时间，并保留失败请求。测试几轮，观察变化是否持续出现，而不要只挑最快的一次。

同一个页面前后更换了图片、压缩方式或脚本，也会影响结果。这些变化应当记下来，避免把所有改善都归功于CDN，或者把其他问题都算在CDN头上。采样和数据解读可以参考CDNChart测评方法。

还有一个范围需要分清：网站测速提供的是相应HTTP请求的观测；浏览器打开完整页面，还要加载图片、执行脚本、完成渲染。页面里那张图片到底改善了多少，需要结合它自己的请求记录；用户看到的首屏有没有更快，还要看浏览器的完整加载过程。

如果没有保存接入前的测速结果，也不用为了一个“提升百分比”去猜。先确认现在的接入和缓存行为，建立可比较的记录，再评价后续优化带来的变化。

检查到哪一步，就下哪一步的结论。

接完CDN后，没有必要只拿“生效”或“没生效”两个词来概括全部情况。

更有用的记录是：这个域名已经按要求接入，这张图片的请求经过了CDN，连续请求看到了缓存命中，而某个地区的连接耗时还需要继续排查。

这样一来，下一步该改解析、调缓存，还是查访问链路，就有了方向。

如果你现在正卡在“后台正常，心里没底”这一步，就从网站里选一张公开图片开始。沿着它的域名、请求和响应查下去，留下几条能对应上的记录，比再刷新十次首页更能让人踏实。