Cloudflare缓存命中率只有30%？配置这3个规则让它飙到90%

上个月我发现自己博客的Cloudflare缓存命中率一直在30%左右晃悠，心里那个急啊。明明用了CDN，图片、CSS这些静态资源倒是缓存了，可HTML页面每次都回源，服务器还是被请求打得满满当当。后来研究了一下才知道，Cloudflare默认根本不缓存HTML！更头疼的是，之前用的Page Rules配置方式已经被标记为deprecated，眼看着就要废弃了。 花了两天时间研究Cloudflare的Cache Rules和Edge TTL配置，终于把缓存命中率从30%飙到了90%。TTFB（首字节时间）从之前的500毫秒掉到了100多毫秒，服务器负载直接降了90%。说实话，这个效果让我挺惊喜的。 这篇文章我会手把手教你配置Cloudflare缓存，从理解为什么HTML不缓存，到具体的Cache Rules配置步骤，再到如何验证效果，全都聊一遍。如果你也在为缓存命中率低头疼，这篇应该能帮到你。

为什么Cloudflare默认不缓存HTML？

Cloudflare默认缓存行为

先说说Cloudflare的默认缓存策略。默认情况下，Cloudflare只会缓存静态资源——图片（JPG、PNG、GIF）、样式文件（CSS）、脚本文件（JS）这些。HTML页面？不好意思，默认不缓存。 这是为啥呢？Cloudflare的逻辑是这样的：判断一个资源能不能缓存，主要看三个条件：

1. Cache-Control头：如果设置了private、no-store、no-cache或者max-age=0，就不缓存
2. 响应码：只有特定的HTTP状态码才会缓存（比如200、301、404等）
3. 请求方法：只缓存GET请求，POST、PUT这些就不缓存了 HTML页面通常被视为”动态内容”，可能包含用户特定的信息，所以默认不缓存。这个设计其实挺合理的——想想看，如果你的网站有用户登录功能，HTML里可能包含用户名、个人信息，这些东西可不能让CDN缓存下来给别人看。

不缓存HTML的真实原因

说白了，Cloudflare这么做是为了安全。我在社区论坛看到过一个倒霉的哥们，他直接开启了全站缓存，结果连wp-login.php登录页面都被缓存了，连带着登录账号密码统统被缓存。后果可想而知——任何访客都能通过缓存的页面直接进WordPress后台。这事儿想想就后怕。 话说回来，如果你的网站确实是静态内容为主，比如：

• 用Next.js、Gatsby等工具生成的静态博客
• 更新频率很低的企业官网、文档站点
• 纯展示型的产品介绍页面 那HTML缓存就能大幅提升性能了。关键是要正确配置，把该排除的页面（后台、登录等）排除掉。

缓存HTML能带来多大改善？

我看到有人在Medium上分享过他的数据：配置HTML缓存后，TTFB从500毫秒降到了100-160毫秒区间，服务器负载直接减少了90%。这个效果真的很夸张。 为什么会有这么大差别？很简单——以前每个访客访问你的网站，HTML都得从源服务器拿，服务器要处理请求、查数据库、渲染页面。现在呢？CDN直接把缓存的HTML扔给访客，源服务器根本不用动。访问量越大，这个差别就越明显。

Page Rules已废弃，如何用Cache Rules替代？

Page Rules的落幕

如果你之前用过Cloudflare，肯定知道Page Rules。这个功能让我们能用”Cache Everything”选项来缓存HTML。可惜的是，Page Rules现在被标记为deprecated了。 时间线是这样的：

• 2024年7月：新注册的免费账户已经不能用Page Rules了
• 2025年：Cloudflare会把现有的Page Rules自动迁移到新系统
• 以后的新配置都得用Cache Rules 为啥要废弃呢？其实也不难理解。Page Rules功能太老了，配置起来不够灵活，免费版还只能建3条规则。对于复杂的缓存策略来说，真的不够用。

Cache Rules的新世界

Cache Rules是Cloudflare新推出的缓存配置系统，功能强大得多。最大的区别在于： Page Rules时代：你需要手动选择”Cache Everything”才能缓存所有内容 Cache Rules时代：当你选择”Eligible for cache”（符合缓存条件）时，Cache Everything功能就自动启用了 这个变化挺重要的。我一开始不知道，还在傻傻地找”Cache Everything”选项在哪，后来才发现人家已经改名了。 另外，Cache Rules的匹配条件更灵活：

• 可以根据URI路径、文件扩展名、主机名等多种条件匹配
• 支持正则表达式（虽然我很少用到）
• 可以组合多个条件

迁移注意事项

如果你现在还在用Page Rules，有几个点要注意：

