任务已就绪，为什么 reCAPTCHA 令牌仍被拒绝？

{
  "id": "example-task",
  "status": "ready",
  "solution": {
    "token": "EXAMPLE_TOKEN",
    "userAgent": "EXAMPLE_USER_AGENT",
    "secChUa": "EXAMPLE_CLIENT_HINTS"
  }
}

在此示例中，应在目标网站要求提供 reCAPTCHA 令牌的位置提交 solution.token 的值。id 用于标识 solvethree 任务，不是令牌。也不要发送整个 solution 对象。

检查最终发出的请求，而不只是保存响应的变量。确认其中包含当前令牌，而不是空值或表单中残留的旧令牌。不要将令牌写入共享日志。

提交的令牌正确，但目标网站仍然拒绝它。

比较任务的网站主机名与受保护请求的主机名。检查是否使用了不同的子域名或环境。

试试这样做： 为预期的主机名请求令牌，并将其提交到该目标。你的工作区必须能访问目标站点的有效配置。

将为一次交互请求的令牌用于另一次交互。

将任务的 action 与此受保护请求所要求的确切 action 进行比较。

试试这样做： 使用与你正在提交的交互对应的 action。

集成使用了错误的 reCAPTCHA 版本。

检查任务请求中的 recaptchaType。其默认值为 enterprise-v3；网关也接受 v3。

试试这样做： 明确匹配目标使用的产品。对于 Enterprise v3，请使用 enterprise-v3。

经典版 reCAPTCHA 和 reCAPTCHA Enterprise 的网站响应令牌均在两分钟后过期，且只能使用一次。经典版令牌只能验证一次；Enterprise 令牌只能评估一次。应在即将发送受保护请求时求解，而不是囤积已就绪的令牌。

• 如果提交有所延迟，请检查从求解完成到发送令牌经过了多长时间。
• 如果令牌已经过验证或评估，请勿将其再次用于其他提交。
• 不要仅为在发送到目标前测试令牌，就单独执行验证或 Enterprise 评估。这样的测试可能会消耗令牌的使用次数。

求解成功，但提交时使用了其他连接。

比较求解成功时使用的代理与发送受保护请求时使用的代理。如果提供了 proxyCandidates，不要假定第一个候选代理就是成功的代理。

试试这样做： 通过求解成功时使用的代理提交。在求解与提交之间切换 IP 可能导致请求失败。

提交请求的客户端使用了自身默认的浏览器请求头。

将发出的 User-Agent 和 Sec-CH-UA 值与 solution.userAgent 和 solution.secChUa 进行比较。

试试这样做： 将返回的浏览器身份信息与求解成功时的代理配合使用。不要将令牌与无关的 user-agent 或客户端提示值混用。

同时检查目标的响应正文和 HTTP 状态码。仅凭 403 无法确定是哪项防护拒绝了请求。再次请求令牌前，请查找明确的令牌错误或主机名/action 不匹配信息。

如果能获取验证详情，请检查经典版 reCAPTCHA 的 success 结果以及返回的上下文和错误信息。对于 Enterprise，请检查令牌有效性及相关评估原因。不要认为仅凭分数就能解释拒绝原因：网站会自行决定如何使用评估结果。

如果仍无法确定原因，请联系 [email protected]，并提供任务 ID、requestId（如有使用）、产品、时间戳、目标主机名/action、HTTP 状态码或任务错误，以及经过脱敏处理的响应描述。请移除 API 密钥、代理密码、令牌、Cookie 和客户数据。