求解后 Ticketmaster 返回 403：应检查哪些内容

api.solvethree.com 返回了 HTTP 403。

文档中所述的站点配置未激活导致的 403 适用于 reCAPTCHA。Kasada 和 TMPT 使用独立的任务类型，不需要 reCAPTCHA 站点配置。检查发送的任务请求体，并阅读 API 响应。

试试这样做： 对于 reCAPTCHA，请激活正确的站点配置。Kasada 和 TMPT 使用各自的类型及 URL，不需要该配置。如果格式正确的任务仍返回 403，请联系支持团队。

API 请求成功，但任务失败。

查看任务的 errorCode 和 error。HTTP 响应状态与任务最终失败是不同层面的错误。

试试这样做： 停止轮询该任务，并在重试前解决其报告的错误。求解失败会退款；不要反复提交未经修改的无效输入。

任务已就绪，但 Ticketmaster 返回了 HTTP 403。

检查发往 Ticketmaster 的请求。已就绪的任务包含可用的解答，但并不代表下游会接受它。

试试这样做： 检查下文所述的 URL、解答放置位置、代理和浏览器身份。仅凭目标返回的 403，无法确定是哪种防护拒绝了请求。

将任务输入与 Ticketmaster 拒绝的请求进行比较。其他 URL 的解答不能替代当前 URL 的解答，TMPT cookie 与 Kasada 请求头也不能互换。

• 对于 action 为 Event 的 TicketmasterTmptTask，使用确切的活动 URL。
• 对于 action 为 Login 的 TicketmasterTmptTask，使用登录入口 URL。
• 对于 KasadaTask，使用 www.ticketmaster.com 上预期的 HTTPS 目标 URL。这是独立 Kasada 目前支持的主机名。

如果集成需要 cookie，却创建了 Kasada 任务；或需要请求头，却创建了 TMPT 任务，请更正任务类型，而不是尝试转换其输出。如果不确定请求需要哪种输出，请参阅 TMPT 与 Kasada 对比。

检查发出的请求，而不只是传给 HTTP 客户端的变量。旧 cookie 或客户端默认值可能使请求与应用预期不同。

TMPT 已就绪，但请求被拒绝。

检查预期的 Ticketmaster 请求是否将返回值作为 tmpt cookie 携带，而不是使用旧 cookie，或将令牌放在其他字段中。

试试这样做： 将返回的原始值作为 tmpt cookie 发送。它不是 reCAPTCHA 令牌，也不是 Kasada 请求头对象。请参阅 TMPT 集成指南。

Kasada 已就绪，但请求被拒绝。

将发出的请求头与返回的完整请求头对象进行比较，查找遗漏或被覆盖的值。

试试这样做： 将返回的请求头一起应用到预期的目标请求。不要只选取其中一个请求头。请参阅 Kasada 请求头指南。

应用通过另一个代理提交请求。

将应用的出口与成功生成解答所用的代理进行比较。如果提供了 proxyCandidates，不要假定第一个候选代理就是成功的那个。

试试这样做： 使用成功的代理发送目标请求。

客户端使用自身的浏览器身份。

检查客户端默认值是否覆盖了返回的 userAgent 或 secChUa。

试试这样做： 将返回的浏览器身份与成功的代理及预期的目标 URL 配合使用。不要混用无关的用户代理或客户端提示。

如果这些检查无法解释被拒绝的原因，请联系 [email protected]，并提供：

• 任务 ID，以及 requestId（如有）。
• 产品或任务类型，以及失败时间戳。
• 返回错误的主机、其 HTTP 状态，以及任务的 errorCode 和 error（如有）。
• 目标主机名和 action：对于 TMPT，为 Event 或 Login。
• 脱敏后的响应描述，以及已完成的 URL、cookie 或请求头、代理和浏览器身份检查。

发送报告前，请移除 API 密钥、代理密码、令牌、cookie 和客户数据。