1. Cloudflare会帮你迁移：2025年的时候，Cloudflare会自动把你的Page Rules转成Cache Rules，不需要你手动操作（当然你也可以提前自己迁移）
2. 有些设置不会被迁移：特别是”Disable Security”和”Disable Performance”这两个设置，已经被废弃了，不会迁移过去
3. 行为略有差异：Cache Rules的”Eligible for cache”等同于Page Rules的”Cache Everything”，但实现逻辑有细微差别 说实话，我建议现在就开始用Cache Rules。反正迟早要换，早换早踏实。而且Cache Rules确实更好用，配置起来更清晰。

Cache Rules配置实战：3个规则搞定全站缓存

好了，理论聊得差不多了，现在进入实战环节。我会教你配置3条Cache Rules，覆盖从后台排除到全站缓存的完整策略。

准备工作：进入配置页面

先登录Cloudflare控制台，选择你要配置的域名，然后：

1. 点击左侧菜单的”Caching”（缓存）
2. 找到”Cache Rules”标签页
3. 点击”Create rule”（创建规则）按钮 接下来咱们一条条配置。

规则1：绕过后台和管理页面（最高优先级）

为什么要放第一位？ 安全第一！这条规则确保你的后台、登录页面永远不会被缓存。 配置步骤：

1. Rule name（规则名称）：输入Bypass Admin Pages
2. When incoming requests match（匹配条件）：
   • 选择”Custom filter expression”
   • Field选择”URI Path”
   • Operator选择”contains”（包含）
   • Value填入/wp-admin（如果有多个后台路径，稍后再加）
3. 添加更多排除路径：点击”Or”按钮，继续添加：
   • /wp-login.php（WordPress登录页）
   • /admin/（通用后台路径）
   • /api/auth/（如果有API认证接口）
4. Then（执行操作）：
   • Cache eligibility下拉选择”Bypass cache”（绕过缓存）
5. 优先级：设置为1（最高优先级） 配置完点”Deploy”（部署）。这条规则会确保所有包含这些路径的请求都不走缓存，直接回源。 WordPress网站的完整排除列表：

/wp-admin
/wp-login.php
/wp-json
/cart
/checkout
/my-account

根据你自己的网站调整这个列表。

规则2：缓存静态资源（中等优先级）

这条规则其实是可选的，因为Cloudflare默认就会缓存静态资源。但显式配置一下，可以更精确地控制TTL。 配置步骤：

1. Rule name：Cache Static Assets
2. When incoming requests match：
   • Field选择”File extension”
   • Operator选择”is in”
   • Value填入：jpg png gif css js woff woff2 ttf svg ico（用空格分隔）
3. Then：
   • Cache eligibility选择”Eligible for cache”
   • Edge cache TTL选择”Use cache-control header if present, use default Cloudflare caching behavior if not”
4. 优先级：设置为2 这条规则让静态资源优先使用源站的Cache-Control头，如果源站没有设置，就用Cloudflare默认的TTL（通常是4小时到1个月不等，根据文件类型）。

规则3：缓存所有其他内容（最低优先级）

重头戏来了！这条规则会缓存包括HTML在内的所有其他内容。 配置步骤：

1. Rule name：Cache Everything Else
2. When incoming requests match：
   • 选择”All incoming requests”（匹配所有请求）
   • 或者，如果你想更精确，可以选”Custom filter expression”，然后排除某些特定路径
3. Then：
   • Cache eligibility选择”Eligible for cache”
   • Edge cache TTL选择”Ignore cache-control header and use this TTL”
   • 时长选择：7 days（1周）
4. 优先级：设置为3（最低优先级） 为什么选1周？ 这是个平衡点。太短（比如1天）缓存效果不明显；太长（比如1个月）内容更新不及时。对于博客、文档站这类更新频率不高的网站，1周是个不错的选择。 免费版注意：免费账户的最短TTL是2小时，Pro账户是1小时。如果你的内容更新很频繁，可以设短一点。

规则执行顺序很重要

Cloudflare会按照优先级从小到大执行规则：

1. 先执行规则1（优先级1）：检查是不是后台页面，是的话Bypass
2. 再执行规则2（优先级2）：检查是不是静态资源，是的话用合适的TTL缓存
3. 最后执行规则3（优先级3）：剩下的所有请求都缓存1周 这个顺序确保了后台页面肯定不会被缓存，静态资源用合理的TTL，HTML页面强制缓存1周。

完整配置检查清单

配置完三条规则后，检查一下：

• 规则1的优先级最高（数字最小）
• 后台路径都加进了排除列表
• 规则3的TTL根据你的更新频率调整了
• 所有规则都已Deploy（部署） 好了，配置完成！接下来咱们聊聊Edge TTL的一些坑。

Edge TTL配置详解：避开这些坑

