La connexion à l’API et le proxy CAPTCHA sont différents

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.

Votre serveur envoie une requête HTTPS authentifiée à l’API solvethree. L’URL du proxy est transmise dans le corps JSON ; solvethree utilise ensuite ce proxy pour la résolution. Votre application ou votre navigateur envoie ensuite une requête distincte à la cible. Ni le champ de la tâche ni un appel au SDK ne configure automatiquement cette dernière connexion.

Remplacez le nom d’hôte, l’action et les identifiants du proxy de l’exemple par vos propres valeurs. Le site doit disposer d’un profil actif accessible à votre espace de travail ; envoyer son nom d’hôte n’en crée pas. Consultez la configuration du profil de site.

Conservez la clé API de l’espace de travail sur votre serveur. Envoyez son en-tête d’autorisation Bearer uniquement à l’hôte de l’API, y compris lors de la récupération du statut d’une tâche. Ne copiez pas cet en-tête dans la requête destinée à la cible et ne l’utilisez pas pour l’authentification du proxy.

Configurez séparément le client HTTP ou le navigateur qui envoie la solution. Utilisez le proxy ayant réussi avec l’identité du navigateur renvoyée dans userAgent et secChUa. Ne combinez pas la solution avec une identité de navigateur, un proxy ou une URL cible sans rapport.

Utiliser la même URL de proxy ne suffit pas si le fournisseur change son IP de sortie entre les connexions. Utilisez sa fonction de session ou de fixation de l’IP pour que la résolution et l’envoi à la cible partagent une même sortie. Une étiquette résidentielle ou mobile ne garantit pas que la cible l’acceptera.

Si vous utilisez proxyCandidates, envoyez la solution via le proxy qui a réellement réussi, et non via une entrée arbitraire de la liste. Les candidats permettent à solvethree d’essayer d’autres sorties ; ils ne configurent pas votre navigateur et ne garantissent pas l’acceptation.

Une tâche au statut ready signifie qu’une solution est disponible. Son acceptation est un résultat distinct : examinez la réponse de la cible à la requête contenant cette solution.

Si votre client HTTP lit HTTP_PROXY ou d’autres paramètres de proxy issus de l’environnement, vérifiez si ces paramètres acheminent également les requêtes vers api.solvethree.com. Cela peut faire passer la connexion à l’API par un proxy que vous destiniez uniquement au trafic vers la cible. Examinez la configuration de transport effective du client plutôt que de supposer qu’elle correspond au JSON de la tâche.

Configurez séparément le transport vers l’API et celui vers la cible. Un paramètre de proxy dans l’environnement ne remplace pas le champ requis dans la tâche : une requête reCAPTCHA doit toujours contenir exactement l’un des deux champs proxy ou proxyCandidates.

La requête à l’API échoue avant que vous receviez une tâche.

Vérifiez la réponse HTTP et le chemin réseau utilisé par votre client API, y compris les éventuels paramètres de proxy de l’environnement.

Essayez ceci : Traitez l’erreur HTTP avant de lire le contenu d’une réponse de succès. Corrigez tout routage involontaire vers l’API plutôt que de modifier aveuglément le proxy de la tâche.

Vous recevez une réponse HTTP 407.

Identifiez la connexion qui a rencontré l’échec d’authentification du proxy : la connexion à l’API ou une connexion utilisant le proxy de la tâche.

Essayez ceci : Corrigez les identifiants de ce proxy. Encodez en pourcentage les caractères réservés dans les composants nom d’utilisateur et mot de passe, et non dans l’URL entière.

La création de la tâche dépasse le délai.

Un dépassement de délai ne prouve pas que l’API n’a pas créé la tâche.

Essayez ceci : Récupérez la tâche si vous disposez de son ID. Si vous avez fourni un requestId, récupérez-la en répétant la même requête de tâche avec cet ID avant de créer une nouvelle tâche logique.

La tâche passe à l’état failed.

Lisez ses champs errorCode et error ; il s’agit d’un problème distinct d’une erreur de transport HTTP.

Essayez ceci : Arrêtez d’interroger cette tâche et corrigez la cause signalée. Ne réessayez pas avec les mêmes entrées invalides et ne supposez pas que le proxy de la connexion à l’API a causé l’échec.