Puppeteer 免费额度用完怎么办：限额、重置与升级

小土豆 技术创作者 2026-11-04 90 阅读

Puppeteer 免费额度用完通常不是 Puppeteer 本身“欠费”，而是承载浏览器的云服务触发了并发、请求数或时长限制。截至 2026-07-29 的公开资料，Puppeteer 官方仓库提供的是浏览器自动化 API；额度规则取决于你使用的云浏览器服务。当前最值得排查的方向是：先区分本地 Puppeteer 与云端浏览器，再确认具体限制、会话是否被占用，以及额度何时重置。

先分清：Puppeteer 本身没有统一免费额度

Puppeteer 是一个用于控制 Chrome 或 Firefox 的 JavaScript 库，默认以无可见界面的 headless（无头浏览器）方式运行。官方安装方式有两种：

npm i puppeteer

这会下载与当前包版本兼容的 Chrome；如果只需要把 Puppeteer 当作库使用，并使用系统已有的浏览器，则安装：

npm i puppeteer-core

因此，如果你是在本地运行 puppeteer.launch()，看到“额度”“配额”“并发会话”等词，通常说明项目连接的是某个云浏览器或浏览器托管服务，而不是 npm 包本身。解决顺序应该是：

场景 需要检查的限制 优先处理方式
本地执行 Puppeteer 浏览器是否安装、运行时是否能启动 检查浏览器下载和启动错误
云端 Browser Rendering 每日浏览器时间、并发会话、每分钟请求数 关闭闲置会话，降低并发
使用 API Key 的云服务 每月请求额度、速率限制 等待月度重置，或按服务商规则调整方案

这张表的意义是避免一看到“额度用完”就去修改 Puppeteer 配置。若错误发生在 page.goto() 或云端会话创建阶段，限制通常在服务端；若发生在 puppeteer.launch() 之后打开网页之前，则要先排查本地浏览器环境。

免费层到底限制了什么

官方 limits 与定价页给出的现行额度：Workers Free 浏览器时长 10 分钟/天、并发浏览器 3 个/账户（新实例每 20 秒 1 个、浏览器空闲超时 60 秒）；Workers Paid 每月 10 小时（超出 $0.09/小时）、并发浏览器定价页口径为月均含额 10 个（超出 $2.00/个），limits 页标注单账户硬上限 200 个 —— 两页口径不同（含额 vs 硬上限），以各自页面说明为准。原补充资料（API Commons 转录文件）里的付费层数值（30 并发、每分钟 180 请求等）是脚手架默认值，与官方现行值不一致 —— 一律以官方页为准。

这些数字不是 Puppeteer 官方仓库统一规定的额度，而是该资料针对云浏览器服务的具体记录。实际使用时，至少要确认三件事：

  1. 你连接的服务是不是该资料描述的 Browser Rendering 服务。
  2. 当前账号是否真的处于 Free Tier（免费层）。
  3. 你的应用是否把“请求数”“会话数”和“浏览器运行时间”混成了一个额度概念。

如果本地脚本只是反复打开网页，但云端不断创建新的浏览器实例，最先撞到的往往是并发会话限制，而不是每月请求额度。Puppeteer 的一个 browser 可以包含多个 page（标签页），在任务允许的情况下，优先复用同一个 browser，再创建多个 page，通常比不断 launch() 更省资源。

额度耗尽时的可执行处理步骤

1. 先确认安装方式和浏览器环境

在项目目录执行：

npm i puppeteer

然后运行：

npx puppeteer browsers install

这条命令来自 Puppeteer 官方仓库 README，适用于安装脚本被现代包管理器阻止、导致浏览器没有下载的情况。安装后可以运行：

node -e "const p=require('puppeteer'); p.launch().then(async b=>{console.log('Puppeteer browser launched'); await b.close()}).catch(e=>{console.error(e.message); process.exit(1)})"

成功标志是输出 Puppeteer browser launched。如果这里就失败，问题还停留在本地浏览器、权限或系统依赖层面，不应先排查云端额度。

2. 在创建会话前读取额度

针对支持 puppeteer.limits() 的云端环境，资料中的检查方式是：

const limits = await puppeteer.limits(env.MYBROWSER);
// { remaining: 540000, total: 600000, concurrent: 2 }

这里需要替换 env.MYBROWSER 为实际使用的云端浏览器连接配置。不要把示例中的 remaining 和 total 当成固定额度，它们只是返回对象示例；真正有意义的字段是当前服务返回的剩余量、总上限和当前并发数。

更稳妥的应用流程是：

const limits = await puppeteer.limits(env.MYBROWSER);

if (!limits.allowedBrowserAcquisitions) {
  throw new Error("Rate limit reached");
}

const browser = await puppeteer.launch(env.MYBROWSER);

这段逻辑的含义是：先查询当前服务是否允许创建新的浏览器获取请求，再启动 browser。若不允许创建新会话，程序应立即停止继续堆积任务，转入等待或复用已有会话。

3. 复用会话、限制并发并正确清理

资料建议的优先顺序是：检查额度、复用会话、执行任务、成功后断开连接，出错时关闭 browser。对于短任务，可以把多个页面放进同一个 browser：

