CDN刷新缓存需要多久完成？

CDN 刷新缓存多久完成，取决于问的是「刷新任务被受理」还是「所有边缘节点都换成新内容」。控制台提交刷新后，任务记录通常很快从「处理中」变成「已完成」；但边缘节点真正回源、替换旧副本的时间，需要结合刷新类型（单个 URL / 目录 / 全站）、厂商实现和当时节点状态确认。判断这件事不要靠刷新浏览器，要靠两处可核对的信息：控制台刷新记录里的任务状态，以及原始 URL 的响应头。

先分清两件事：刷新任务状态完成，和边缘节点内容更新，不是同一时刻。可核对的动作是——控制台刷新记录页看任务状态与提交时间，同时对原始 URL（不带随机参数）执行 curl -sI，看 Age、X-Cache 一类响应头，并与源站 ETag 比对。任务显示完成但内容仍旧，优先查源站是否真的更新、缓存键是否把参数排除在外，而不是反复重提刷新。厂商的额度、限速、生效范围会变，以控制台当页说明和开放 API 文档字段为准。

CDN刷新缓存需要多久完成啊怎么设置

这一步在流程里对应的是「提交刷新请求并确认它被受理」，不是「内容已经在所有节点生效」。很多人卡住，是因为把这两件事当成同一件，于是任务一提交就去刷新页面，看到旧内容就以为刷新没生效。

确认是不是卡在这一步，看三个可核对的字段。进入控制台后找 CDN 的「刷新 / 预热」入口，打开刷新记录页；各厂商叫法不同，但列表里通常会有任务 ID、提交时间、状态、刷新类型、URL 数量。字段名以你实际看到的页面为准。

提交后在记录里能不能立刻看到这条任务。看不到，说明是提交没成功或权限不足，不是速度慢。
任务状态停在处理中，说明在排队或被频率限制。限制条件在刷新页面的说明文字、控制台的「使用限制」链接、或开放 API 文档里该接口的「频率限制 / 配额」字段，位置以你账号内实际文档为准。
状态已是完成但内容仍旧，这一般不是排队问题，往下看第三节。

边缘侧的确认可以用一条命令，重点看响应头里的缓存状态和年龄字段：

curl -sI "https://static.example.com/app.js" | grep -Ei '^(age|x-cache|cf-cache-status|cache-control|etag|last-modified|via):'

缓存状态头的名字各家不同（X-Cache、CF-Cache-Status、X-Cache-Status 之类），以实际返回和厂商文档中的「响应头」章节为准，不要默认一定叫某个名字。

CDN刷新缓存需要多久完成：先把能核对的事实摆清楚

先把对象和前提写清楚，再谈快慢。对象至少有三种：单个 URL 刷新、目录或前缀刷新、全站刷新，三者的生效范围不同，不要用单个 URL 的观察去推断目录刷新。前提是源站内容已经更新，并且能从源站直接取到新版本；如果源站本身还是旧文件，刷新多少次都没意义。另外要确认缓存键的构成：是否忽略查询参数、是否按 Accept-Encoding 或 Cookie 区分，这会直接决定刷新后同一个 URL 是否命中同一份缓存。

可核对的现象只有几类，全部落在命令、日志和面板字段上：

源站直连的 ETag / Last-Modified，作为比对基准。
CDN 边缘响应的 ETag / Last-Modified 与 Age。
控制台刷新记录里的任务状态、提交时间、URL 条数。
响应头中的缓存状态字段，以及 Via 头是否表明还经过了父层或中间层。

# 1) 直连源站取值（把 IP 换成你的回源地址，域名保持业务域名）
curl -sI --resolve static.example.com:443:203.0.113.10 https://static.example.com/app.js \
  | grep -Ei '^(etag|last-modified|age|cache-control):'

# 2) 走公网 DNS 看 CDN 边缘返回
curl -sI https://static.example.com/app.js \
  | grep -Ei '^(etag|last-modified|age|x-cache|via):'

这两条命令的输出，就是后面所有判断的依据。先不下结论，先看两份 ETag 是否一致、Age 是多大。

CDN刷新缓存需要多久完成最容易搞错的一点

