服务对象与地域限制
PuppyIP 仅面向海外合规企业及其授权人员提供服务，不面向中国大陆地区开放或提供代理服务。本服务仅限用于中国大陆境外的合法业务活动，严禁在中国大陆境内使用本服务。
代理 IP 或服务器位于境外，不改变上述限制。不得通过中转、转接、共享或转售向中国大陆境内的最终使用者提供本服务。使用前请阅读用户服务协议。
本文要点
- 11 月 10 日更新允许用 concurrency.limit 限制单个 Workflow；需要 Wrangler 4.127.0 或更高版本，本地开发不执行这项限制。
- 账号同时运行实例上限为 Workers Free 100、Workers Paid 50,000，由账号内所有 Workflows 共享；单个工作流上限不能提高账号额度。
- 超过并发上限会进入 queued，等待空位。短暂睡眠或重试可能仍占槽；只有实例实际转为不计入并发的 waiting 或 paused 状态后，才会释放槽位。
- Workers Paid 的定时实例每次触发有最多一小时的并发预算，期间不消耗 Workflow 并发槽，也不受单个 Workflow 上限阻挡；之后进入普通队列。
新增上限限制什么，为什么实例显示 queued？
Cloudflare 于 2026 年 11 月 10 日公布单个 Workflow 并发上限，用来控制同一工作流同时运行多少个实例。例如，数据库只能承受少量并行连接时，可以降低相关工作流的并发，避免所有任务同时访问下游。这里的实例是一次工作流执行，不是其中的一次 HTTP 请求。
正常受限实例必须同时满足账号和工作流两项容量条件。账号上限由所有工作流共享：Workers Free 为 100，Workers Paid 为 50,000；即使某个工作流低于自己的上限，账号满了也会排队。Workers Paid 定时实例的特殊预算见下文。
超过并发上限的实例不会因此被拒绝，而是进入 queued，等正在运行的实例结束或释放槽位后再启动。没有单独配置上限的工作流仍可使用账号的全部可用并发；queued 既不是 completed，也不能单凭它认定任务失败。
怎样设置，并避免下次部署时丢失？
先确认使用 Wrangler 4.127.0 或更高版本，再在定义该 Workflow 的 Wrangler 配置中设置 concurrency.limit，然后部署对应 Worker。假设把值设为 10，普通受限执行最多同时占用 10 个实例槽；这个数字必须是正整数，且不能超过账号上限。本文没有替任何账号执行部署。
每次部署都会按当前配置设置上限。若某次部署漏掉 concurrency，原上限会被移除，因此应把设置保留在实际使用的配置中。调低上限不会停止已经运行的实例；已有数量高于新值时，等待数量降到新上限以下才启动新的受限实例。
本地开发不应用这项并发限制，不能仅凭本地结果判断线上限流是否生效。concurrency 不能与 script_name 一起配置；若绑定的是另一个 Worker 定义的 Workflow，应在定义它的 Worker 上设置，而不是只改调用方。
sleep、重试、暂停和回滚，哪些状态仍占槽？
实际处于 waiting 或 paused 的实例不计入并发。调用 step.sleep、等待重试或 step.waitForEvent 后，实例可能进入 waiting，但释放并不一定立即发生：短暂等待期间仍可能保持 running 并占用槽位。
running、正在完成当前工作以准备暂停的 waitingForPause，以及执行回滚处理的实例仍会计入。选择上限时，应把短暂睡眠或重试仍占槽的情况算进去，不能把“正在等”一概当作已释放。
waiting 或 paused 实例准备继续执行时，若账号或工作流已满，会再次排队。核对原实例的实际状态与容量条件，再判断是否需要处理；直接新建一个相同任务可能重复触发业务动作。
为什么 Paid 定时任务可能超过配置的数字？
Workers Paid 中由 schedules 创建的 Workflow 实例，每次 cron 触发有最多一小时的并发预算。在这段预算内，它不消耗 Workflow 并发槽，单个工作流上限也不会阻挡它。因此，观察到定时实例运行，不能直接推断 concurrency.limit 已失效。
预算用完后，实例会让出执行机会并进入普通并发队列，等账号与工作流都有空位时恢复。文档说明，它不会仅因为用完这项预算而失败、超时或终止。
这一小时是并发调度规则，不是免费使用承诺，也不是 CPU、步骤数量或总运行时保证。它针对 Workers Paid 的 Workflow 定时实例，不能直接套用到 Workers Free、普通 HTTP 请求或其他 Cron Trigger 执行类型。
并发排队、创建限速和费用要分开查
实例创建频率是另一项限制：当前表列 Workers Free 每秒 100 个；Workers Paid 每账号每秒 300 个、每工作流每秒 100 个。超过创建频率可能返回 HTTP 429，这与已有实例因并发不足而 queued 是不同情况。
队列也有容量上限，当前表列 Free 100,000 个、Paid 2,000,000 个。不能据“超过并发会排队”推定任务可以无限创建、永远保留或一定立即启动；这几份来源也没有给出确定等待时长。
本次核验的公告、并发说明和限制页没有说明排队实例的具体计费处理。不要把排队或定时并发预算理解成免费；费用、实际账号权限和地区可用性应另按所用账号的当前正式条款核对。
调整前后，怎样确认自己的任务结果？
先记录目标 Workflow、Wrangler 版本、实际部署配置、账号容量及原实例 ID。在已有授权范围内，用少量、无外部副作用的任务观察 queued、running、waiting 和完成状态；本地开发不执行这项上限，不能代替线上验证。
把“已创建”“正在运行”和“业务已完成”分开记录。若任务涉及写入或外部 API，核对原实例与下游结果后再决定是否重试，避免把容量等待当成失败而重复提交。
本文基于第一方公开说明，没有访问任何 Cloudflare 账号、部署 Worker、创建实例或测试账单。具体账号是否可用、实际等待多久及业务效果仍未验证；代理出口也不会增加账号并发或赋予平台资格。
资料来源
常见问题
排队实例严格按创建顺序启动吗？
文档说按进入队列的顺序尽力调度，属于 best-effort，而不是严格顺序或固定启动时间保证。要按业务顺序执行的任务仍需自己的顺序控制，不能只依赖并发队列。
多个工作流的上限相加，必须等于账号上限吗？
不需要。文档允许各工作流上限之和超过账号上限，但这些上限只是容量封顶，不是预留配额。给重要工作流设置一个值，不会为它锁定槽位；还应限制其他工作流，避免它们耗尽共享容量。