静态站却让所有请求都先过 Worker：检查 run_worker_first

要点

• 作者说他的静态站配置里有一行 "run_worker_first": true，导致每个静态资源请求都先调用 Worker；额度邮件升到 92% 后他把它改掉了。
• 他在后续帖子里写道，这行配置是 AI 代理在迁移到独立域名时加的：没有用简单的 301 跳转，而是让所有请求都走 Worker，上千用户的访问量就能耗光每天 10 万次的免费请求额度。他称这次没有实际损失。
• 官方文档（2026-10-14 复核）：run_worker_first 默认为 false；设为 true 时即使请求命中静态资源也会先调用 Worker；也可写成路由模式数组，只对指定路径生效。静态资源请求免费且不限量，Worker 调用按 Workers 价格计费；Free 方案超出请求额度后，这些请求返回 429，而不是回退到静态资源。

原始来源

1. 发布2026-10-13

   原帖

   到 𝕏 阅读

   gm365 的静态站连续收到 Workers 额度告警邮件（最高 92%），排查后发现是 AI 在配置里写了 "run_worker_first": true。

   gm365

   @gm365 · 𝕏 原帖

   差一点就体会了一把什么叫“CF 账单刺客”。 早上连续收到 CF 的邮件告警，都是 CF Worker 额度消耗进度的内容（最高到 92%） 让 Grok Bot 检查了一下，原来之前不知道是哪个 AI 给我埋的坑。 配置文件写了一行： "run_worker_first": true 明明是一个静态站，结果所有资源都先请求一遍 CF Worker（纯纯没必要啊）。 赶紧给改了，AI 大佬们写代码手下留情吧。

   2026-10-13 03:16:17 UTC

2. 2026-10-13

   后续：作者追查是谁加的这项配置，称上千访问量就能耗光每天 10 万次免费请求，并提到此前 AI 写的代码发起几十亿次 RPC 请求、账单达 1200 美元的经历。

   到 𝕏 阅读

   gm365

   @gm365 · 𝕏 原帖

   GPT 6 Astra 模型是真的能出活儿，不服不行 今天发现 CF Worker 额度告警，一通分析，发现问题出在一个配置项上。 先是 Grok Bot 分析，然后出 PR，之后 Opus 5.5 审计并合并上线。 结束后，我又重新打开了 Claude 会话，想让它分析下当初是谁改的这个配置项（罪案现场调查）。 很快就有结果了，原来是大聪明 GPT 6 Astra (medium)。 当初因为迁移到独立域名，Astra 直接在 CF 配置文件中，让所有请求都走 Worker。 明明有更简单的方案（配置 301 跳转），但需要人类辅助操作一下，于是 Astra 自作聪明，选了一条自己就能搞定的路子。 结果是埋下隐患。 上千用户访问量，直接就能耗光一天 10 万的 Worker 请求额度。 虽然没有实际损失，但这个代码水平，你哪敢放心让 Codex 帮你处理任何严肃的生产代码。 要说真损失，那还得是 Gemini 3.8 帮我写的代码，调用了几十亿次 RPC 请求，直接让账单原地爆炸（$1200）。 差的模型让你更快、更多的亏钱，算是体会到了。 没想到的是，连 GPT 6 Astra 都归到了跟美国大豆包一个类别。 所以问题来了： Gemini 4 为何还不放出来？ GPT 为何还不推出匹敌 Opus 5.5 的模型？ 国产模型这么久来还没新消息，真的是因为 Claude 屏蔽了 99% 的蒸馏请求导致的？

   2026-10-13 04:14:07 UTC