La conexión con la API y el proxy de CAPTCHA son 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.

Tu servidor envía una solicitud HTTPS autenticada a la API de solvethree. La URL del proxy se transmite dentro del cuerpo JSON; solvethree usa después ese proxy para la resolución. A continuación, tu aplicación o navegador realiza una solicitud independiente al destino. Ni el campo de la tarea ni una llamada al SDK configuran automáticamente esa conexión final.

Sustituye el nombre de host, la acción y las credenciales del proxy del ejemplo por tus propios valores. El sitio necesita un perfil activo disponible en tu espacio de trabajo; enviar su nombre de host no crea uno. Consulta la configuración del perfil del sitio.

Mantén la clave de API del espacio de trabajo en tu servidor. Envía su encabezado de autorización Bearer solo al host de la API, también al consultar el estado de la tarea. No copies ese encabezado a la solicitud al destino ni lo uses para autenticarte en el proxy.

Configura por separado el cliente HTTP o el navegador que envía la solución. Usa el proxy que tuvo éxito junto con la identidad del navegador devuelta en userAgent y secChUa. No combines la solución con una identidad de navegador, un proxy o una URL de destino que no le correspondan.

Usar la misma URL de proxy no basta si el proveedor rota su IP de salida entre conexiones. Usa la función de sesión o de fijación del proveedor para que la resolución y el envío al destino compartan una salida. La etiqueta de residencial o móvil no demuestra que el destino vaya a aceptarlo.

Si usas proxyCandidates, realiza el envío a través del proxy que realmente tuvo éxito, no de una entrada arbitraria de la lista. Los candidatos permiten que solvethree pruebe salidas alternativas; no configuran tu navegador ni garantizan la aceptación.

Una tarea en estado ready indica que hay una solución disponible. La aceptación es un resultado independiente: inspecciona la respuesta del destino a la solicitud que contiene esa solución.

Si tu cliente HTTP lee HTTP_PROXY u otras opciones de proxy del entorno, comprueba si esas opciones también enrutan las solicitudes a api.solvethree.com. Eso puede enviar la conexión a la API a través de un proxy que solo querías usar para el tráfico al destino. Inspecciona la configuración de transporte efectiva del cliente en lugar de suponer que coincide con el JSON de la tarea.

Configura por separado el transporte de la API y el del destino. Una opción de proxy del entorno no sustituye al campo obligatorio de la tarea: una solicitud de reCAPTCHA sigue necesitando exactamente uno de los campos proxy o proxyCandidates.

La solicitud a la API falla antes de que recibas una tarea.

Comprueba la respuesta HTTP y la ruta que usó tu cliente de API, incluidas las opciones de proxy del entorno.

Prueba esto: Gestiona el error HTTP antes de leer un cuerpo de respuesta de éxito. Corrige el enrutamiento no deseado de la API en lugar de cambiar a ciegas el proxy de la tarea.

Recibes HTTP 407.

Identifica en qué conexión se produjo el fallo de autenticación del proxy: la conexión a la API o una conexión que usa el proxy de la tarea.

Prueba esto: Corrige las credenciales de ese proxy. Codifica con porcentajes los caracteres reservados dentro de los componentes de nombre de usuario y contraseña, no la URL completa.

Se agota el tiempo de espera de la creación de la tarea.

Que se agote el tiempo de espera no demuestra que la API no haya creado la tarea.

Prueba esto: Consulta la tarea si tienes su ID. Si proporcionaste un requestId, recupérala repitiendo la misma solicitud de tarea con ese ID antes de crear una tarea lógica nueva.

La tarea pasa a failed.

Lee sus campos errorCode y error; esto es distinto de un error de transporte HTTP.

Prueba esto: Deja de consultar esa tarea y corrige la causa indicada. No reintentes con entradas no válidas sin modificarlas ni supongas que el proxy de la conexión a la API causó el fallo.