Puppeteer CAPTCHA 处理：检测、预防和云浏览器限制

Sophia Martinez

Specialist in Anti-Bot Strategies

13-Aug-2026

TL;DR:

将 CAPTCHA 视为停止信号，而不是 Puppeteer 击败的难题。 检测多个页面信号，保存诊断信息，并暂停受影响的任务。
不要只相信一个选择器。 挑战页面可以出现在 iframe、小部件容器、页面副本或特定提供者的响应字段中。
保持合法的会话状态。 重新使用授权的浏览器上下文可以减少无意的重新挑战，而无需尝试解决或逃避它们。
了解本地 Puppeteer 的停止位置。 随着工作量的增加，浏览器维护、会话隔离、代理路由和可观察性成为运营工作。
Scrapeless Scraping Browser 是云边界。 它保持 Puppeteer API，同时将浏览器基础设施和会话控制移至托管服务。

Puppeteer 对 CAPTCHA 的处理应该从检测和预防开始。如果公共页面呈现挑战，安全的自动化响应是对页面进行分类、捕捉证据，并停止或将该项转交审查。重复同样的请求通常会使信号变得更糟，并使下游系统看不到真正的失败。

本教程构建了一个小型的多信号检测器，展示了如何负责任地保存会话状态，并定义了本地 Chrome 进程何时成为运营问题。它不自动化 CAPTCHA 解决方案或推荐第三方解决服务。

在 Puppeteer 中 CAPTCHA 检测意味着什么

CAPTCHA 是一种访问控制响应，旨在区分合法交互和可疑流量。Puppeteer 可以观察到页面包含挑战，但检测并不等同于继续进行的授权。

Puppeteer 交互指南 解释了定位器和等待如何与页面状态同步。Google 的 reCAPTCHA 显示文档 记录了小部件容器和回调模型。HTTP 语义规范 也是有用的，因为挑战可以以其他正常状态代码的形式出现。

检测应结合信号，而不是假设每个挑战使用相同的标记：

已知的挑战 iframe 来源；
小部件容器，如 .g-recaptcha；
提供者响应字段；
要求验证的可见文本；
不再与请求内容匹配的页面标题或规范 URL。

安装确切的依赖项

经过验证的示例使用 Node.js、puppeteer-core 25.3.0 和已安装的 Chrome 浏览器。

bash Copy

mkdir puppeteer-captcha-check && cd puppeteer-captcha-check
pnpm init
pnpm add puppeteer-core@25.3.0

使用 puppeteer-core 使浏览器可执行文件明确。如果项目更倾向于使用 Puppeteer 附带的浏览器，请安装 puppeteer 并从启动选项中移除 executablePath。

构建一个多信号挑战检测器

下面的脚本访问 Google 的公共 reCAPTCHA 演示，等待 DOM，报告它看到的信号。它不点击或解决小部件。

javascript Copy

import puppeteer from 'puppeteer-core';

const browser = await puppeteer.launch({
  headless: true,
  executablePath: '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
});

const page = await browser.newPage();
await page.goto('https://www.google.com/recaptcha/api2/demo', {
  waitUntil: 'domcontentloaded'
});

const signals = await page.evaluate(() => {
  const findings = [];
  const iframe = document.querySelector('iframe[src*="recaptcha"], iframe[src*="captcha"]');
  if (iframe) findings.push('challenge iframe');
  if (document.querySelector('.g-recaptcha, [data-sitekey]')) findings.push('recaptcha container');
  if (document.querySelector('[name="g-recaptcha-response"]')) findings.push('response field');
  if (/verify|captcha|not a robot/i.test(document.body.innerText)) findings.push('verification copy');
  return findings;
});

console.log({
  url: page.url(),
  title: await page.title(),
  challengeDetected: signals.length > 0,
  signals
});

await browser.close();

在验证过程中，页面加载并且 challengeDetected 是 true；检测器记录了 reCAPTCHA 容器。这是预期的结果：识别页面并在提取之前停止。

将检测转变为安全控制路径

页面分类应在记录进入解析器之前进行。使用小的结果合同，如 content、challenge、unexpected_page 或 policy_review。附上请求的 URL、最终 URL、标题、时间戳和截图路径，以便操作员可以在不盲目重新运行的情况下理解故障。

当出现挑战时：

停止该任务的导航；
记录检测信号和页面身份；
保存没有敏感数据的截图或 HTML 示例；
对源应用有限的冷却时间，而不是迅速重复重新加载；
审查授权、请求速率、会话设计和目标条款。

这种方法防止挑战 HTML 被接受为产品、搜索或文章数据。

通过会话卫生减少无意的挑战

预防主要是有纪律的浏览器行为。保持一个浏览器上下文进行有限的、授权的工作流程，以便在每个页面之间不会重置 cookies、区域设置和存储。固定所需的地理位置和语言。避免打开比源合理提供更多的标签，并在同一页面不需要再次收集时缓存结果。

保持状态并不是要克服访问控制的指令。如果目标需要登录，请使用项目授权使用的帐户和自动化流程。如果挑战仍然存在，暂停并审查，而不是旋转身份直到一个通过。

本地 Puppeteer 停止的地方

本地脚本在开发和小型定时作业中表现良好。在生产规模上，团队还负责 Chrome 安装、浏览器崩溃、内存限制、进程清理、会话隔离、地理路由、屏幕截图和运行诊断。

Puppeteer 插件可以改变浏览器行为的某些部分，但它们增加了版本兼容性和维护工作。它们并不会创建访问页面的权限，也不会替代内容验证合同。

当浏览器基础设施分散了数据工作的注意力时，受管边界是有用的。Scrapeless Scraping Browser 提供了与 Puppeteer 兼容的连接，同时增加了管理会话、代理地理位置、录制和浏览器生命周期控制。

将 Puppeteer 连接到 Scrapeless Scraping Browser

先决条件： 云示例需要一个 Scrapeless 账户和一个读者拥有的 SCRAPELESS_API_KEY。SDK 导入和 Puppeteer.connect 方法在本地经过验证；本文章环境中未创建实时云会话，因为该凭证不在。

javascript Copy

import { Puppeteer } from '@scrapeless-ai/sdk';

const browser = await Puppeteer.connect({
  apiKey: process.env.SCRAPELESS_API_KEY,
  sessionName: 'public-data-check',
  sessionTTL: 180,
  proxyCountry: 'US',
  sessionRecording: true
});

const pages = await browser.pages();
const page = pages[0] || await browser.newPage();
await page.goto('https://example.com', { waitUntil: 'domcontentloaded' });
console.log(await page.title());
await browser.close();

当前的 Scrapeless Puppeteer 文档是连接选项的真实来源。在迁移到云后保持相同的挑战分类器；受管的浏览器基础设施应该改善操作，而不是移除验证。