flow2api 遇到人机验证报错？这几种解决办法值得一试

最近想把手头的 Google Flow 玩出点新花样，想给它接个无限画布，再顺带跑跑 Google 的 Nano 和 VEO 模型，想着这波组合拳下来，生产效率不得起飞？

想法是好的，现实却有点骨感。原版的 Google Flow 官方入口实在难用，各种限制让人头秃。于是我把目光投向了社区里蛮火的 flow2api 项目，想着转成 API 调用能省不少事。

结果刚上手就卡住了——不管选“有头”还是“无头”打码模式，系统直接甩出一个报错：Failed to obtain reCAPTCHA token。意思是人机验证这块没过去，API 调用直接被拦截。

人机验证这块，到底该怎么解？

首先得说清楚，flow2api 里的“打码”其实指的就是处理 Google 的 reCAPTCHA 验证。

目前主流的无头浏览器（比如 Puppeteer 或 Playwright 配合 flow2api 的无头模式）在遇到高级别的 reCAPTCHA v3 时，表现确实不太稳定。Google 的风控机制一直在升级，单纯靠浏览器自动化脚本去“猜”验证，很容易被判定为机器行为，导致拿不到 Token。

如果你发现无头模式一直报错，建议先尝试切回“有头模式”。虽然看着不太优雅（需要弹个浏览器窗口），但在当前的风控环境下，有人工操作痕迹或者有头浏览器模拟的真实环境，过验证的概率往往比纯无头要高。你可以试着在有头模式下运行一段时间，观察是否能稳定拿到 Token。

如果浏览器打码都挂了，还有什么招？

如果系统自带的两种模式都跑不通，或者你不想天天盯着弹窗，那可能需要借助外部力量了。

接入第三方的打码平台 这是最直接粗暴的方案。像 2Captcha、YesCaptcha 或者 Capsolver 这些服务，专门干这个的。流程也不复杂：当 flow2api 遇到验证码时，把验证码的相关参数（比如 sitekey）发给打码平台，平台那边通过人工或者AI帮你搞定，返回一个有效的 Token，你再把这个 Token 塞回请求里继续跑。这种方案的优点是成功率高，基本通吃各类验证码；缺点嘛，肯定是要花点小钱，而且增加了请求的延迟。
检查你的运行环境 有时候不是代码不行，是环境太“可疑”。如果你的服务器在云厂商（特别是 AWS、GCP 这种）的公网 IP 段，Google 可能会直接默认你是机器人。这时候搞个住宅代理 IP，或者把环境伪装得像普通家用电脑多一点，说不定不用改码就能过。

有没有其他好用的替代方案？ 如果你觉得 flow2api 的维护太折腾，或者不想在打码上浪费太多精力，不妨看看其他几个同类项目，思路都是类似的，都是把 Web 界面转 API，但实现细节可能有差异：

gpt-api-relay 类项目：这类工具有很多变种，核心是做流量转发。虽然不一定专门针对 Flow，但对于 Google 的许多 Web 服务，只要能找到对应的接口，都能通过转发的方式绕过部分前端限制。
浏览即服务（BAS）方案：如果不想自己维护无头浏览器，可以使用基于浏览器的自动化服务，通过云端提供的真实浏览器环境来操作，这种通常自带过验证的能力。

总结一下：遇到 Failed to obtain reCAPTCHA token 别慌，先切有头模式试试，不行就用 IP 池或者代理稀释一下请求特征。如果这些都搞不定，花点钱上个打码平台是目前最稳妥的“氪金”解法。毕竟，时间才是最贵的成本，先把服务跑通再说。

大家平时都是怎么搞定 Google 这一系列验证的？有没遇到过什么玄学问题？欢迎在评论区交流避坑经验。