自动化验证码解决的主要方法有两种:实时拦截和解决验证码的浏览器扩展,以及以编程方式提交验证码数据的基于 API 的服务。每种方法都在速度、可扩展性和控制方面进行权衡。
快速比较
| 特征 | 浏览器扩展 | 基于 API 的求解器 |
|---|---|---|
| 设置 | 安装扩展,添加 API 密钥 | 通过 HTTP 调用集成到代码中 |
| 需要浏览器 | 是的 | 否(除非注入代币) |
| 可扩展性 | 低 — 每个实例一个浏览器 | 高——无限制的并行请求 |
| 速度 | 快速(自动检测+解决) | 取决于验证码类型(5-30 秒) |
| 控制 | 有限的 | 完全编程控制 |
| 无头支持 | 有限的 | 满的 |
| 服务器端使用 | 不 | 是的 |
| 成本 | 每个解决方案的定价相同 | 每个解决方案的定价相同 |
| 语言 | 仅限浏览器 (JavaScript) | 任何语言 |
浏览器扩展的工作原理
浏览器扩展程序监视已知验证码小部件(reCAPTCHA、Turnstile、图像验证码)的页面加载。当检测到时,它会自动提取参数,提交给解决API,并将token 提交回页面。
优点:
- 零代码设置——安装和配置
- 自动验证码检测和注入
- 像人类用户一样解决验证码
- 适用于复杂的 JavaScript 密集型网站
缺点:
- 需要可见或无头浏览器
- 一个浏览器实例 = 一次解决一个问题
- 难以大规模运行(需要许多浏览器实例)
- 扩展程序可能会被反机器人系统检测到
- 无法在没有浏览器的服务器上运行
- 有限的错误处理和重试逻辑
- 扩展更新可能会破坏功能
基于 API 的解决方案如何工作
您向解决 API 发出 HTTP 请求。提交验证码参数(站点密钥、页面 URL、图像数据),轮询结果,然后在应用程序中使用令牌 - 无需浏览器。
优点:
- 完全编程控制
- 适用于任何语言(Python、Node.js、PHP、Go 等)
- 可扩展到数千个并行求解
- 在服务器、容器、无服务器功能上运行
- 自定义错误处理、重试逻辑和监控
- 有或没有浏览器都可以使用
- 无扩展检测风险
缺点:
- 需要编码集成
- 您自己处理token 提交
- 需要手动提取sitekey和参数
何时使用浏览器扩展
| 使用案例 | 为什么扩展有效 |
|---|---|
| 偶尔使用验证码进行手动浏览 | 方便——无需代码 |
| 快速原型制作 | 在构建 API 集成之前进行测试 |
| 单浏览器任务 | 填写表格、创建帐户(少量) |
| 非开发者用户 | 无需编程 |
何时使用 API
| 使用案例 | 为什么 API 更好 |
|---|---|
| 大规模网络抓取 | 并行求解,无浏览器开销 |
| 服务器端自动化 | 没有可用的浏览器 |
| CI/CD 测试 | 无头环境 |
| 微服务 | 来自任何服务的 HTTP 调用 |
| 多验证码类型处理 | 编程类型检测和路由 |
| 自定义重试/error 处理 | 完全控制故障恢复 |
| 成本优化 | 跟踪使用情况,尽可能缓存,避免冗余解决方案 |
可扩展性比较
| 公制 | 扩大 | 应用程序编程接口 |
|---|---|---|
| 1 验证码 | 速度相同 | 速度相同 |
| 10 个并发验证码 | 需要 10 个浏览器实例 | 10 个并行 HTTP 请求 |
| 100 个并发验证码 | 不切实际 | 标准工作量 |
| 1,000+ 并发验证码 | 不可行 | 队列+工人 |
| 每个实例的 RAM | 200–500 MB(Chrome) | ~10 MB(HTTP 客户端) |
| 每个实例的CPU | 高(浏览器渲染) | 低(仅 HTTP) |
可靠性比较
| 因素 | 扩大 | 应用程序编程接口 |
|---|---|---|
| 验证码检测 | 自动(可能会错过自定义验证码) | 手动(您控制检测逻辑) |
| 错误处理 | 扩展级(有限) | 您的代码(完全控制) |
| 更新 | 扩展更新可能会破坏一些东西 | API版本化,向后兼容 |
| 浏览器崩溃 | 失去会话 | 没有浏览器崩溃 |
| 反机器人检测 | 可以检测到分机特征 | 无分机特征 |
混合方法
对于复杂的网站,将两者结合起来:使用浏览器进行导航,使用 API 进行解决。
from selenium import webdriver
import requests
import time
driver = webdriver.Chrome()
driver.get("https://staging.example.com/qa-login")
# Detect CAPTCHA
sitekey = driver.find_element("css selector", "[data-sitekey]").get_attribute("data-sitekey")
# Solve via API (not extension)
submit = requests.post("https://ocr.captchaai.com/in.php", data={
"key": "YOUR_API_KEY",
"method": "userrecaptcha",
"googlekey": sitekey,
"pageurl": driver.current_url,
"json": 1
}).json()
task_id = submit["request"]
time.sleep(15)
for _ in range(24):
result = requests.get("https://ocr.captchaai.com/res.php", params={
"key": "YOUR_API_KEY", "action": "get", "id": task_id, "json": 1
}).json()
if result.get("status") == 1:
token = result["request"]
# Inject token via JavaScript
driver.execute_script(
f'document.getElementById("g-recaptcha-response").value = "{token}";'
)
driver.find_element("css selector", "form").submit()
break
time.sleep(5)
这为您提供了 JavaScript 密集型网站的浏览器级渲染,以及用于验证码解决的 API 级控制。
常问问题
扩展和 API 之间的每次解决成本是否不同?
不会。两者都使用相同的 CaptchaAI 解决基础设施。每个验证码的成本是相同的。
我可以在无头 Chrome 中使用扩展程序吗?
技术上是可以的,但支持有限。 Headless Chrome 可以加载扩展程序,但某些验证码会检测无头模式。 API 方法对于无头环境更可靠。
扩展可以与 Selenium 或 Puppeteer 一起使用吗?
有些是这样的。您可以将该扩展加载到 Selenium 管理的浏览器中。但那时,您已经在编写代码了——API 为您提供了更多控制权,同时开销更少。
我应该从扩展还是 API 开始?
如果您正在探索或需要在 5 分钟内完成一些工作,请从扩展开始。如果您正在构建生产自动化,请从 API 开始——您最终将需要它。
获取您的 CaptchaAI API 密钥
构建可扩展的验证码解决方案验证码网站。
相关指南
- CaptchaAI 快速入门指南
- 如何使用API解决reCAPTCHA v2
- 未检测到 CaptchaAI 的 ChromeDriver
- 用于验证码解决的 Headless 与 Headed Chrome