Comment fonctionne Cloudflare Challenge

Votre requête renvoie une page « Vérification de votre navigateur » au lieu du contenu attendu ? Vous venez de croiser un Cloudflare Challenge : un interstitiel plein écran qui bloque toute la page tant que le navigateur n'a pas prouvé qu'il n'est pas un robot. À ne pas confondre avec Turnstile, le widget intégré dans une page.

La distinction est concrète pour l'automatisation : une fois le challenge réussi, Cloudflare dépose un cookie cf_clearance qui débloque les requêtes suivantes — mais il est verrouillé sur votre IP et votre User-Agent. D'où la nécessité d'un proxy.

Cloudflare Challenge ou Turnstile ?

Les deux viennent de Cloudflare, mais ne se traitent pas de la même façon :

Ce qui déclenche l'affichage d'un Cloudflare Challenge

Cloudflare réagit à un faisceau de signaux. Les plus courants côté automatisation :

Le déroulement de la vérification, étape par étape

Request → Cloudflare proxy → Suspicious? → Challenge page
                                              ↓
                                    Browser verification
                                              ↓
                                    cf_clearance cookie set
                                              ↓
                                    Original page loads

1. Requête interceptée — le reverse proxy de Cloudflare inspecte la requête avant qu'elle n'atteigne le serveur d'origine.
2. Évaluation du risque — réputation de l'IP, en-têtes, empreinte TLS et comportement sont analysés en quelques millisecondes.
3. Challenge servi — si le profil paraît suspect, la page de challenge remplace la réponse attendue.
4. Vérification du navigateur — des scripts JavaScript s'exécutent pour valider l'environnement.
5. Dépôt du cookie — en cas de succès, cf_clearance est posé avec un TTL configurable.
6. Accès accordé — le navigateur recharge et reçoit enfin le contenu d'origine.

Le cookie cf_clearance et ses contraintes

Une fois le challenge franchi, le navigateur reçoit un cookie de ce type :

cf_clearance=abc123...; path=/; domain=.example.com; secure; HttpOnly; SameSite=None

Ses propriétés dictent toute votre stratégie d'automatisation :

• Durée de vie : de 15 minutes à 24 heures, au choix du propriétaire du site.
• Portée : limitée au domaine qui a émis le challenge.
• Liaison : rattaché à l'User-Agent et à l'adresse IP utilisés pendant la vérification.
• Usage : à renvoyer sur chaque requête suivante, faute de quoi un nouveau challenge est déclenché.

À retenir : changez d'IP ou d'User-Agent après la résolution, et le cookie cf_clearance devient aussitôt invalide. C'est cette contrainte qui commande tout le reste.

Pourquoi un proxy est indispensable

Le cookie cf_clearance est lié cryptographiquement à trois éléments :

• L'adresse IP — la résolution doit partir de l'IP que vous réutiliserez ensuite.
• L'User-Agent — celui de la résolution doit correspondre à vos requêtes.
• L'empreinte TLS — certaines configurations vérifient aussi les caractéristiques TLS de la connexion.

Dès qu'un de ces éléments diffère, le cookie est rejeté et le challenge réapparaît. Concrètement : si vos workers tournent sur une IP datacenter (OVHcloud, AWS eu-west-3 à Paris, Scaleway…), faites résoudre le challenge derrière un proxy résidentiel de la même région, puis réutilisez ce même proxy pour toutes les requêtes suivantes.

Résoudre un Cloudflare Challenge avec CaptchaAI

La résolution d'un Cloudflare Challenge passe obligatoirement par un proxy, puisque le cookie cf_clearance est verrouillé sur l'IP. CaptchaAI expose la méthode cloudflare_challenge sur le même couple in.php / res.php que les autres types.

Python

import requests
import time

API_KEY = "YOUR_API_KEY"

# Submit task — proxy is REQUIRED
response = requests.get("https://ocr.captchaai.com/in.php", params={
    "key": API_KEY,
    "method": "cloudflare_challenge",
    "pageurl": "https://example.com/protected-page",
    "proxy": "username:password@proxy.example.com:8080",
    "proxytype": "HTTP",
    "json": 1
})

