A conexão com a API e o proxy de CAPTCHA são diferentes

Application server
  -> HTTPS api.solvethree.com/v1/tasks
     Authorization: Bearer <workspace API key>
     JSON: { "site": "accounts.example.com", "action": "login", "proxy": "http://USER:PASS@PROXY:PORT" }

solvethree solves through the proxy supplied in that JSON.

Application or browser
  -> the SAME successful proxy and pinned exit
  -> intended target, with the returned token/headers/cookie and browser identity

The API key belongs on the API request, never the target request.
Putting a proxy URL in task JSON does not configure the application's HTTP client.

Seu servidor envia uma solicitação HTTPS autenticada à API solvethree. A URL do proxy vai no corpo JSON; o solvethree então usa esse proxy para a resolução. Depois, sua aplicação ou navegador faz uma solicitação separada ao destino. Nem o campo da tarefa nem uma chamada ao SDK configura automaticamente essa conexão final.

Substitua o hostname, a ação e as credenciais de proxy do exemplo pelos seus próprios valores. O site precisa de um perfil ativo disponível no seu workspace; enviar seu hostname não cria um perfil. Consulte a configuração do perfil do site.

Mantenha a chave de API do workspace no seu servidor. Envie o cabeçalho de autorização Bearer dela apenas ao host da API, inclusive ao consultar o status da tarefa. Não copie esse cabeçalho para a solicitação ao destino nem o use como autenticação de proxy.

Configure separadamente o cliente HTTP ou navegador que envia a solução. Use o proxy que teve sucesso junto com a identidade de navegador retornada em userAgent e secChUa. Não combine a solução com uma identidade de navegador, um proxy ou uma URL de destino sem relação com ela.

A mesma URL de proxy não basta se o provedor alterna o IP de saída entre conexões. Use o recurso de sessão ou fixação do provedor para que a resolução e o envio ao destino compartilhem uma saída. Um rótulo de residencial ou móvel não garante que o destino o aceitará.

Se você usa proxyCandidates, envie pelo proxy que realmente teve sucesso, não por uma entrada arbitrária da lista. Os candidatos permitem que o solvethree tente saídas alternativas; eles não configuram seu navegador nem garantem a aceitação.

Uma tarefa em ready significa que há uma solução disponível. A aceitação é um resultado separado: examine a resposta do destino à solicitação que contém essa solução.

Se seu cliente HTTP lê HTTP_PROXY ou outras configurações de proxy do ambiente, verifique se essas configurações também roteiam solicitações para api.solvethree.com. Isso pode enviar a conexão com a API por um proxy que você pretendia usar apenas para o tráfego do destino. Examine a configuração efetiva de transporte do cliente em vez de presumir que ela corresponde ao JSON da tarefa.

Configure separadamente o transporte da API e o transporte do destino. Uma configuração de proxy no ambiente não substitui o campo obrigatório da tarefa: uma solicitação reCAPTCHA ainda precisa de exatamente um entre proxy e proxyCandidates.

A solicitação à API falha antes de você receber uma tarefa.

Verifique a resposta HTTP e a rota usada pelo seu cliente de API, incluindo quaisquer configurações de proxy do ambiente.

Experimente: Trate o erro HTTP antes de ler um payload de sucesso. Corrija o roteamento indesejado da API em vez de alterar o proxy da tarefa às cegas.

Você recebe HTTP 407.

Identifique qual conexão encontrou a falha de autenticação do proxy: a conexão com a API ou uma conexão usando o proxy da tarefa.

Experimente: Corrija as credenciais desse proxy. Aplique codificação percentual aos caracteres reservados nos componentes de nome de usuário e senha, não na URL inteira.

A criação da tarefa atinge o tempo limite.

Um tempo limite excedido não comprova que a API falhou ao criar a tarefa.

Experimente: Consulte a tarefa se você tiver o ID dela. Se você forneceu um requestId, recupere-a repetindo a mesma solicitação de tarefa com esse ID antes de criar uma nova tarefa lógica.

A tarefa chega ao status failed.

Leia os campos errorCode e error dela; isso é diferente de um erro de transporte HTTP.

Experimente: Pare de consultar essa tarefa e resolva a causa informada. Não repita entradas inválidas sem alterações nem presuma que o proxy da conexão com a API causou a falha.