我每个月在 Cloudflare 上花多少钱？从白嫖 18 个月到月付 $72 的账单复盘

💡 核心速览

1. 白嫖期与转折点：从 2024 年 3 月开通 R2 到 2025 年 8 月，整整 18 个月账单金额全部为零，免费额度足够支撑早期的低频流量。真正的费用拐点始于 2025 年底将核心业务迁入 Cloudflare 并 Images 服务。

2. 月结规律与尖刺波动：每月 17 号是我的结算日。基础费用是 Workers Paid 的 $5.00，但在 2026 年经历过多次跳涨，从 2 月的 $19.34 到 5 月的 $15.13，并在 9 月份创下了 $32.55 的单月新高，叠加域名续费当月总支出达到 $71.95 😭。

3. 隐形扣费刺客：从请求数超量，到 Workers Observability，再到边缘缓存穿透。其实这里的坑比想象中多不少。

4. 缓存治理带来的直接收益：通过不断改进缓存，我们很好控制了云服务账单，验证了良好架构对降低云成本的决定性作用。

从“18 个月 $0”到月付 $72

每个做独立开发或者小团队技术选型的人，大概率都听过类似的宣传：“Cloudflare 是全世界对独立开发者最慷慨的云厂商，只要 $5/月就能跑遍全球，简直赛博菩萨。”

这话到底有没有水分？作为一个早在 2018 年就注册 Cloudflare、如今在上面托管着 20 个主域名，十几个全栈项目（包括本个人站、MuiCV、MuiRouter AI 网关、常用工具站、free-ai-api 导航站等）的老用户，我决定用真实的信用卡账单来给出答案。

我先介绍一下我的情况：

1. 我有 20 个主域名，大部分网站跑在 Worker 上，用 Next.js + OpenNext 或者 TanStack，也有少数静态页面

2. 我有网站、App 等，流量大的主要是这个博客、FreeAIAPI.org、拜拜在线拜佛、My-Playlist.app。其它网站流量不大

3. 我基本会选择 Cloudflare 全家桶，包括 R2 存储，D1 数据库，KV，DO 等等

4. 除了本站，我主要做出海，以 i18n 为主

5. 本站是老站，有大量爬虫整天爬来爬去

好，咱们继续。我的账单曲线非常鲜明地划分为三个阶段：

历史阶段	时间跨度	月均总支出	典型特征
阶段一：纯白嫖时代	2024.03 ~ 2025.08	$0.00	连续 18 个月出账 $0，R2 存储与免费 CDN 完全够用
阶段二：上车探索期	2025.09 ~ 2025.12	$10 ~ $21	域名转入 Cloudflare Registrar，开通 $5 Workers Paid
阶段三：业务爆发与尖刺期	2026.01 ~ 2026.09	$6 ~ $72	全面边缘全栈化，月结账单突破基线，9 月创下历史新高

我虽然在 2024 年 3 月就绑定信用卡并开通 R2 Paid（按量付费模式），但因为 Cloudflare 提供不少的免费额度，我的个人站点和小工具根本用不完。于是每个月的 17 号，系统都会按时给我发来一张 $0.00 的账单。

转折点发生在 2025 年末。随着我开始在 Cloudflare 部署更复杂的动态应用、自建基于 Durable Objects 和 D1 的 API 计费网关，把越来越多的域名转入托管，账单开始有了巨大的变化。

到了 2026 年 9 月，我的单月付款总额达到了 $71.95：

• 2026-09-05：扣费 $28.20

• 2026-09-17：月结扣费 $32.55（历史单笔云服务月结最高）

• 2026-09-19：扣费 $11.20

拆解账单：我的钱花在哪里？

仔细观察全部 49 笔账单的时间分布，可以发现一个非常清晰的账目分离逻辑：每月 17 号的固定月结单，以及非 17 号发生的离散扣款。

1. 离散扣款：域名资产池的成本价维护

在账单里，经常会出现诸如 $10.46、$11.20、$7.50、$4.18 这种零碎扣费。

只要对域名市场稍微熟悉一点，就能认出 $10.46 这个经典数字：这是 Cloudflare Registrar 对 .com 域名收取的纯成本续费价（Verisign 批发价 $10.28 加上 ICANN 的 $0.18 规费，Cloudflare 不赚差价）。

