Cloudflare 爆单案例、免费档服务额度与防护做法

一、几个爆单案例

有位独立开发者，平时 Cloudflare 每月不到 10 美元。后来 D1 里出了一个 bug：程序反复往数据库写同样的数据，内容根本没变。月底账单是 2739.12 美元，光 D1 写入就约 2641 美元。

他找了 Cloudflare。对方给了 2141 美元的 goodwill credit，但这笔钱只能抵以后的账单。已经从卡里扣掉的钱不退。

这不是孤例。还有人的 D1 账单也到了上千美元。另一个人用 AI 建站，读写约 1.8 亿次，账单一千多元人民币，约 142 美元。

这几件事有共同点：都已经开通了付费，或者用了按量计费的产品；程序出错时没有东西把它停下来；等发现时，钱已经扣了。

要防这种事，先得清楚 Cloudflare 各产品免费给多少，超了以后是报错还是扣钱。

二、常用产品和免费额度

下面是免费档里常用的几个产品。

Workers：每天 10 万次请求，按 UTC 时间重置。单次请求 CPU 时间 10ms，内存 128MB。

Pages：静态资源免费，不限请求。Pages Functions 和 Workers 共用每天 10 万次请求的额度。每月 500 次构建。

R2（对象存储）：每月 10GB 存储、100 万次 Class A 操作、1000 万次 Class B 操作，出口流量免费。超额价格：存储 0.015 美元/GB·月，Class A 4.50 美元/百万次，Class B 0.36 美元/百万次。按计费单位向上取整。

KV：每天 10 万次读，写、删除、列表各 1000 次，存储 1GB。

D1（SQLite 数据库）：每天读 500 万行、写 10 万行，存储 5GB。开通 Workers Paid 后，超出部分按行计费。前面的爆单案例大多出在这里。

Queues：每天 1 万次操作。付费后 0.40 美元/百万次操作。

Workers AI：每天 1 万 Neurons。要超额使用得先开 Workers Paid，价格 0.011 美元/千 Neurons。

Durable Objects：免费档只能用 SQLite 后端。大约每天 10 万次请求、13000 GB-s，额度和 Workers 分开算。

三、超额后的两种结果

超额后分两种情况。

报错，不扣钱。 Workers 和 Pages Functions 超过每天 10 万次后，返回 Error 1027。KV、D1 在免费档下超额，操作直接失败。服务会断，但不会产生账单。

继续跑，继续扣钱。 R2、Queues、开通付费后的 Workers AI，还有付费后 D1 的超量部分，都会照常执行，然后按量计费。

我自己有个旁证。我有个项目的 Pages Functions 某天峰值到了 121040 次，超过 10 万免费额度约 21%。结果是超出的请求报错，没有扣钱，也没有收到任何告警。我是后来自己查用量才发现的。

所以免费档上的 Workers 和 Pages Functions 风险不大，坏处只是服务中断。真正可能扣钱的，是 R2、Queues、Workers AI，以及开了 Paid 的 D1。

四、Budget 不是硬止损

Cloudflare 后台的 Billable Usage 里可以建 Budget。但它只发邮件，不会停服务。

另外还有 threshold billing：用量到了一定金额会在账期中途扣款。这个阈值账户自己改不了，而且每个账户只触发一次。它的作用是提前收钱，不是限制花费。

两者都不是硬停。有人说 2026 年第四季度可能推出硬上限的早期版本。没上线之前，不要把它当作现有的保护。

五、怎么防

下面是我做了的和建议做的事。

1. 用 Access 锁住只给自己用的项目。
我把自己的部分项目加到了 Cloudflare Access 里。没登录的访问会被 302 跳转到登录页，不会执行 Functions，也就不消耗请求额度。但 Access 只管 HTTP 入口，挡不住程序内部对 R2、D1 的读写。

2. 定时查用量。
Cloudflare 的 GraphQL Analytics 接口能查各产品用量。我用 GitHub Actions 每 6 小时跑一次脚本。两个账户各建一个 API Token，权限只给 Analytics Read，别的都不给。阈值分 50%、80%、100% 三档。默认只发通知。脚本里保留了 disable 和 panic 两个开关，但真要停服务还是我手动操作，不让脚本自动停机。

3. R2 设生命周期规则。
临时文件的桶设 30 天自动删除。不要指望自己记得清理。

4. R2 桶不公开。
对外提供文件时，用 Worker 做一层转发，或者发预签名 URL。公开桶的读操作谁都能刷，Class B 次数会涨得很快。

5. Token 最小权限。
每个 Token 只给需要的权限。监控用的只读，部署用的只给对应项目。Token 泄露了，损失也有限。

6. Workers 路由想清楚 fail open 还是 fail closed。
超额后请求是直接放行到源站，还是返回错误，要根据业务提前选好。

7. 不需要付费就不绑卡。
如果确定只用免费额度，可以不绑卡。这样需要付费的能力会直接失败，也就产生不了账单。要注意：取消 R2 的 Paid 后，桶里的文件还在，生命周期规则也得自己配。

六、这些做法的局限

我的监控每 6 小时查一次，两次之间出的事要等下一次才知道。一个写入死循环几个小时就能跑出很多费用。

GraphQL 只能看到已经发生的用量，没法预测，也没法拦截。

Budget 只发邮件，threshold billing 只是提前扣款，都不能当硬止损用。

作为参考，我这边目前的用量：Workers 日峰 2180 次（额度 10 万），R2 Class A 85 次、Class B 20906 次，存储 0.3GB，Pages Functions 日峰 121040 次（121%）。除了 Pages Functions，其余都离额度很远。

七、小结

Cloudflare 免费档本身不会扣钱，超额只会报错。会扣钱的是 R2、Queues、Workers AI 和开了 Paid 的 D1。官方的 Budget 只是提醒，不会停服务。

能做的是：入口用 Access 锁住，桶不公开，Token 最小权限，临时数据设生命周期，用量定时查，不需要付费就不绑卡。这些不能保证不出事，但能让你早点发现，损失也小一些。