阿里云CDN接入后怎么确认生效？域名与缓存检查步骤

阿里云CDN控制台里的域名已经显示“正常运行”，CNAME也按照提示配置了，但网站打开以后似乎没有明显变化。

这时最容易出现两种误判：一种是看到网站能正常访问，就认为CDN已经生效；另一种是第一次请求返回MISS，便认为CDN根本没起作用。

其实，“域名已经接入”“请求经过CDN”和“资源命中缓存”是三件不同的事：

所以，确认阿里云CDN是否生效，不能只做一次ping，也不能只在浏览器里打开首页。更稳妥的做法，是选一个具体的加速域名和一份应该缓存的静态文件，从DNS一路检查到HTTP缓存。

检查前，先选对测试对象

假设网站使用以下地址加载一张图片：

https://static.example.com/assets/logo.png

测试时请换成自己的真实地址。这个文件最好满足以下条件：

• 无需登录即可访问；

• 内容稳定，不会每次请求都动态生成；

• 在阿里云CDN中配置了缓存规则；

• URL中不带不断变化的时间戳、Token或随机参数；

• 能正常返回200，而不是跳转页或错误页。

首页、登录接口、购物车和用户中心通常不是理想的缓存测试对象。它们即使经过CDN，也可能按业务设计每次回源。拿动态页面测试，最后很容易得到“接入正常、缓存也按规则工作，但怎么看都是MISS”的结果。

还要确认测试域名就是控制台里添加的加速域名。控制台配置的是static.example.com，网页资源却仍从www.example.com加载，前者生效也不会自动加速后者。

第一步：先看阿里云CDN控制台里的域名状态

进入阿里云CDN控制台的“域名管理”，找到目标加速域名，先核对三项：

1. 加速域名与业务实际请求的主机名完全一致；

2. 域名处于正常运行状态，而不是配置中、已停用或审核异常；

3. 复制控制台为该域名分配的CNAME值，后面用于核对DNS结果。

这里要特别留意“域名运行状态”和“CNAME状态”的区别。

域名正常运行，说明这条加速域名可以在阿里云CDN侧提供服务；CNAME显示已配置，才说明阿里云检测到了相应的DNS指向。只完成前者，没有把公网DNS切到CNAME，真实用户仍可能直连源站。

阿里云官方的配置CNAME说明也将CNAME配置称为激活CDN服务的最后一步：DNS先把加速域名指向阿里云分配的CNAME，再由CDN调度系统返回适合的边缘节点IP。

不过，控制台状态适合快速核对，不应替代真实解析查询。尤其是使用分线路解析时，控制台的检测位置可能与你的用户所在地区不同。

阿里云文档也提示：如果只对中国内地以外区域配置CNAME，控制台可能仍显示“待配置”，但对应区域的加速服务并不一定受影响。

第二步：用nslookup或dig检查CNAME是否生效

在Windows命令提示符中执行：

nslookup -type=CNAME static.example.com

在macOS或Linux中，可以执行：

dig static.example.com CNAME +noall +answer

返回的CNAME目标应与阿里云CDN控制台分配的值一致。示意结果可能类似：

static.example.com.  600  IN  CNAME  static.example.com.w.kunlunsl.com.

这只是格式示例，实际值以你自己的控制台为准，不要手动照抄示例中的域名。

接着再查看完整解析链和最终IP：

dig static.example.com

需要排查权威DNS委派时，还可以执行：

dig static.example.com +trace

+trace适合排查权威DNS和记录是否正确，但它与普通用户通过递归DNS获得结果的过程并不完全相同。实际排障时，可以再指定几个递归DNS交叉查询：

dig @223.5.5.5 static.example.com CNAME +short
dig @1.1.1.1 static.example.com CNAME +short
dig @8.8.8.8 static.example.com CNAME +short

这里不是要强求不同DNS返回完全相同的节点IP。

CDN本来就会根据地区、运营商、网络情况和节点负载进行调度，不同位置解析到不同边缘IP很正常。真正要核对的是：CNAME链是否进入预期的阿里云CDN调度体系，而不是仍然直接返回源站记录或旧CDN记录。

刚修改CNAME，为什么有人生效、有人没生效？

DNS记录存在缓存。修改记录后，部分递归DNS和本地设备可能在原TTL到期前继续使用旧结果。