const browser = await puppeteer.launch(env.MYBROWSER);

try {
  const pages = await Promise.all([
    browser.newPage(),
    browser.newPage(),
  ]);

  await Promise.all(
    pages.map((page) => page.goto("https://example.com"))
  );
} finally {
  await browser.close();
}

这能减少重复创建云端会话，但页面数量仍要控制在服务商允许的并发范围内。最常见的误区是只写 browser.close()，却没有处理异常路径，导致脚本失败后 browser 仍占用并发名额；try/finally 可以保证无论任务是否抛错都执行清理。

4. 遇到 429 时按响应等待，不要立即重试

限速资料列出的响应码包括 429 和 503，并建议客户端遵守 Retry-After 响应头，并使用带抖动的指数退避。带抖动的指数退避，是每次等待时间逐步增加，同时加入随机偏移，避免多个任务在同一时刻再次冲击服务端。

在 Node.js 中可以把 Retry-After 转换为等待时间，并设置上限：

async function waitBeforeRetry(response: Response) {
  const retryAfter = response.headers.get("retry-after");
  const seconds = retryAfter ? Number(retryAfter) : 60;

  await new Promise((resolve) =>
    setTimeout(resolve, Math.min(seconds, 300) * 1000)
  );
}

这不是 Puppeteer 内置命令，而是根据响应头实现的重试等待逻辑。若你的云服务返回 Retry-After，优先按它等待（示例代码把等待上限设为 300 秒）；没有该响应头时，示例代码退到固定等待 60 秒 —— 上面那条”指数递增 + 随机抖动”是资料建议的更优做法，示例为求直白没有实现，需要时可自行扩展。

免费额度什么时候重置，要按限制类型判断

转录资料给出的 API Commons Rate Limits 规则是：每分钟、每秒窗口采用滑动窗口；月度额度在每个日历月开始时按 UTC 重置；免费层默认每分钟请求上限为 10、短时突发 20、月度 1000。注意出处已失效：该转录文件所在仓库已被清空（2026-11-04 实测根目录仅剩 README），这些数值是写稿时抓取的快照，需自行核对；官方现行的限流口径见 limits 页 —— 触发限流返回 429，按其 Retry-After 值退避重试。

因此，不能笼统地说“额度过几天就恢复”：

  • 每分钟请求数超限，通常应等待当前速率窗口恢复。
  • 并发会话超限，应关闭闲置 browser，而不是只等待重置。
  • 每日浏览器时间超限，需要等该日额度恢复，或者减少运行时间。
  • 月度请求额度超限，应等下个日历月开始时按 UTC 重置。

需要特别注意：这份规范文件明确标注其中部分默认值是脚手架值，不能自动等同于任何服务商的正式承诺。最终判断应优先看当前服务返回的额度对象、响应头和服务控制台状态。

升级前先排除这几种误判

报错：Session limit exceeded

资料给出的原因是并发会话过多。处理方式是关闭不用的 browser，并尽量用多个 page 代替多个 browser；如果仍无法创建会话，先查询 puppeteer.limits()，再决定等待还是复用。

报错：返回 429

这表示请求速率超限。不要立刻重复发送同一请求；读取 Retry-After，按上面给出的等待逻辑等待，并减少并发任务。

报错：返回 503

资料把 503 与限流响应一起列出，说明它可能是服务暂时不可用或达到速率限制后的响应。先按上面的等待逻辑等待，再重试；如果持续出现，检查是否存在已创建但未关闭的 browser，以及服务账号是否已经耗尽月度额度。

报错：Could not find Chrome (ver. ...) 或浏览器启动失败

这类错误不是额度问题。执行：

npx puppeteer browsers install

如果使用的是 puppeteer-core，则还要确认系统中存在可用的 Chrome 或 Firefox，并让代码通过 executablePath 指向该浏览器。

什么时候该升级方案

只有确认错误来自云服务额度，并且免费层无法满足任务时，才需要升级。升级前先看服务控制台中的当前计划、用量、并发会话和账单页；不要只看“请求数”，还要同时确认浏览器分钟数，因为免费层的每日浏览器时间可能先耗尽。

升级后做一次最小验证：创建浏览器、打开页面、关闭浏览器，再观察控制台用量是否增长。成功标志是限额查询不再显示额度为零、任务不再返回 429 或 Session limit exceeded，并且异常路径结束后没有残留会话。

如果服务方没有提供可核实的套餐名称、价格或升级按钮路径，就不能把某个具体套餐金额写成 Puppeteer 的官方价格；实际付款前应以该云服务当前控制台为准。

延伸入口与最终核验路径

最终核验顺序可以压缩成三步：先在项目目录执行 npx puppeteer browsers install 排除本地环境问题；再运行 puppeteer.limits(env.MYBROWSER) 查看服务实际额度；最后根据 429、503 或 Session limit exceeded 的具体响应，分别执行等待、复用会话或升级方案。这样能把“额度用完”和“浏览器没装好”彻底分开处理。

参考来源

# AI# 知识

评论区

0 条评论

登录后可评论。

小土豆 90 阅读