最常见的误解是：刷新任务提交成功，等于所有用户立刻看到新内容。实际上「任务状态完成」「边缘缓存已替换」「用户浏览器不再使用本地副本」是三件不同的事，中间任何一环没走完，看到的都还是旧文件。

判断分界可以用一个动作区分：对同一个原始 URL 连续请求两次，间隔几十秒，比较 Age 和 ETag。

for i in 1 2; do
  curl -sI https://static.example.com/app.js | grep -Ei '^(age|etag|x-cache):'
  sleep 30
done

Age 变小或消失、ETag 变成源站的新值，说明边缘已经在换新；Age 持续增长、ETag 还是旧的、控制台任务却显示完成，说明问题在缓存键、回源链路或父层缓存，这时候反复重提刷新基本没用。

还有一个配套的坑：用带随机参数的地址验证。加 ?v=时间戳 只是绕过缓存直接看到源站内容，它不能证明边缘那份旧副本已经清掉。要验证边缘缓存必须用不带随机参数的原始 URL。这两个动作经常被混为一谈，结论也就跟着错。

CDN刷新缓存需要多久完成：一个照着就能做完的做法

下面这条路径从改源站一直走到边缘抽样，每一步都写明该看到什么。

更新源站文件，用第一节的命令确认源站已经返回新的 ETag 或 Last-Modified，记下这个值。看不到新值就停下，先解决源站或回源发布。
在控制台刷新记录页提交刷新，刷新类型按实际需要选单个 URL 或目录。如果走开放 API，请求体和返回字段以厂商「刷新缓存」接口文档为准，通常是类型、URL 或路径列表，返回一个任务 ID。
回到刷新记录页，或按任务 ID 调任务查询接口，确认这条任务存在且状态在推进。
用脚本做边缘抽样，判断是否已经换成新内容：

TARGET="https://static.example.com/app.js"
ORIGIN_ETAG=$(curl -sI --resolve static.example.com:443:203.0.113.10 "$TARGET" \
  | awk -F': ' 'tolower($1)=="etag"{print $2}' | tr -d '\r')
echo "origin etag: ${ORIGIN_ETAG:-none}"

for i in $(seq 1 10); do
  HDR=$(curl -sI "$TARGET")
  EDGE_ETAG=$(printf '%s\n' "$HDR" | awk -F': ' 'tolower($1)=="etag"{print $2}' | tr -d '\r')
  AGE=$(printf '%s\n' "$HDR" | awk -F': ' 'tolower($1)=="age"{print $2}' | tr -d '\r')
  echo "[$i] age=${AGE:-none} edge_etag=${EDGE_ETAG:-none}"
  if [ -n "$ORIGIN_ETAG" ] && [ "$EDGE_ETAG" = "$ORIGIN_ETAG" ]; then
    echo "edge matched origin"
    break
  fi
  sleep 20
done

脚本里 10 次、每次间隔 20 秒，只是控制观察窗口长度，不是对完成时间的承诺；要延长就用更大的次数。正常推进时应当看到：源站 ETag 有值，边缘 ETag 在某次循环后与源站一致，Age 从小变大再回落或消失；如果跑完仍不一致，按第三节的顺序排查，不要继续加提刷新次数。

CDN刷新缓存需要多久完成：怎么验证结果对不对

验证分两侧。控制台侧看刷新记录页：任务状态为完成、完成时间有值、URL 条数与提交时一致，说明请求侧没有问题。边缘侧用不带参数的原始 URL 验证：

curl -sI https://static.example.com/app.js | grep -Ei '^(etag|last-modified|age|x-cache|via):'

正常结果长这样：ETag 或 Last-Modified 与源站一致，Age 处于回落状态，缓存状态字段显示已命中，Via 头没有暴露额外的父层缓存。再换一到两个不同网络环境或不同解析结果各请求一次，确认不是只命中了某一个节点。

需要留出的边界：个别节点在短时间内仍返回旧副本属于常见情况，通常继续观察或等 TTL 到期即可；如果长时间不变，优先核对三件事——刷新的是否是要用的那个 URL（http 与 https、带不带 www、带不带参数都算不同 URL）、缓存键是否按规则忽略了参数、是否存在父层或中间层缓存。刷新额度、并发限制和生效范围属于会变的配置，请以控制台刷新页面上的说明和开放 API 文档中对应接口的字段为准，不要照搬别处的数字。