阿里云文档给出的说明是：在云解析DNS新增CNAME可实时生效；修改CNAME时，实际等待时间取决于原DNS记录的TTL，默认TTL场景可能需要约10分钟。若域名使用的不是云解析DNS，还要以当前权威DNS服务商的规则为准。

此时不要连续删除、重建同一条记录。先分别查询权威DNS和多个递归DNS，记录“谁还在返回旧值”。

如果只是本机结果陈旧，可以清理操作系统DNS缓存或换一个递归DNS再次验证；如果权威DNS本身仍是旧值，就应回到DNS服务商检查记录是否改在了正确的解析区、主机记录是否写对，以及NS委派是否指向当前使用的DNS平台。

第三步：确认真实HTTP请求经过了阿里云CDN

CNAME正确，只能证明DNS配置基本到位。还要对真实资源发起请求，看看最终连到了哪里、收到了什么响应。

先用普通GET请求保留响应头并丢弃正文：

curl -sS -D - -o /dev/null \
  --connect-timeout 10 --max-time 30 \
  'https://static.example.com/assets/logo.png'

Windows中可以使用：

curl.exe -sS -D - -o NUL --connect-timeout 10 --max-time 30 "https://static.example.com/assets/logo.png"

为什么不用curl -I作为唯一依据？

因为-I发送的是HEAD请求，某些源站、代理规则或缓存逻辑对HEAD和GET的处理不同。阿里云的缓存排障指南也建议优先使用GET验证真实缓存行为，HEAD只作为辅助。

如果还想把解析IP和各阶段耗时一起记录，可以执行：

curl -sS -D /tmp/aliyun-cdn-headers.txt -o /dev/null \
  -w 'remote_ip=%{remote_ip}\nhttp_code=%{http_code}\ndns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nttfb=%{time_starttransfer}\ntotal=%{time_total}\n' \
  'https://static.example.com/assets/logo.png'

这里的remote_ip是本次实际建立连接的IP。它应结合CNAME、IP网络归属、响应头和CDN侧记录一起看，不要因为某个IP与上一次不同就判断异常。

也可以把加速域名放进CDNChart CDN检测，查看CNAME链、响应IP、IP/ASN及HTTP响应头等公开线索。

检测结果适合做交叉验证：证据一致时，可以提高判断可信度；若显示“疑似”或未识别到，则应继续查看DNS和阿里云控制台，而不是把一次自动识别当作最终结论。

页面能打开，为什么还不能证明CDN已经生效？

因为源站本来就能提供页面。即使DNS没有切换成功，用户直连源站也可能正常看到网站。

反过来，响应头里只看到Server: nginx，也不能立刻认定没有经过CDN。源站响应头可能被透传，CDN侧字段也可能按配置被隐藏或修改。

更可靠的判断，是让以下证据相互对应：

• CNAME链进入阿里云CDN；

• 本次请求连接到预期的边缘网络，而不是已知源站IP；

• 响应中出现与阿里云CDN缓存相关的字段；

• 阿里云CDN日志或监控能查到相应域名、时间和请求；

• 源站访问日志显示该请求来自回源链路，而不是客户端直接访问。

第四步：连续请求同一静态文件，检查X-Cache

确认请求经过CDN后，再判断缓存有没有工作。

对同一个完整URL连续请求两到三次，中间不要加随机参数，也不要改请求头：

for i in 1 2 3; do
  echo "request=$i"
  curl -sS -D - -o /dev/null \
    'https://static.example.com/assets/logo.png' \
    | grep -Ei '^(HTTP/|x-cache:|age:|x-swift-cachetime:|cache-control:|expires:|vary:|set-cookie:)'
  sleep 2
done

你可能会看到类似下面的变化：

X-Cache: MISS
Age: 0
X-Swift-CacheTime: 86400

随后变为：

X-Cache: HIT
Age: 8
X-Swift-CacheTime: 86400

以上仅为便于理解的示意，字段是否出现、大小写和具体值以真实响应为准。

按阿里云官方说明：

• X-Cache为HIT，表示本次请求命中了节点缓存；

• X-Cache为MISS或字段不存在，通常表示本次未命中，需要结合其他信息确认是否回源；

• Age表示资源已在节点缓存的秒数；

• X-Swift-CacheTime表示允许缓存的总时长；

• 可用X-Swift-CacheTime - Age估算该副本的剩余缓存时间。

第一次MISS、第二次HIT，是很常见的过程：当前节点首次没有该资源，于是回源获取并缓存；下一次相同请求才从节点副本返回。

