reCAPTCHA 是怎么被自动打码过掉的?原理科普
reCAPTCHA v2 / v3 打码背后是人工工厂 + 模型识别双路径。这篇讲清两代验证机制、打码服务后端长什么样、为什么 Google 明知能被打还留着,以及打码只解决一层、上游 IP / 指纹 / 行为异常照样封的现实。
你可能正在纠结
- 注册 Claude / ChatGPT 反复被"我不是机器人"弹窗卡住 · 想知道能不能自动过
- 做自动化爬公开数据 · Cloudflare 前台 Turnstile 拦得很严 · 打码服务能不能覆盖
- 听说打码能自动过 · 但不清楚它是真人工还是 AI · 后端具体怎么运作
- reCAPTCHA v2 / v3 都听过 · 不清楚两者差在哪 · 哪个更难过
- 用过 2Captcha / CapMonster · 有时候能过有时候不能 · 想搞清失败的常见原因
这篇文章会拆解:
- v2 vs v3 各自在验证什么 · 图像挑战 vs 行为打分 · 机制差异
- 打码服务后端的 2 条路径 · 人工工厂 vs AI 模型识别 · 各自成本 / 速度 / 覆盖面
- 打码解决了哪一层 · 为什么"过了 CAPTCHA 账号还是被封" · 剩下的那几层是什么
- 常见失败原因 · IP / 指纹 / 行为异常 · 各自跟 CAPTCHA 的关系
先给答案:reCAPTCHA 分 v2(点图片那种)和 v3(不弹窗、后台打分)两代。所谓"自动打码"背后走两条路径:一条是把图丢给真人打码工厂 · 几秒内人工点掉再把 token 回传;另一条是训练小模型直接识别 v2 的九宫格。v3 因为不是"选图题"而是"看你像不像人" · 打码要伪造完整行为轨迹 · 难度高一个量级。打码只解决了验证码这一层 · IP、指纹、行为异常照样会失败。
reCAPTCHA v2 和 v3 到底在验证什么
reCAPTCHA v2 就是你熟悉的那个"我不是机器人"复选框。点一下之后,可能直接过,也可能弹一个九宫格让你选红绿灯、公交车、消防栓。这一代的核心是图像识别挑战 + cookie 信号:Google 会看你之前在这个浏览器上的浏览行为、点的位置、鼠标轨迹,加上做题结果,综合给一个"是不是机器"的判断。
v3 是 2018 年之后推出的,完全不弹窗。你打开页面它就在后台跑,给你一个 0.0 到 1.0 之间的分数。分数低,平台就默认你是机器;分数高,平台放行。判断依据也不再是"你能不能选对图",而是你打开页面之后的一整套行为模式 —— 鼠标怎么动、滚动速度、点击间隔、页面上停留多久、之前有没有 Google 账号 cookie 等等。
区别到底在哪:v2 你可以"做完题就走",一次性;v3 是持续性打分,同一个 session 里前面攒的分,后面才用得到。这个差别决定了后续所有打码手段的走向。
| 项 | reCAPTCHA v2 | reCAPTCHA v3 |
|---|---|---|
| 用户体验 | 弹窗 / 九宫格 | 无感,后台跑 |
| 判断方式 | 做对题 + cookie 信号 | 行为轨迹综合打分 |
| 输出 | pass / fail | 0.0 – 1.0 分数 |
| 打码难度 | 中等 | 高一个量级 |
| 平台部署位置 | 关键动作前(注册/登录/评论) | 全页面持续采集 |
打码服务的后端到底长什么样
"自动打码"听起来像纯 AI · 其实业内真正跑得下来的是两条路径并行。
路径一:人肉打码工厂。用户端遇到验证码,把图片和 sitekey 打包发到打码平台的 API;平台把这个任务分发给后端一批打工的人 —— 通常在东南亚、南亚、东欧,几毛钱一题,7×24 有人在线;人工做完,回传答案,你的脚本拿着 token 继续走。整个过程听起来慢,实际因为并发够大,平均响应时间能压到 10-30 秒。
路径二:模型打码。九宫格题 Google 用来给自己的地图数据打标,反过来也给了打码方大量训练素材。识别红绿灯、公交车、消防栓、桥梁这类固定题库,一个 YOLO 级别的小模型就够用了。模型打码的问题在于:Google 会定期换题库、换风格、加干扰,模型要跟着更新;所以大多数打码服务是"能用模型就用模型,模型不行降级到人工",内部走一套自动路由。
v3 的情况完全不同。v3 没有"题"给你做,平台后端会养一批预热过的浏览器 profile,先在 Google 服务上刷一段时间正常浏览(Gmail、YouTube、地图搜索),攒出高分 cookie,然后把这些 cookie / token 卖给用户。这套东西跟纯打码不是一回事 —— 更像"高分账号租赁"。
另外一个细节:业内讨论时经常把 reCAPTCHA 打码和 hCaptcha、Cloudflare Turnstile、GeeTest 混着叫"打码"。它们机制其实差别不小 —— hCaptcha 更依赖图像题、Turnstile 走纯行为判断、GeeTest 有滑动 + 图像混合 —— 但打码服务基本都会一起支持 · 因为客户不在意机制差别 · 只想拿到 pass token。
为什么 Google 明知道打码存在还留着 reCAPTCHA
按常理说 · Google 完全有能力把打码服务的 IP、账号、cookie pattern 全部识别出来 —— 毕竟这些服务的调用量巨大 · 行为特征也很稳定。但 reCAPTCHA 从 2007 年做到现在 · 一直"能被打" · Google 却没有把它彻底堵死。原因很现实:
第一 · reCAPTCHA 的 KPI 从来不是"100% 挡住机器" · 是"给攻击者提高成本"。挡住 90% 的低成本自动化 · 剩下 10% 让攻击者花钱去解 —— 这已经完成了商业目标。真正需要 100% 挡的场景 · 平台会额外叠风控引擎、设备指纹、行为模型 · reCAPTCHA 只是入口层的第一道筛子。
第二,打码工厂反过来在帮 Google 干活。你可能没意识到:reCAPTCHA v2 那些九宫格题,本质上是 Google Maps、Waymo(自动驾驶)在众包标数据。谁会以最高强度、最标准化地做这些题?打码工厂里那批打工的人。他们一天要点几万道消防栓、红绿灯、人行道,标注质量比一般用户还稳定。Google 拿到的免费高质量标注数据,价值远超 reCAPTCHA 本身。
第三 · v3 让打码变成"军备升级"游戏。v3 不是选择题 · 是行为题。要打过 v3 · 你要么租高分 cookie(受制于人)· 要么自己养 profile(成本很高)。这个门槛把大多数低端刷号玩家挡在门外 · 同时留下一个"愿意付高价"的市场 —— 对 Google 来说结果是好的:低端灰产被清出去 · 高端玩家反正也不是 reCAPTCHA 一层能挡住的 · 那让风控引擎去处理。
一句话:reCAPTCHA 不是护城河 · 是税收系统。它抽的是自动化玩家的成本税 · 不是绝对挡门。
打码解决了什么 · 没解决什么
打码只解决了验证码那一层。一个海外账号能不能成 · 是至少 5-6 层信号叠加的结果:
- 网络层:你走的是住宅代理、数据中心代理还是手机 4G,平台一眼能看出来。相关阅读:3 种代理怎么选。
- 设备指纹:浏览器 UA、屏幕、字体、Canvas、WebGL 拼起来的那个"数字身份证"。相关阅读:指纹浏览器是干嘛的。
- 验证码层:你要过的这一关。打码服务就在这层。
- 号码层:注册时收码的号本身也是 signal(不同号段、不同来源在平台端权重不同)。
- 行为层:注册流程里的鼠标轨迹、停顿、拖拽、翻页速度 —— 这层现在越来越重要,连 v3 都是这层的一部分。
- 账号历史层:注册完之后的养号动作。这层跟当前注册无关,但决定了这个号能活多久。
只把第 3 层打过,前面 1、2、4、5 任何一层不干净,平台照样会失败。经常看到有人问"我明明打码成功了,为什么还是被封 / 收不到验证码 / 注册后立刻停用",答案 99% 出在其他层。
补充一点:v3 尤其如此。v3 打分低不是"打码没打过" · 很多时候是你的浏览器 profile 本身就低分 —— 一台没登陆过任何 Google 服务、cookie 是空的、user agent 又常见的浏览器 · 连题都不会给你出 · 直接给低分。这时候调打码 API 也没用 · 要修的是上游的浏览器和账号状态。做矩阵通常会把打码跟指纹、代理、账号状态一起管 · 不当孤立环节看。相关阅读:平台是怎么发现你多开的。
实操方案 · 怎么做
挑打码服务 · 按品类选而不是按名气选
市面上打码服务不下十几家,但从后端跑的东西看,基本就 3 类。你要注册的场景决定挑哪一类,不是挑名气最大的。
人工打码工厂型
后端是真人 7×24 打工,几毛钱一题。适合的场景:
- reCAPTCHA v2 九宫格(选红绿灯 / 消防栓 / 桥梁)
- hCaptcha 图像题
- 中等吞吐(每分钟几十道到几百道)
- 你的预算敏感,想按题付费
不适合:v3(v3 没题给人做)、需要极低延迟的场景(人工排队平均 10-30 秒)。
模型打码型
后端是训练好的图像识别模型,自动跑。适合的场景:
- v3 分数需求(可以配合 cookie 池 / 高分 profile 一起卖)
- 高吞吐(每秒几十上百道)
- 对延迟敏感(模型秒级返回)
- 你的预算能接受更贵一点
不适合:题库经常变的场景(模型没跟上会暴跌 pass 率)。
内置到自动化框架的 SDK 型
不是纯打码服务,而是把打码嵌到浏览器自动化框架(比如各类自动化 workflow 平台)里,你调 API 时它顺便帮你把 CAPTCHA 过掉。适合的场景:
- 你本来就在用某个自动化框架跑注册流
- 不想额外接一个打码 API 增加链路复杂度
- 愿意锁定在这个框架的生态里
不适合:你只是偶尔要过一次 CAPTCHA、没在跑规模化自动化的场景。
对接思路 · 3 步走通
通用对接步骤如下(不同服务的 endpoint / 字段名不一样 · 具体以厂商文档为准):
第一步 · 选服务、拿 API key
按上面 3 种品类判断你适合哪一类,注册对应服务的账户,拿一个 API key。
第二步 · 从目标页面抓 sitekey 和 page URL,传过去
sitekey 是 Google / hCaptcha 给这个页面签发的公开标识,一般在页面 DOM 里的 data-sitekey 属性能找到。page URL 就是你要过验证的那个页面地址。把这两个和 API key 一起 POST 到打码服务。
第三步 · 拿到返回的 token,塞回目标页面表单
打码服务后端跑完(人工 or 模型)会返回一个 token 字符串。你把这个 token 填到目标页面对应的 hidden input(通常是 g-recaptcha-response 或者类似字段),然后提交表单。目标平台后端会拿这个 token 去 Google 那边验证,验证通过就放行。
规模化跑起来后 · 失败点常见在细节 —— sitekey 抓错 / page URL 没跟当前实际域名对齐 / token 有时效性没在 2 分钟内提交 / 平台层再多套一个风控检查。
打码不是终局 · 前后还有几层
v3 分数低 90% 是浏览器 profile 的锅 · 不是打码 API 没打过。调 100 次打码 · 每次都是低分 · 不是打码坏了 · 是这台浏览器/环境本身在 Google 眼里就是可疑的:cookie 空、没登陆过 Google 服务、UA 太标准、没 YouTube 浏览史。这时候要修的是上游的浏览器 profile · 不是 API。
打码解决不了 IP + 指纹 + 行为异常。把 CAPTCHA 过了 · 平台还有 4 层信号(网络、设备、号码、行为)在同时打分。任何一层挂了 · 注册按钮点得动但账号 3 天后停用。想理解 7 层信号怎么叠加 · 看 平台是怎么发现你多开的;想看打码在整个 stack 里的位置 · 看 一次完整的海外账号注册要几层工具配合 里 L3 那一层。
打码是规模化操作的产物。规模化跑注册流才需要 API · 一次性手动过 CAPTCHA 直接点就好。
深入阅读
- 海外注册 · 4 大工具原理集群总纲 — 4 层工具原理一次看完
- 一次完整的海外账号注册要几层工具配合 — 完整注册链路 · reCAPTCHA 在哪一层
- 打码服务横评 · 5 家 CAPTCHA solver 实战对比 — 想挑具体服务(2Captcha / CapMonster / CapSolver 等)
- 批量注册海外账号 · 老司机全套 stack 一次配齐 — 从 5 号到 500 号 · 4 大工具层 + 3 档规模
想试试 dogesms
打码解决的是验证码那一层。如果你的规模化注册还卡在号码那一层 · dogesms 承接这个:
- 一次性接码 · dashboard 直接选号 · 价格按国家 live 显示
- 号池干净 · 不用担心号段被 AI 平台 blacklist
- 需要长期号(WhatsApp / Telegram 主号)走 租号服务
TG 频道 @dogesms_official 蹲人 · 里面有一群做海外注册 / 矩阵的用户 · 打码 / 号池 / 代理的坑基本都聊过。