Edge TTL（边缘缓存过期时间）是整个缓存策略的核心，但也是最容易出错的地方。我当时就在这踩了不少坑。

三种Edge TTL模式详解

Cloudflare的Edge TTL有三种模式，选哪个很重要： 模式1：Use cache-control header if present, bypass cache if not

• 翻译：有Cache-Control就听它的，没有就不缓存
• 适用场景：你的源站已经配置了完善的Cache-Control头
• 我的评价：太严格了，对于很多小网站来说源站根本没配Cache-Control，这模式就等于不缓存 模式2：Use cache-control header if present, use default Cloudflare caching behavior if not（推荐）
• 翻译：有Cache-Control就听它的，没有就用Cloudflare默认规则
• 适用场景：源站部分配置了Cache-Control，其他的希望Cloudflare智能处理
• 我的评价：最平衡的选择，适合大部分网站 模式3：Ignore cache-control header and use this TTL
• 翻译：不管源站怎么说，强制按我设定的时间缓存
• 适用场景：静态网站、或者你很清楚缓存策略的情况
• 我的评价：霸道但有效，适合全站缓存HTML的场景 对于HTML缓存，我推荐用模式3。为啥？很多网站的HTML页面压根没设Cache-Control，或者设了no-cache（为了安全），这时候模式1和2都不会缓存。模式3直接强制缓存，简单粗暴。

TTL时长怎么选？

这个真的因网站而异。我给你列个参考表：

常见配置错误（我都踩过）

错误1：忘记排除后台页面 我最开始图省事，直接建了一条”Cache Everything”规则，结果WordPress后台也被缓存了。登录的时候老是显示旧页面，操作完还要手动刷新缓存才能看到效果，简直崩溃。 解决方案：务必先建Bypass规则，优先级设最高。 错误2：TTL设太长导致内容更新不及时 有次我把TTL设成了1个月，结果发现改了文章标题，但访客看到的还是旧标题。等了好几天才想起来是缓存的锅。 解决方案：根据你的更新频率合理设置TTL。更新频繁就短一点，更新少就长一点。实在不确定，先设1周试试。 错误3：混淆Edge TTL和Browser TTL Edge TTL是CDN节点的缓存时间，Browser TTL是访客浏览器的缓存时间。这俩是独立的！

• Edge TTL：控制Cloudflare的CDN节点多久回源拿一次新内容
• Browser TTL：控制访客的浏览器多久向CDN请求一次新内容 如果你只设了Edge TTL但没设Browser TTL，访客浏览器还是会频繁向CDN请求，虽然CDN不回源了，但对访客来说速度提升有限。 解决方案：Browser TTL可以设置”Respect origin”（遵循源站设置）或者设个合理的值，比如1天。

手动清除缓存：Purge Cache

内容更新了怎么办？不用等TTL过期，可以手动清缓存。 在Cloudflare控制台：

1. 进入”Caching”菜单
2. 找到”Purge Cache”区域
3. 可以选择：
   • Purge Everything：清空整站缓存（简单粗暴）
   • Custom Purge：清除特定URL的缓存（精准） 我一般用Custom Purge，只清更新的那几个页面。全站清除会导致短时间内所有请求都回源，服务器压力瞬间飙升。 小技巧：如果你用WordPress，可以装个Cloudflare插件，发布文章时自动Purge相关页面的缓存，非常方便。

验证和优化：确保缓存真正生效

配置完了，怎么知道有没有生效呢？别光猜，咱们用数据说话。

方法1：浏览器开发者工具查看

这是最简单直接的方法。

1. 打开Chrome浏览器（或其他浏览器）
2. 按F12打开开发者工具
3. 切到”Network”（网络）标签
4. 访问你的网站首页
5. 在Network列表里找到HTML文档（通常是第一个请求）
6. 点击它，查看”Headers”（响应头） 重点看这几个header： cf-cache-status：这是关键！可能的值：

• HIT：缓存命中！说明内容是从CDN拿的，没回源
• MISS：缓存未命中，这次回源了，但内容会被缓存下来
• DYNAMIC：动态内容，不缓存（可能是你的Bypass规则生效了）
• BYPASS：明确绕过缓存（应该是后台页面）
• EXPIRED：缓存过期了，CDN回源更新 第一次访问通常是MISS，第二次访问应该就变HIT了。如果一直是DYNAMIC或BYPASS，说明配置有问题。 age：这个header显示内容在CDN上缓存了多久（秒）。比如age: 3600表示这个内容已经在CDN上缓存了1小时。 cache-control：源站设置的缓存策略。即使你在Cloudflare用了”Ignore cache-control”模式，这个header还是会显示，但Cloudflare不会遵循它。

方法2：用curl命令验证

