reCAPTCHA Enterprise 站点密钥与 API 密钥：配置指南

提交 reCAPTCHA Enterprise 任务却拿不到 token，先别怀疑接口——十有八九是密钥拿错了。答案很短：CaptchaAI 只要页面里那串 6L 开头的 sitekey，AIzaSy 开头的 Google Cloud API key 一次都用不上。下面讲清该提交哪个值、怎么把它找出来、报错时往哪儿看。

sitekey 与 API key 的区别一览

sitekey：写在页面里的公开值

sitekey 直接嵌在 HTML 里，告诉浏览器加载哪一份 reCAPTCHA 配置：

<script src="https://www.google.com/recaptcha/enterprise.js?render=6LcR_RsTAAAAADge..."></script>

也可能出现在 grecaptcha.enterprise.execute 的第一个参数里：

grecaptcha.enterprise.execute('6LcR_RsTAAAAADge...', { action: 'login' });

它以 6L 开头，和标准 reCAPTCHA 前缀一致，在源码里直接可见——本来就是公开值，安全边界靠 Google Cloud Console 里的域名绑定来兜底。CaptchaAI 要的就是这个值。

API key：只在服务端露面的私有凭证

API key 用于网站后端向 Google 发起 token 校验请求：

POST https://recaptchaenterprise.googleapis.com/v1/projects/PROJECT_ID/assessments?key=AIzaSy...

特征刚好相反：AIzaSy 开头，从不出现在客户端代码里，只被网站后端用来校验 token。CaptchaAI 不需要它，也不应该拿到它。

Enterprise 和标准版 reCAPTCHA 差在哪

Enterprise 不是“更难的验证码”，它换掉的是密钥来源和校验链路：

完整校验链路：CaptchaAI 只接管前两步

把整条链路拆开看，就明白为什么只有 sitekey 与你有关。

1. 浏览器用 sitekey 加载 enterprise.js
2. 浏览器执行挑战，拿到 token
3. 网站后端把 token 和自己的 API key 一起发到 Google 的 assessments 接口
4. Google 返回风险分数和评估明细
5. 网站后端按分数决定放行还是拦截

CaptchaAI 替代第 1、2 步：用 sitekey 生成有效 token，之后是网站方的事。这也解释了为什么网站轮换 API key 与你的识别流程无关。

三种方法定位页面上的 sitekey

方法一：直接搜页面源码

在 HTML 里搜 enterprise.js：

View Source → Ctrl+F → "enterprise.js"

render 参数后面跟的就是 sitekey：

<script src="https://www.google.com/recaptcha/enterprise.js?render=6LcR_RsTAAAAADge..."></script>

顺带一眼就能确认版本：Enterprise 走 /recaptcha/enterprise.js，标准版走 /recaptcha/api.js。

方法二：浏览器控制台

在控制台里执行：

// Check for Enterprise grecaptcha
if (window.grecaptcha && window.grecaptcha.enterprise) {
  console.log('reCAPTCHA Enterprise detected');
}

// Find site key from rendered widgets
document.querySelectorAll('[data-sitekey]').forEach(el => {
  console.log('Site key:', el.getAttribute('data-sitekey'));
});

方法三：网络面板

在 Network 面板里按 enterprise.js 过滤，sitekey 会出现在请求 URL 里。源码是异步拼出来、搜不到明文时，用这一招基本都能拿到。

用 googlekey 和 enterprise=1 提交任务

拿到 sitekey 之后，用 googlekey 参数提交：

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

必填参数：

Enterprise 可选参数：

提交后按常规节奏轮询 res.php。同一把 CaptchaAI API Key 对所有支持的验证码类型通用，Enterprise 不需要额外开通；计费按并发线程走，换用 Enterprise 不改变成本结构。

出海业务里的两个落差

国内站点很少用 reCAPTCHA，主流是 GeeTest（极验）、网易易盾、腾讯防水墙。第一次撞上 Enterprise，多半是在做出海业务时：跨境电商后台、海外 SaaS 控制台、面向欧美用户的注册页。

由此带来两个落差。一是 enterprise.js 由 Google 托管，在内地网络下不一定稳定加载，但 sitekey 静态写在 HTML 里，所以方法一比方法二可靠——组件没渲染时 grecaptcha 对象不存在，控制台脚本会直接报错。

二是 staging 与生产挂在不同域名下，在 Google Cloud Console 里就是两份 sitekey，拿测试环境的密钥去生产提交必然无效。涉及数据采集时，还要先确认 robots 协议与《网络安全法》《数据安全法》和 PIPL 下的授权边界。

报错对照表

常见问题

页面里有好几个 sitekey，该提交哪一个？

以实际触发验证的那个表单为准。登录、注册、搜索组件常各绑一个 sitekey。用控制台把 data-sitekey 列出来当候选，再看提交时 enterprise.js 请求携带的 render 值。

enterprise=1 和 enterprise_type 必须一起填吗？

enterprise=1 必填，它决定任务走不走 Enterprise 通道。enterprise_type 可选，自动判断不准时才显式指定 v2 或 v3。目标是 v3 时建议同时带上 action。

token 拿到了网站还是拒绝，是 sitekey 错了吗？

不一定。Enterprise 返回的是风险分数，放行与否由网站阈值决定。先核对 pageurl 是否与表单地址一致、v3 的 action 是否对得上、token 是否在有效期内用掉。

延伸阅读

• reCAPTCHA v2 Callback 类型的识别流程
• API Key 的 IP 白名单与安全设置
• CaptchaAI API Key 轮换实践

下一步

先把目标页面的 sitekey 找出来，再注册 CaptchaAI 领取 API Key，带上 enterprise=1 提交第一个 Enterprise 任务。