task_id = response.json()["request"]

# Poll for result
for _ in range(60):
    time.sleep(5)
    result = requests.get("https://ocr.captchaai.com/res.php", params={
        "key": API_KEY, "action": "get", "id": task_id, "json": 1
    }).json()

    if result.get("status") == 1:
        solution = result["request"]
        # solution contains cf_clearance cookie + user_agent
        print(f"cf_clearance: {solution}")
        break

Node.js

const axios = require('axios');

async function solveCloudflareChallenge(pageurl, proxy) {
  const { data } = await axios.get('https://ocr.captchaai.com/in.php', {
    params: {
      key: 'YOUR_API_KEY',
      method: 'cloudflare_challenge',
      pageurl,
      proxy,
      proxytype: 'HTTP',
      json: 1
    }
  });

  const taskId = data.request;

  for (let i = 0; i < 60; i++) {
    await new Promise(r => setTimeout(r, 5000));
    const res = await axios.get('https://ocr.captchaai.com/res.php', {
      params: { key: 'YOUR_API_KEY', action: 'get', id: taskId, json: 1 }
    });
    if (res.data.status === 1) return res.data.request;
  }
  throw new Error('Timeout');
}

Réutiliser le cookie cf_clearance

# After getting the solution
cf_clearance = solution["cf_clearance"]
user_agent = solution["user_agent"]

# Use the SAME proxy and user agent for subsequent requests
session = requests.Session()
session.cookies.set("cf_clearance", cf_clearance, domain=".example.com")
session.headers["User-Agent"] = user_agent
session.proxies = {"https": "http://username:password@proxy.example.com:8080"}

# Now access the protected page
page = session.get("https://example.com/protected-page")
print(f"Status: {page.status_code}")

Réutilisez le même proxy et le même User-Agent qu'à la résolution : sans quoi le cookie cf_clearance est invalide.

Questions fréquentes

Pourquoi le cookie cf_clearance cesse-t-il de fonctionner après un changement de proxy ?

Il est verrouillé sur deux paramètres de la résolution, à réutiliser tels quels :

• l'adresse IP — un changement de proxy la modifie et déclenche aussitôt un nouveau challenge ;
• l'User-Agent — il doit rester strictement identique à celui de la résolution.

Faut-il un proxy résidentiel ou datacenter pour un Cloudflare Challenge ?

Privilégiez un proxy résidentiel, pour deux raisons :

• fiabilité — les IP datacenter sont justement un déclencheur fréquent de challenge ;
• cohérence géographique — choisissez-le au plus près de vos requêtes finales pour éviter les incohérences de région.

Comment distinguer un Cloudflare Challenge d'un Turnstile dans mon code ?

Le Challenge est une page entière (souvent « Just a moment… » avec une redirection JavaScript) qui vous empêche d'atteindre le HTML utile ; Turnstile est un widget <div class="cf-turnstile"> présent dans une page déjà chargée.

CaptchaAI prend-il en charge hCaptcha ou GeeTest v4 ?

Non pour hCaptcha. La prise en charge se répartit ainsi :

• pris en charge — reCAPTCHA v2/v3, Cloudflare Turnstile, Cloudflare Challenge et GeeTest v3 ;
• non pris en charge — hCaptcha et FunCaptcha (Arkose Labs) ;
• à venir — GeeTest v4.

Le cookie cf_clearance a-t-il des implications RGPD ?

C'est un cookie technique de session, pas un identifiant marketing. Traitez-le comme tel :

• journalisation minimale — ne le conservez pas sans raison ;
• durée limitée — alignez sa rétention sur vos obligations RGPD.

Guides associés

• Résoudre un Cloudflare Challenge via l'API
• Erreurs Cloudflare Challenge et correctifs
• Le fonctionnement de Cloudflare Turnstile
• Résoudre Cloudflare Turnstile via l'API