reCAPTCHA Cookie 要求：设置内容及其重要性

很多出海团队第一次接入 reCAPTCHA 都会踩坑：同一段脚本，本地跑一次就过，换到 CI 或全新会话里却连续弹出好几轮图片验证。差别往往不在脚本逻辑，而在 cookie —— reCAPTCHA 用它判断"这台浏览器像不像真实用户"。搞清楚 reCAPTCHA 读写哪些 cookie，才能在自动化里稳定保留会话、提高识别成功率。

Cookie 状态如何决定 reCAPTCHA 挑战难度

reCAPTCHA 的风险引擎把 cookie 当作信号之一，但权重很高——同一个 sitekey，cookie 状态不同，挑战完全不同：

Cookie 打分机制

把上面的表格拆开看，reCAPTCHA 的判断大致分三档：

1. 最佳情况： 浏览器带着已登录 Google 账号的 SID、HSID、NID cookie → 往往点一下复选框就通过。
2. 较好情况： 浏览器有正常浏览积累下的 NID 和 1P_JAR → 图片挑战更简单，或者直接复选框通过。
3. 最差情况： 全新会话，没有任何 Google cookie → 大概率遇到多轮图片挑战。

reCAPTCHA 用到哪些 Cookie

再看 reCAPTCHA 具体读写哪些 cookie，方便对症保留。

Google 域下的 Cookie

以下 cookie 设置在 .google.com，由 reCAPTCHA 的 iframe 读取：

reCAPTCHA 专属 Cookie

这些 cookie 和 localStorage 键是 reCAPTCHA 自己写入的，专门服务于挑战流程：

目标站点自身的 Cookie

站点本身也可能用 cookie 做会话和 CSRF 跟踪，这部分和 Google 无关，但同样影响流程是否顺畅：

跨域限制与 Google 的应对方式

reCAPTCHA 是从 google.com 加载进 iframe 的，而现代浏览器对第三方 cookie 越来越严格：

Google 主要有三种应对方式：

• 用 recaptcha.net 作为备用域名；
• 用 localStorage（rc::* 系列键）保存客户端状态，降低对第三方 cookie 的依赖；
• 给企业客户提供第一方脚本加载方案。

国内团队测试时的坑：google.com / recaptcha.net 在大陆网络下并非始终可达，先排查连通性，再怀疑脚本逻辑。

自动化流程中如何处理 Cookie

接入方式不同，cookie 处理方式也不同，主要分两种。

浏览器自动化（Playwright / Puppeteer）

用 Playwright 或 Puppeteer 跑浏览器时，cookie 会被自动管理，你只需要在会话之间把它保存下来：

# Save cookies after session
cookies = page.context.cookies()
import json
with open("cookies.json", "w") as f:
    json.dump(cookies, f)

# Restore cookies in next session
with open("cookies.json") as f:
    cookies = json.load(f)
page.context.add_cookies(cookies)

只用 CaptchaAI API（不跑浏览器）

直接用 CaptchaAI API 识别、不经过真实浏览器时，cookie 不影响 CaptchaAI 这一侧——它用自己的求解环境处理挑战。但目标站点需要 cookie 维持会话时，可以一并传过去：

POST https://ocr.captchaai.com/in.php

key=YOUR_API_KEY
&method=userrecaptcha
&googlekey=SITE_KEY
&pageurl=https://staging.example.com/qa-login
&cookies=NID=12345;1P_JAR=2026-04-04-12

cookies 参数可选，用于把上下文传给 CaptchaAI 辅助识别。

localStorage：reCAPTCHA 的第二层状态

除了 cookie，reCAPTCHA 还把风险评估数据存进 localStorage 的 rc:: 前缀键里，这层状态不受第三方 cookie 策略影响：

这些数据帮 reCAPTCHA 在页面刷新之间保持状态，不依赖第三方 cookie。自动化流程里保留 localStorage，同样能降低挑战难度：

# Save localStorage
storage = page.evaluate("() => JSON.stringify(localStorage)")
with open("localstorage.json", "w") as f:
    f.write(storage)

# Restore localStorage
with open("localstorage.json") as f:
    storage = f.read()
page.evaluate(f"Object.entries(JSON.parse('{storage}')).forEach(([k,v]) => localStorage.setItem(k,v))")

最佳实践

• 在多次运行之间保留浏览器 profile——积累浏览历史，挑战更容易。
• 任务之间不要清空 cookie——保持 Google 风险评估的连续性。
• google.com 被拦截时改用 recaptcha.net——服务一样，换个域名而已。
• 保留 localStorage 里的 rc:: 系列键——维持 reCAPTCHA 的会话状态。
• 偶尔访问一下 Google 的产品页面——刷新 cookie 的有效性。

常见问题排查

常见问题

CaptchaAI 识别 reCAPTCHA，需要拿到我浏览器的 cookie 吗？

不需要。CaptchaAI 用自己的基础设施独立识别 reCAPTCHA，不依赖你浏览器里的 cookie，需要时可选传过去作为上下文。

NID、1P_JAR 这些 cookie 会过期吗？多久需要刷新一次？

会过期。NID 大约 6 个月有效，1P_JAR 只有约 1 个月。定期用同一个浏览器 profile 访问 Google 页面，能让这些 cookie 保持新鲜，避免每次都重新积累信任。

GeeTest（极验）和 reCAPTCHA 的 cookie 逻辑一样吗？

不完全一样。国内更常见的 GeeTest（极验）主要靠滑动轨迹、行为特征判断风险，对 cookie 依赖没有 reCAPTCHA 重；reCAPTCHA 把 Google 生态里的登录状态、历史 cookie 当作核心信号之一。这是出海团队容易忽略的差异点。

全新账号、全新浏览器第一次跑自动化，为什么总是遇到最难的挑战？

因为 reCAPTCHA 没有历史可参考——没有 Google cookie，也没有 rc:: 系列的 localStorage 记录，风险引擎只能按最谨慎的方式处理，通常给出多轮图片挑战。先让浏览器 profile 正常使用一段时间、积累 Google cookie，再跑自动化。

延伸阅读

相关主题可以接着看：如何用 API 识别 reCAPTCHA v2 回调型挑战、reCAPTCHA v2 与 Turnstile 同站点处理指南、reCAPTCHA v2 回调机制详解。

下一步

想提升 reCAPTCHA 的识别成功率？获取你的 CaptchaAI API Key，把上面这些 cookie 管理方式用到你的自动化流程里。