如果你习惯用命令行，curl更方便快捷：

curl -I https://your-website.com

输出会显示所有response headers。找到cf-cache-status看看是HIT还是MISS。 想看更详细的？用这个：

curl -svo /dev/null https://your-website.com 2>&1 | grep -i "cf-cache"

这会只显示Cloudflare相关的header。

方法3：Cloudflare Analytics查看缓存指标

想看整体效果？进Cloudflare控制台：

1. 选择你的域名
2. 点击左侧”Analytics”菜单
3. 找到”Caching”标签页
4. 查看”Cache Hit Ratio”（缓存命中率） 配置前我的命中率是30%，配置后第二天就涨到了85%，现在稳定在90%左右。如果你的命中率也有这个涨幅，说明配置成功了。 正常指标参考：

• 缓存命中率：目标80%以上
• 带宽节省：应该能看到明显下降（因为很多内容不回源了）
• 请求数：CDN服务的请求数大幅增加，源站请求数大幅减少

提升缓存命中率的进阶技巧

如果命中率还是不够高，试试这些优化： 技巧1：预热缓存 新发布的内容第一次访问肯定是MISS。如果你希望用户第一次访问就是HIT，可以提前”预热”： 发布新文章后，自己先访问一遍所有页面，让CDN把内容都缓存下来。或者写个脚本自动crawl你的站点。 技巧2：统一URL格式 同一个页面，不同的URL会被视为不同的缓存对象：

• https://example.com/page 和 https://example.com/page? 是不同的
• https://example.com/page 和 https://example.com/page/ 是不同的 确保你的网站链接格式统一，避免无谓的缓存MISS。 技巧3：去除无用的Query String 如果你的URL带了追踪参数（比如?utm_source=twitter），每个参数组合都会被视为不同的页面，缓存命中率会大幅下降。 Cloudflare有个”Query String Sort”功能，可以在Caching设置里打开，会把query参数排序后再缓存，一定程度上能提升命中率。 更好的做法是用Cloudflare的Transform Rules把不影响内容的query参数剥离掉。

常见问题排查

问题1：cf-cache-status一直显示DYNAMIC 可能原因：

• 源站的Cache-Control设置了no-cache或private
• 你的Cache Rule没配对，请求没匹配到”Eligible for cache”规则 解决：检查Cache Rules的匹配条件，确保HTML请求被包含进去。如果用了模式3（Ignore cache-control），应该能强制缓存。 问题2：缓存命中率只有50-60%，不够高 可能原因：
• 有些页面的URL带了动态参数
• 源站的某些header阻止了缓存
• CDN节点还在逐步缓存内容（刚配置完需要时间） 解决：给新配置一两天时间，让CDN节点都缓存上内容。同时检查Analytics，看哪些类型的请求命中率低，针对性优化。 问题3：更新内容后，访客还是看到旧的 可能原因：TTL设太长了，或者Browser Cache也缓存了 解决：发布内容后手动Purge Cache。或者装个自动化插件（WordPress有很多）。

总结一下

说了这么多，咱们回顾一下核心步骤：

1. 理解Cloudflare为什么默认不缓存HTML：主要是安全考虑，避免缓存动态内容和敏感页面
2. 从Page Rules迁移到Cache Rules：Page Rules即将废弃，Cache Rules更强大灵活，“Eligible for cache”就等于以前的”Cache Everything”
3. 配置3条Cache Rules：
   • 规则1（优先级1）：Bypass后台和登录页面
   • 规则2（优先级2）：缓存静态资源
   • 规则3（优先级3）：强制缓存其他所有内容（HTML），TTL建议1周
4. 选对Edge TTL模式：对HTML用”Ignore cache-control and use this TTL”强制缓存，根据更新频率调整时长
5. 验证效果：用浏览器开发者工具看cf-cache-status，用Analytics看缓存命中率，目标80%以上 我自己配置完后，缓存命中率从30%飙到90%，TTFB从500毫秒降到100多毫秒，服务器负载减少90%。效果真的很明显，特别是对访问量大的网站。 现在就动手试试吧：
6. 先去Cloudflare Analytics看看你现在的缓存命中率
7. 按照文章的步骤配置3条Cache Rules（记得先排除后台！）
8. 等一两天，再去Analytics看看效果 如果你遇到问题，检查一下：

• 后台页面有没有被Bypass？
• Cache Rules的优先级对不对？
• Edge TTL模式选对了吗？ 对了，如果你用的是WordPress，强烈建议装个Cloudflare官方插件，发布文章自动清缓存，省心多了。 有什么问题或者优化经验，欢迎在评论区分享，大家一起交流！

发布于: 2025年12月1日 · 修改于: 2025年12月4日

Easton

技术开发