Cloudflare 缓存与源站：更新后前台仍是旧页怎么核对（2026）
摘要：独立站或文章更新之后，前台还是旧标题、旧正文时，先分清是浏览器缓存、源站（含 WordPress / Nginx）还没更新，还是 Cloudflare 边缘仍在命中旧副本。依据 Cloudflare 官方文档，核对 CF-Cache-Status、Age、CF-Ray、Cache-Control，以及 Development Mode、按 URL / 前缀 / Everything 刷新和带 Cookie 的缓存规则。查询日期 2026-11-13。只放官网普通链接（affiliate_later）。
依据：Cloudflare 文档 Cache responses、Default cache behavior、Purge cache、Purge by single-file、Purge cache by prefix、Development Mode、Edge and Browser Cache TTL、Bypass Cache on Cookie、Cache Rules settings、HTTP headers。查询日期：2026-11-13（北京时间）。只放官网普通链接（
affiliate_later: 1）。字段名、刷新方式和计划额度以你打开时的官方文档为准。不编未写明的按钮路径和 TTL，也不构成运维承诺。
你刚在 WordPress 里改了标题、更新了文章，打开前台却还是旧内容。页面能打开，不是 404 或 502。站点打不开、证书报错或回源校验失败，分别见 网站 404 / 502 排查清单 和 CDN 回源 HOST / HTTPS / SNI 怎么核对，本文不重写那两层。这里只解决一件事：前台能打开，但内容是旧的。要先分清是浏览器自己留着旧文件，还是源站（WordPress 或 Nginx）没把新 HTML 吐出来，还是 Cloudflare 边缘仍在命中旧副本。
Cloudflare 接入和 SSL 怎么接，见 Cloudflare 免费 CDN 与 SSL 接入。缓存键、状态码和「刷新 / 预热」入门（含阿里云、腾讯云口径）见 CDN 回源与缓存规则入门。本文只按 Cloudflare 官方文档，把「更新后仍是旧页」这一步核对清楚。
1. 先分清三层：浏览器、源站、Cloudflare 边缘
建议按这个顺序看，每层只回答一个问题。
第一层：是不是浏览器还拿着旧文件？ 用无痕窗口、另一个浏览器，或在本机用 curl -sI "https://你的域名/那篇文章的路径/" 再请求一次。若无痕或 curl 已经是新标题，而日常用的那个浏览器仍是旧页，问题在浏览器缓存。Cloudflare 文档 Edge and Browser Cache TTL 写明：刷新 Cloudflare 缓存，不会清掉访客浏览器里已经存下的资源。 浏览器能把旧页面或旧的 CSS、JS 留多久，取决于响应里的 Cache-Control / Expires，以及你是否在 Cloudflare 里设置了 Browser Cache TTL（文档还写了：若设成 Respect Existing Headers，且没有另写缓存规则，Cloudflare 不会改写或插入这些头）。所以这一层要先排除，再去动边缘刷新。
第二层：请求有没有经过 Cloudflare，边缘有没有命中缓存？ 看响应头里的 CF-Cache-Status、Age、CF-Ray 和 Cache-Control。出现 CF-Ray，说明这次请求走过 Cloudflare 网络。CF-Cache-Status 才是边缘有没有用缓存副本的直接标记，下一节分开读。
第三层：源站自己是不是还在吐旧页？ 若 CF-Cache-Status 已经是 MISS、EXPIRED、DYNAMIC 或 BYPASS，而 HTML 标题和正文仍旧，边缘这一跳并没有在用旧缓存，旧内容是源站给的。常见情况包括：WordPress 里其实还没点发布或还在草稿；源站前面还有 Nginx 的 proxy_cache / FastCGI 缓存；或页面缓存插件仍在吐旧 HTML。插件和整站提速怎么设置，见 WordPress 网站提速：缓存插件、图片压缩与 CDN，本文不重写设置步骤。若你有一个未经过 Cloudflare 代理的源站主机名，用同一路径对比 HTML，两边都是旧的，就先查源站，不要先做整站 Purge Everything。
还有一个很容易误判的前提。Cloudflare Default cache behavior 写明：默认按文件扩展名缓存，默认不缓存 HTML 或 JSON。独立站文章页多半是 HTML。若你没有用 Cache Rules 把这类请求设成 Eligible for cache（或旧版 Page Rules 的 Cache Everything），文章页本身常常会返回 DYNAMIC，边缘本来就不存这份 HTML。这时前台仍是旧页，更应去核源站或浏览器，而不是先怀疑「Cloudflare 把文章缓存住了」。静态的 CSS、JS、图片则可能仍是 HIT，改完样式却看起来没变化时，要单独看这些资源的头。
被大流量打满时的止血开关，见 网站被 CC/DDoS 时先止血，和「能打开但是内容旧」不是同一类问题。
2. 读响应头：CF-Cache-Status、Age、CF-Ray
在浏览器开发者工具的网络面板里点开该文档请求，或用：
curl -sI "https://www.example.com/your-post/"重点看这几个字段。含义以 Cache responses 和 HTTP headers 为准。
CF-Cache-Status 常见取值（官方页面上的定义，摘要如下）：
| 值 | 官方含义（摘要） | 更新后仍是旧页时怎么用 |
|---|---|---|
HIT | 资源在 Cloudflare 缓存里找到了 | 边缘仍在用已缓存的副本。看 Age（秒）。要立刻换成新内容，按下一节做刷新，刷新后再请求，确认它不再是 HIT |
MISS | 请求有资格被缓存，但当时缓存里没有，已回源 | 这次已经从源站取。若内容仍旧，查源站 |
EXPIRED | 缓存里有过期副本，本次从源站重新取 | 单文件刷新后通常是 MISS；按前缀刷新且开了 Tiered Cache 时，文档写明后续请求也可能是 EXPIRED |
STALE | 已过期但仍从缓存提供，因为当时联系不上源站 | 边缘在源站不可达时用了旧副本。先看源站是否可访问 |
REVALIDATED | 源站通过条件请求确认缓存未改，仍从缓存提供 | 源站认为这份还有效。若你确信已经改过，查源站是否真的更新，以及是否返回了 304 |
UPDATING | 已过期，但在后台向源站更新时仍从缓存提供（常见于 stale-while-revalidate） | 短窗口内仍可能看到旧副本，稍后再看一次状态 |
BYPASS | 请求当时有资格进缓存，但源站响应最终不可缓存 | 例如源站带了 Cache-Control: no-store / private，或返回了 Set-Cookie 等（详见官方 BYPASS 列表）。边缘没存，旧内容来自源站响应 |
DYNAMIC | 请求当时就被判定为没有缓存资格，没有做缓存查找，直接回源 | 常见于默认不缓存的 HTML，或匹配了 Bypass cache 的规则，或开了 Development Mode。旧内容同样先查源站或浏览器 |
NONE / UNKNOWN | 响应不是从缓存来的，例如 Worker 在缓存前生成了响应，或重定向、WAF 在到达缓存前就结束了请求 | 先分清这次返回的是不是你要看的那篇 HTML |
Age 表示这份资源进入 Cloudflare 缓存、或上次向源站再验证之后，已经过了多少秒；在向源站再验证、刷新或被逐出时会重置。文档写明：Cloudflare 会在 HIT、STALE、UPDATING 上设置 Age；在 MISS，以及向源站再验证时的 EXPIRED / REVALIDATED，还有 DYNAMIC、BYPASS、NONE/UNKNOWN 上，不会由 Cloudflare 设置 Age。若源站自己在不可缓存的响应上带了 Age，这个值会原样转给客户端，这时 DYNAMIC 或 BYPASS 里看到的 Age 不是边缘缓存的年龄。开了 Tiered Cache 时，本地的一次 HIT 也可能带上来自上层节点的 Age，数值可能比「刚刚在本地写入」更老。
CF-Ray（文档里也写作 Cf-Ray）是一次请求的标识，末尾通常带数据中心三字母代码。查缓存问题时把它记下来；官方在排查未缓存响应时也要求提供 cf-ray，以便在网络里追踪这次请求。
3. 刷新缓存：单 URL、前缀和 Everything
确认是边缘 HIT 之后，再刷新。Cloudflare Purge cache 把 按单个 URL 刷新（purge by single-file / purge by URL）列为推荐方式。同一页还列出了 Purge everything、按 cache-tags、按 hostname、按 prefix（URL）等选项。
文档里的操作入口是：在 Cloudflare 控制台进入 Configuration 页面，在 Purge Cache 下选择 Custom Purge，再选 Purge by 的类型。按单个 URL 时，主机名部分大小写不敏感，路径部分大小写敏感；要写完整 URL，例如 https://www.example.com/your-post/。单文件刷新后，后续请求的 CF-Cache-Status 应为 MISS。
需要清掉某一目录下的多份资源时，用 Purge cache by prefix。官方示例是：对 https://www.example.com/foo/bar/baz/qux.jpg，有效前缀包括 www.example.com、www.example.com/foo、www.example.com/foo/bar、www.example.com/foo/bar/baz 以及该文件本身的完整路径。独立站更新了一栏目的多篇文章，可以对应该栏目路径写前缀，例如 www.example.com/blog 或再往下一层的 www.example.com/blog/2026。前缀写法不要带协议、查询串或片段；文档还写明：刷新 foo.com/bar 时，以它开头的资源都会被清掉，包括带查询串的地址，但把查询串写进前缀本身不会生效。
Purge Everything 会清掉该 zone 里已缓存的全部内容。文档和常识都指向：先对出问题的那几个 URL 做单文件刷新，整站 Everything 放在最后。
刷新是否生效，不要只看接口或按钮返回成功。官方写明：刷新请求返回 HTTP 200，只表示 Cloudflare 已经收到请求，不表示目标内容一定曾被缓存、也不表示一定已被逐出。核对方法是：刷新后再请求该资源，确认 CF-Cache-Status 不再是 HIT。
计划额度以 Purge cache 的表格为准（查询当天）：按 hostname / tag / prefix / Everything，Free 为每分钟 5 次请求，令牌桶容量 25，每次最多 100 个操作；Pro 为每秒 5 次。单文件刷新另有按 URL 条数计算的额度。短时间反复点 Everything，会先撞到这些上限。若 Cache Rules 用了包含请求头或 Cookie 的自定义缓存键，控制台里的单 URL 刷新可能清不掉，文档要求改走 API 并带上这些键，或改用前缀、Tag、Everything。本文不展开 API 请求体。
4. Development Mode 与带 Cookie 的缓存规则
Development Mode 会暂时关闭边缘缓存和 Polish，默认持续三小时（也可提前关掉）。官方写明：它让你可以立刻看到对图片、CSS、JavaScript 等可缓存内容的修改。入口同样在 Configuration 页面，把 Development Mode 拨到 On。
两件必须分开的事：
- Development Mode 只是暂时绕过缓存，并不会清除已经缓存的文件。 要立刻清掉边缘副本，仍要走上一节的 Purge。三小时结束或你提前关掉之后，原来那些缓存还在，前台可能再次回到旧页。
- 需要超过三小时的绕过时，文档指向用 Cache Rules 的 Bypass cache，而不是一直开着 Development Mode。
登录后的编辑预览、带会话 Cookie 的后台请求，常常不应该走同一份匿名缓存。官方示例 Bypass Cache on Cookie 的写法是：当主机名包含 example.com，并且 Cookie 包含指定名字（示例里是 test-cookie）时，把 Cache eligibility 设为 Bypass cache。表达式示例为 (http.host contains "example.com" and http.cookie contains "test-cookie")。Cache Rules 文档还写明：匹配 Bypass cache 的规则时，响应头上看到的往往是 DYNAMIC，因为请求在查找缓存之前就已经被判定为没有缓存资格。
源站若在可缓存的响应里带了 Set-Cookie，是否进入缓存、会不会变成 BYPASS，取决于当时的 Origin Cache Control 和是否设置了 Eligible for cache / Edge TTL，细节见 cache behavior 里「Set-Cookie」一节。不要在没核对这些头之前，就把「登录后看到新页、未登录仍是旧页」一律当成源站没更新。
5. 核对时可以挨项看的几件事
- 无痕窗口或
curl -sI看到的是不是已经是新标题、新正文。若只有日常浏览器是旧的，先对浏览器缓存，记住刷新 Cloudflare 不会清掉访客浏览器里的文件。 - 响应里有没有
CF-Ray。有则请求经过了 Cloudflare。 CF-Cache-Status是HIT还是DYNAMIC/MISS/BYPASS等。文章页若从未被规则设为可缓存，HTML 本身常常是DYNAMIC。- 若是
HIT，记下Age，对出问题的 URL 做 Custom Purge（先按单个 URL；需要清目录时按官方前缀示例写路径；Everything 放最后），再请求一次，确认不再是HIT。 - 刷新接口或按钮返回 200 之后，仍要看新的响应头，不要把它当成「一定已经逐出」。
- 若状态已是回源类（
MISS、DYNAMIC、BYPASS等）而 HTML 仍旧，去核 WordPress 是否已发布、源站 Nginx 或页面缓存插件是否还在吐旧副本。 - 开过 Development Mode 的，记住它不清除已有缓存；关掉之后若旧页回来，再按第 4 步刷新。
- 登录态和匿名访问看到的不一样时，核对自己是否写了 Bypass cache on cookie，以及源站是否带了
Set-Cookie。
风险与范围
本文只整理 Cloudflare 官方文档在查询当天写明的响应头、刷新方式和规则字段，方便你在「页面能打开但内容是旧的」时分层核对。它不能代替对 WordPress、Nginx 和页面缓存插件的具体配置检查，也不能保证某一次刷新在所有数据中心立刻可见。阿里云、腾讯云 CDN 的刷新和预热口径不同，见 缓存键与刷新预热，不要把 Cloudflare 的 CF-Cache-Status 直接套过去。计划额度、控制台文案可能随产品改版变化，以你账号和文档当时显示的为准。只放官网普通链接（affiliate_later: 1）。
官方来源（查询日期 2026-11-13，北京时间）
- Cloudflare cache responses
- Default cache behavior
- Purge cache
- Purge by single-file
- Purge cache by prefix (URL)
- Development Mode
- Edge and Browser Cache TTL
- Bypass Cache on Cookie
- Cache Rules settings
- Cloudflare HTTP headers
- Head Requests and Set-Cookie Headers