但不要把“连续两次请求”理解成任何场景都必须从MISS变HIT。若资源被设置为不缓存、响应带有禁止缓存的指令、URL参数不断变化、缓存键受请求头影响，或两次请求实际落到不同节点，结果都可能继续是MISS。

想更系统地理解这些字段，可以继续阅读《CDN缓存命中怎么看？HIT、MISS和Age怎么理解》。

一直是MISS，优先查这几个地方

测试的资源本来就不该缓存

动态API、登录页面、订单数据和个性化内容通常需要回源或按用户隔离。它们一直MISS不一定是故障。

不要为了让检测结果变成HIT，就把全站都强制缓存。否则可能造成登录态错乱、购物车串号，甚至让一位用户看到另一位用户的数据。

源站返回了不缓存指令

检查响应中的这些字段：

Cache-Control: no-store
Cache-Control: no-cache
Cache-Control: max-age=0
Pragma: no-cache

它们的含义并不完全相同。no-store通常表示不要存储响应；no-cache允许存储，但使用前需要重新验证。排查时不能简单地把两者都解释成“完全没有缓存”。

如果是公共静态资源，应优先从源站修正响应头和业务逻辑。阿里云CDN虽然提供忽略源站不缓存标头等配置，但强制覆盖前必须确认内容不包含用户相关数据。

源站对静态文件返回Set-Cookie

阿里云缓存排障文档指出，源站响应含Set-Cookie时，CDN默认可能不缓存该响应。

最稳妥的处理方式，是让图片、CSS、JavaScript、字体等公共静态资源不再由源站设置会话Cookie。

不建议直接在全站范围删除Set-Cookie。登录态、鉴权和购物车往往依赖它。若只能在CDN侧处理，也应该限定明确的静态资源路径，并在上线前验证业务影响。

URL参数让同一文件变成多个缓存对象

例如：

/assets/logo.png?t=1720000001
/assets/logo.png?t=1720000002

如果参数参与缓存键，两次请求会被当成不同对象。测试时先保持URL完全相同；生产配置则要区分参数是否真的影响内容。

统计参数可能可以忽略，图片处理参数、版本号、鉴权参数却往往必须保留。全局忽略所有参数虽然可能让命中率变高，也可能返回错误内容。

缓存规则没有匹配到目标路径

检查目标文件究竟命中了哪条缓存规则，包括规则类型、目录或后缀、优先级、缓存时间和条件规则。

更具体的路径规则可能覆盖通用规则，而一个高优先级的“缓存0秒”规则可能让所有请求持续回源。

配置已经修改，但节点仍有旧缓存

规则下发与旧缓存清理是两件事。

阿里云文档说明，配置下发到全网节点通常需要几分钟；而已经按旧策略缓存的资源不会因为规则修改自动消失。

如果需要立即验证新规则，可以按实际范围执行URL刷新或目录刷新。操作前先评估回源压力，尤其不要为了测试一个文件就刷新整个站点。具体限制和使用方式应以阿里云的刷新和预热资源文档为准。

两次请求落到了不同节点

本机网络切换、DNS重新解析、IPv4与IPv6差异，以及CDN调度变化，都可能让连续请求到达不同节点。

第一个节点已经缓存，不代表第二个节点也一定有相同副本。保存每次请求的remote_ip和响应头。如果IP发生变化，就不要只比较HIT与MISS，还要把节点变化纳入判断。

第五步：检查不同地区和运营商是否都已切换

自己电脑上的一次请求，只能代表当前网络、当前DNS和当前时刻。

网站面向全国用户时，还应检查电信、联通、移动以及主要省份的解析和访问结果。

可以使用CDNChart网站测速对实际加速域名或具体静态文件做多地区测试，重点看：

• 不同地区解析出的响应IP；

• 电信、联通、移动是否都能正常访问；

• 是否有部分节点仍连接到旧IP或其他CDN；

• 状态码、DNS耗时、连接耗时和总耗时是否存在区域性异常；

• IPv4与IPv6是否出现不一致的访问路径。

不同地区返回不同IP，本身是CDN调度的正常表现。

真正值得警惕的是：部分地区仍然明确解析到源站、旧服务商或错误地址；或者只有某个运营商集中出现403、5xx、证书错误和超时。

