Tutorials

Configurer le proxy de l'extension CaptchaAI, étape par étape

Périmètre sûr : ce guide s'applique exclusivement à vos propres applications, à vos environnements de QA, de préproduction ou de production, ou à des systèmes pour lesquels vous disposez d'une autorisation écrite. Il ne porte ni sur l'automatisation de sites tiers, ni sur la neutralisation de protections anti-bot.

Configurer le proxy dans l'extension CaptchaAI prend deux minutes ; le garder stable en production en prend beaucoup plus. La règle tient en une phrase : traitez l'extension comme un profil de navigateur reproductible, pas comme un bouton que l'on active une fois. La plupart des incidents « côté extension » viennent d'ailleurs de la dérive du profil, pas du proxy.

Traiter l'extension CaptchaAI comme un workflow reproductible

Exemple concret : une équipe collecte des données autorisées depuis un worker OVHcloud, derrière un proxy résidentiel européen. Si le proxy est câblé au profil — et non redéfini à chaque lancement — le comportement reste identique en production comme en préproduction. Côté RGPD, minimisez les données personnelles collectées.

Préparer et isoler l'environnement

Avant d'écrire la moindre ligne, vérifiez que votre environnement de QA est isolé de la production, que la clé CaptchaAI est stockée dans un coffre ou un secret CI, et que vos endpoints internes acceptent les requêtes de test. Concrètement : un --user-data-dir dédié par profil, l'extension chargée depuis un chemin fixe et un solde vérifié en amont.

Renseigner le proxy dans l'extension

Le proxy doit vivre dans le profil, pas dans une session éphémère : attachez-le au --user-data-dir que charge l'extension, pour repartir de la même configuration à chaque lancement. Choisissez le type selon la source autorisée :

Type de proxy Quand l'utiliser
Résidentiel européen Cibles francophones sensibles à la latence (sortie eu-west-3, Paris).
Datacenter Vos propres environnements de préproduction.

Point clé : le proxy de l'extension et le contexte du navigateur qui poursuit le parcours doivent être le même. Une résolution appliquée depuis une autre sortie réseau est la première cause de rejet après coup.

Encapsuler l'appel à l'API CaptchaAI

Encapsulez l'appel dans une fonction réutilisable qui prend la sitekey et l'URL de votre propre page, retourne un token et trace la durée et le code retour. La boucle tient en trois étapes :

  1. Envoyer la tâche avec les seuls paramètres attendus par la famille de CAPTCHA.
  2. Interroger le résultat à un rythme borné, par exemple toutes les 5 secondes, plafonné à 120 secondes par tâche.
  3. Appliquer le token dans la même session que celle qui a déclenché le défi.

Vérifier le token côté serveur

Le token retourné doit être vérifié par votre propre backend avant toute opération métier : ainsi, aucune requête n'est acceptée sur la base d'un token périmé ou contrefait. Traitez tout statut différent du succès comme une erreur et journalisez la réponse complète.

Exemple : créer une tâche Turnstile en Node.js

Voici un exemple commenté qui appelle l'API pour une tâche Cloudflare Turnstile :

import fetch from 'node-fetch';

const API_KEY = process.env.CAPTCHAAI_KEY;

export async function createTurnstileTask(siteKey, pageUrl) {
  const res = await fetch('https://api.captchaai.com/createTask', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      clientKey: API_KEY,
      task: {
        type: 'TurnstileTaskProxyless',
        websiteURL: pageUrl,
        websiteKey: siteKey,
      },
    }),
  });
  const data = await res.json();
  return data.taskId;
}

Journaliser et observer chaque résolution

Instrumentez les appels CAPTCHA pour obtenir des métriques exploitables : durée d'obtention du token, code retour HTTP et identifiant de tâche. Séparez les journaux par environnement et corrélez les identifiants à votre traçage distribué (par exemple OpenTelemetry) pour rejouer un scénario complet à partir d'un seul identifiant.

Liste de contrôle avant la mise en production

  • Périmètre limité à vos propres applications ou à des sources autorisées.
  • Clé CaptchaAI dans un secret CI ou un coffre, jamais dans le code source.
  • Proxy attaché au profil de navigateur, pas à une session éphémère.
  • Durées d'appel et codes retour tracés à chaque exécution.
  • Retry idempotent en place pour les erreurs transitoires.
  • Tests rejouables et reproductibles depuis l'intégration continue.

Questions fréquentes

Faut-il un proxy résidentiel pour l'extension CaptchaAI ?

Cela dépend de la source. En préproduction, un proxy datacenter suffit ; un proxy résidentiel n'a de sens que si la cible autorisée l'exige. L'extension utilise le proxy que vous fournissez.

Le proxy renseigné dans l'extension s'applique-t-il aux résolutions ?

Oui, à condition qu'il soit attaché au profil chargé par le navigateur. Un proxy défini dans un onglet mais absent du profil du worker provoque des rejets intermittents difficiles à diagnostiquer.

Que faire si le token est refusé après la résolution ?

C'est presque toujours un problème de session : le token a été appliqué dans un contexte différent de celui qui a déclenché le défi. Gardez la résolution et l'envoi du formulaire dans le même contexte, avec le même cookie jar.

La configuration du proxy change-t-elle la facturation ?

Non. La facturation CaptchaAI se fait au thread, résolutions illimitées par thread : le plan BASIC ($15/mois, 5 threads) est le point d'entrée. Le proxy n'entre pas dans ce calcul ; seul le nombre de résolutions simultanées compte.

Guides connexes

Fiabilisez vos workflows CAPTCHA avec une approche méthodique et reproductible. – Créez votre clé CaptchaAI.

Les commentaires sont désactivés pour cet article.