分享这个内容是为了警告任何使用 Cloudflare Durable Objects（持久对象）和警报的用户。
<p>根本原因：</p>
我的 DO 代理的 onStart() 处理程序在每次唤醒时都调用了 this.ctx.storage.setAlarm()，而没有检查是否已经安排了一个警报。加上 60 多个预览 Worker 部署，每个都创建了独立的 DO 实例，这导致了一个失控的自我健康检查循环。
<p>时间线：</p>
- 4 月 3 日：循环开始（在此日期之前没有 DO 使用）
- 4 月 4-5 日：达到约 9300 亿行读取/天的峰值
- 4 月 11 日：发现问题并修复
- 4 月 15 日：收到 34,895 美元的账单，但尚未收到任何账单回应
<p>修复方法：</p>
```javascript
// 修复前（危险）
async onStart() {
await this.ctx.storage.setAlarm(Date.now() + 60_000)
}
// 修复后（安全）
async onStart() {
const existing = await this.ctx.storage.getAlarm()
if (!existing) {
await this.ctx.storage.setAlarm(Date.now() + 60_000)
}
}
```
<p>值得做的其他事情：</p>
- 完全从预览环境中移除 DO 绑定
- 部署一个预算监控的杀死开关 Worker
- 添加一个电路断路器，在调度之前检查警报状态
<p>为什么我没有收到警告：</p>
Cloudflare 的 Workers 使用通知仅监控 CPU 时间，而不监控 Durable Object 的行读取或写入。仪表板或 Wrangler 配置中也没有可用的 DO 操作硬性支出上限。在这个失控的过程中，没有任何东西会触发警报。我是在账单出现时才发现的。
<p>如果你在使用 DO 警报，这一点值得知道。平台不会告诉你 DO 行读取/写入何时呈指数增长。你必须自己建立一个杀死开关。</p>
<p>还有一件我认为值得更多关注的事情：这是代理周。Cloudflare 目前正在进行专门的营销推广，鼓励个人开发者在 Durable Objects 上构建 AI 代理。博客文章、公告，所有的一切。这是一个有意的努力，旨在将独立开发者和独立创始人引入一个可以在没有任何平台警告的情况下悄然产生五位数账单的产品。DO 操作没有支出上限。使用通知系统不涵盖 DO 的读取或写入。Cloudflare 知道这一点。在这个缺口存在的情况下进行代理周的决策并不是中立的。</p>
我已经提交了案例 02067725。我是一名预发布的独资经营者，将我所有的个人储蓄投入到这个初创公司中。这张账单将会在没有任何商业价值的使用情况下摧毁我的财务。在这里分享既是技术警告，也是因为我需要帮助将此问题呈现给 Cloudflare 的某个可以做出决策的人。
有没有人成功升级过与 Cloudflare 的账单争议？
返回首页
最新
尽管Anthropic的Mythos声称非常高大上，但这个测试工具却让人感到困惑且愚蠢。<p>根据报告，它通过“听起来有多可疑”来对每个文件进行排名，然后用简短的指示循环处理每个文件，要求“找出一个漏洞”，将候选项交给评审和ASan检查器——结果零日漏洞就这样显现出来。<p>这本不应该有效。<p>但它确实有效。<p>在miniupnp上，使用20美元的计划，Opus 4.6可靠地重新发现了旧版本中的已知CVE，甚至还发现了一个新的远程全局缓冲区溢出（非默认配置）。<p>那么，如果这个测试工具实际上是好的——也就是说，配备了适当的安全工具，会发生什么呢？<p>我是一名学生，而不是安全工程师，因此我非常希望能得到关于我计划的工具路线图的想法或批评。<p>（如果你有200美元的计划并且有额外的使用额度，可以试试看，看看它是否能在你自己的C代码中发现零日漏洞。）