如果刚完成切换，建议在一个TTL周期后再测一次，并保留时间、地区、运营商、响应IP和状态码。这样可以区分DNS缓存尚未过期与持续存在的解析配置错误。

第六步：回到阿里云控制台看监控和日志

外部请求已经能提供很多证据，但站点属于自己时，还可以用阿里云侧数据复核。

在资源监控中查看目标加速域名的访问流量、请求数、回源流量、命中率和HTTP状态码。

阿里云的CDN资源监控说明中区分了字节命中率与请求命中率：前者关注由节点直接响应的字节占比，后者关注命中的请求占比，两者不一定同步变化。

例如，一个站点有大量小图片命中缓存，但少量大文件持续回源，请求命中率可能不难看，字节命中率却会偏低。只盯一个百分比，很可能误判源站压力和真实加速效果。

监控数据通常存在统计延迟，不适合拿来确认刚刚一秒钟前的单个请求。单次排障可先看curl响应与实时日志，趋势判断再看监控曲线。

接入成功但网站没有明显变快，问题可能不在“是否生效”

当CNAME、请求路径和缓存命中都正常后，网站仍然可能感觉不快。原因包括：

• HTML主文档仍需回源，TTFB受源站应用和数据库影响；

• 页面包含大量第三方脚本，这些资源不受你的CDN配置控制；

• 图片过大、JavaScript执行时间长或首屏渲染被阻塞；

• HTTPS证书链、重定向和连接复用配置不理想；

• 主要用户与源站、节点覆盖或加速区域不匹配；

• 缓存命中了，但文件本身体积没有优化。

这时应该把“CDN有没有接上”和“用户体验有没有改善”分开验证。

前者看DNS、请求路径与缓存；后者看DNS、TCP、TLS、TTFB、下载以及浏览器渲染全过程。

如果需要完整的通用检查框架，可以参考《CDN加速有没有生效？接入后这样检查》。如果已经确认接入正常，但TTFB依旧很高，可以继续看《TTFB高是什么原因？CDN和源站应该先查谁》。

一张表判断下一步查什么

常见问题

阿里云CDN控制台显示“已配置”，就一定生效了吗？

说明阿里云检测到CNAME配置，是重要证据，但仍建议用nslookup或dig查询真实DNS结果，再对一个实际URL发起HTTP请求。

分线路解析、递归DNS缓存和业务使用了另一个域名，都可能让部分用户的访问路径与控制台状态不同。

CNAME生效后，ping出来为什么还是一个IP？

应用最终必须连接到IP，所以DNS沿着CNAME链继续解析后仍会得到A或AAAA记录。

ping显示最终IP是正常的。它测的是ICMP可达性与往返时间，不能证明HTTP缓存是否命中，也不能完整代表网页加载速度。

X-Cache第一次MISS，是否说明阿里云CDN没有生效？

不一定。

当前节点第一次请求该资源时没有副本，可能需要回源获取，因此出现MISS。保持URL和请求条件一致再请求几次，如果后续出现HIT，说明节点已经建立缓存。

若始终MISS，再检查缓存规则、源站不缓存响应头、Set-Cookie、URL参数和节点是否发生变化。

为什么换一台电脑测试，又变回MISS？

另一台电脑可能使用不同运营商、不同递归DNS，或被调度到另一个边缘节点。不同节点的缓存状态彼此可能不同。

记录两边的解析结果、实际连接IP和响应头，才能判断是正常的节点差异还是配置异常。

修改缓存规则后，需要马上刷新吗？

不一定。新规则通常只影响后续形成的缓存，旧副本可等自然过期。

如果业务必须立即看到新内容，或需要立刻验证新缓存键和响应策略，再执行精确的URL刷新。范围越大，回源压力越高，不建议把全站刷新当成日常测试动作。

检查阿里云CDN是否生效，最少要保存哪些信息？

至少保存测试时间、完整URL、所在地区和运营商、CNAME链、实际连接IP、HTTP状态码、X-Cache、Age、X-Swift-CacheTime、Cache-Control以及连续两到三次请求结果。

若需要提交工单，再补充阿里云账号下的加速域名、异常地区、复现时间和相关日志。

当这些记录能够串起来时，“CDN到底有没有生效”就不再是凭感觉判断：DNS把请求交给了阿里云CDN，真实HTTP请求到达了边缘网络，应缓存的静态资源出现了HIT，多地区用户也不再访问旧路径——这才是一条完整、可复核的生效证据链。