随着我陆续将 meathill.com、muicv.com、xiaoniaoshuo.com 以及若干垂直工具域名统一托管，这部分支出本质上是资产维护成本，无论你用哪家云厂商，域名都是刚性开销。

2. 17 号月结单：真实的边缘云基础设施开销

剔除掉域名后，我们把目光聚焦在每个月 17 号扣除的云服务月结账单上。2026 年以来的月结走势如下：

账单结算日	月结扣款金额	相对 $5 底座的溢出部分	核心驱动因素
2026-01-17	$5.00	$0.00	纯净的 Workers Paid 基础月费
2026-02-17	$19.34	+$14.34	开通 Images Basic，媒体动态变换与存储开销激增
2026-03-17	$7.50	+$2.50	请求量小幅超量
2026-04-17	$6.26	+$1.26	流量平稳，轻微超量
2026-05-17	$15.13	+$10.13	多个 Worker 并发激增，D1 与 CPU 耗时拉长。AI 加持下，网站越做越多，自然增长。
2026-06-17	$14.92	+$9.92	持续处于高负载调用期
2026-07-17	$5.00	$0.00	全站边缘缓存深度治理生效，重回基线！
2026-08-17	$10.45	+$5.45	业务继续增长，带来自然请求超量
2026-09-17	$32.55	+$27.55	prefetch 肘击自己，Observability 遥测与日志暴击！

从这张表可以看出，Cloudflare 的底层扣费从来不是失控的黑天鹅，每一次跳涨和每一次回落，背后都精准对应着一次架构演进或配置疏漏。

四大扣费刺客与架构避坑实录

很多人，包括我自己，以为部署在 Workers 上的代码超量了只会按请求数计费。这个费用极其低廉，即使多出几百万次请求，也就一两杯咖啡钱。但其实不然，因为关联着的，还有能让账单翻倍的隐形刺客。

刺客 1：Worker 缓存穿透

不怕大家笑话，第一次看到 Cloudflare 账单的时候我震惊了：啥？我竟然已经把 Worker 免费额度用完了？就这？

实际上，由于之前只用过自建 VPS 和 Cloudflare CDN，我对 Worker 的理解其实是偏颇的。我以为 Worker 就是一般的服务器；Worker 输出的时候，只要加上缓存头，就能改变 CDN 行为，缓存输出的结果——之后的用户访问的都是 CDN 缓存，不会有请求打到 Worker，自然也就不需要花钱。

然而事实并非如此。Worker 最初是作为可编程网关存在的，它的 JS runtime 是裁剪过的，很小很快，目的就是利用能拿到的各种信息，快速响应用户请求。但与之相伴的是：CDN 不会缓存 Worker 响应！

解决方案有几个（当时）：

1. 提前把网页渲染好，存在静态缓存里，直接发给用户。这样做性能最好最便宜，但是有两个问题：

   1. 静态页面肯定有很多限制

   2. 构建阶段的环境和运行时有巨大差别，包括数据库、服务绑定等，很难做好

2. ISR：把页面存下来，用户访问就直接返回，虽然请求数下不来，但是可以节省 CPU 时间

3. 手动调用 Cache API：手动缓存页面，连请求数都可以生下来，唯一的缺点是麻烦，但我们有 AI

一通操作之下，我的账单在7月（实际是6月）短暂恢复到 $5 基线。

（关于我推荐的缓存最佳实践，近期应该能写出来吧。）

不过现在好多了，因为 Cloudflare 终于推出 Worker Cache，只需要启动 Worker Cache，Worker 的响应体就会遵守常见的缓存约定，在 CDN 层存留提供服务。不需要再手动处理。

{
  "cache": {
    "enable": true
  }
}  

刺客 2：Cloudflare Images

2026 年 1 月 24 日，我为了给博客和媒体站提供高性能的 WebP/AVIF 自适应压缩与缩放，开通了 Images Basic Base。

使用 Next.js 的内建组件 <Image> 配合 Cloudflare Images 本身体验不错，轻松上线。但是，如我所说，我这是个老站，一堆爬虫整天爬来爬去，所以很快，每个月 5k 次唯一转换（图片+尺寸+格式）的额度就用完了，然后开始每天 $0.5（约1k次）的快速消耗。

于是我赶紧行动：

1. 重构网站，现在本站（访问量最大的网站）首页（访问量最大的页面）只有 6 篇博客

2. 请 AI 帮我检查访问日志，找出可疑来源直接屏蔽或者加验证码

3. 手动设置优化尺寸，减少转换次数

4. 将缓存时间增加到 1y

一套操作下来，终于把图片转换控制在免费额度附近，最近几个月每个月大概多 1k 次。我建议大家，参考 Next.js 图片怎么这么贵？！——Cloudflare 原生 Image Resizing 避坑与最佳实践 的做法，控制好成本。

刺客 3：Workers Observability

开发复杂的分布式边缘应用时（比如我自研的 MuiRouter 网关，需要处理流式响应、异步计费、Durable Object 状态机），必须开着 Observability。这样我才能从控制台能看到每一步的耗时、分布式调用链和错误堆栈。

但是当我们的服务已经开始稳定运行，同时还要兼顾开发维护数个其它项目的时候，这里的日志就没什么特别大的意义了。更多时候，我们都是发现问题才会来处理，绝大部分日志看都不会看。

9 月初，我运气不错，发出一篇爆款文章，没想到接下来就被 Next.js 的 Prefetch bug DDOS（详见 乐极生悲的 Next.js+OpenNext 生产踩坑排错实录：被10+M R2读操作和10M+ Worker 请求轮番肘击的一天）。免费额度一天烧完，马上开始扣费。我当然不可能关闭 Worker，所以，只好停掉所有项目的 Observability。但最后还是花了 $3。

实际上，我建议大家长期关闭项目的 Observability，只定时开放特定项目的 Observability 并收集收据，处理完问题就关闭。

刺客 4：缓存位置的选择

开发内容类网站，比如本站，或者 freeaiapi.org 的时候，ISR 是首选方案。我们可以参考官方文档来做：https://opennext.js.org/cloudflare/caching。

这里的问题在于，KV 需要最多 60 秒的时间完成全球同步，所以官方文档没有首推 KV。然而，R2 的作用要广泛得多，各种文件上传、格式转换都需要用到，所以通常来说额度更加紧张。我的案例就是如此，还是那次 Prefetch Bug 导致的全账户额度紧张，我没有办法避免使用 R2，后面还是该付费就付费。如果我用 KV 做 ISR，停掉便是。

所以我建议大家使用 KV 存储 ISR 缓存。或者至少一个站用 KV，一个站用 R2。

不过，使用 KV 做 ISR 则要小心一个存在已久的 Bug：OpenNext 在处理 KV ISR 的时候不会传入 TTL，可能会很快撑爆 KV 存储，我们需要手动补丁以避免问题。具体可以参考我最近的博文：潜伏的缓存刺客：Next.js + OpenNext + Cloudflare KV 存储暴涨实录。

总结

回顾近三年来费用从 $0 到 $72 的演变，我对 Cloudflare 的计费体系有了完全不同的理解：

第一，$5/月的神话是真实的，但它代表的是“入场券”，而不是“包打天下”。Cloudflare Workers Paid 提供的 1000 万次请求和全球调度能力，性价比在整个云行业依然是无可匹敌的。不过当你的产品和业务达到一定规模，架构仍然是不容忽视的一环。

第二，之前的经验仍然有用，但需要因地制宜。比如建立缓存层就能节省大量资源消耗，但是 Cloudflare Workers + CDN 会怎么工作，应该用什么来存储缓存，还是需要深入研究。

第三，Cloudflare 目前的计费功能比较弱，需要我们自己注意。不得不说，Cloudflare 目前的计费功能很差，更新不及时、没有硬上限、分拆不够清晰，导致我们很难根据现状及时调整，更是不知何时就会遭到刺客暴击。所以我们自己平时要多查看账单。每天至少看两三次吧。

如果你对 Cloudflare 有什么问题，欢迎提问；如果你觉得我的上文有误，欢迎指出。希望这篇文章对大家有帮助，请大家不吝分享扩散，谢谢大家。