La plupart des scrapers échouent avant même la lecture du moindre header.
Le serveur analyse la signature réseau transmise par votre client et détermine si vous êtes un navigateur ou une bibliothèque client qui tente de l'imiter. Python requests, net/http de Go, curl standard : tous transmettent une empreinte distinctive dès la connexion initiale. Les sites qui s'en protègent (Datadome, Akamai, Imperva, les configurations gérées de Cloudflare) coupent la connexion ou renvoient une page de challenge avant même que votre User-Agent n'entre en jeu.
C'est précisément ce que unblocker: true résout sur FourA. Au cours du dernier mois, nous avons stabilisé les composants nécessaires pour garantir un fonctionnement fiable.
Nouveautés
unblocker: true est un simple paramètre disponible sur chaque appel /api/single. Activez-le et nous effectuons trois opérations : injecter l'ensemble des headers du navigateur, router la request via un transport identique à celui d'un navigateur réel, et décompresser la response retournée par le serveur (gzip, brotli, deflate). Les deux premières fonctionnalités étaient déjà disponibles en version bêta. La troisième (la décompression automatique brotli) a été déployée le 25 mars, suivie le lendemain par l'épinglage des versions afin de maintenir une synchronisation stricte entre headers et transport.
Fonctionnement
Voici à quoi ressemble une request :
curl -X POST "https://api.foura.ai/api/single" \
-H "Content-Type: application/json" \
-H "x-api-key: YOUR_API_KEY" \
-d '{
"url": "https://example.com/products",
"method": "GET",
"unblocker": true
}'
Trois couches s'exécutent en dessous.
Injection d'en-têtes. Nous définissons l'ensemble complet des en-têtes de navigateur : User-Agent, Sec-Ch-Ua, Sec-Ch-Ua-Platform, Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-Dest, Accept, Accept-Language et Accept-Encoding. L'ordre compte. Les vrais navigateurs les émettent dans une séquence spécifique, et les bibliothèques de détection la vérifient.
Signature de connexion. Notre transport reproduit la structure au niveau de l'octet d'une session de navigateur à jour : le même ordre des extensions, les mêmes préférences de chiffrement, les mêmes particularités de handshake. Les clients standards curl, Python requests et net/http de Go produisent des signatures qui sont automatiquement signalées en quelques millisecondes sur les infrastructures protégées.
Décompression automatique. Quand unblocker est activé, nous définissons Accept-Encoding sur gzip, deflate, br et le transport décompresse le corps. Vous récupérez une chaîne décodée (ou un Buffer si vous passez returnBuffer: true). Aucune gestion manuelle de brotli, aucune incohérence entre en-têtes et corps lorsqu'un site choisit deflate plutôt que gzip.
Pourquoi le verrouillage de version est essentiel
Les signatures de connexion sont liées à une version précise. Les détails réseau d'un navigateur ce mois-ci ne sont pas ceux du mois dernier, et un site qui effectue un fingerprinting précis remarquera l'écart. Nous verrouillons ensemble les composants variables afin que les en-têtes, les objets navigator et la signature de connexion signalent tous la même version de navigateur.
Si cela semble méticuleux, ça l'est. Nous avons été confrontés à une divergence lors de la migration du monorepo en mars lorsqu'un composant s'est mis à jour automatiquement et que le reste s'est désynchronisé. Le correctif a nécessité deux commits : verrouiller le composant variable et ne jamais faire confiance au gestionnaire de paquets pour maintenir l'alignement à votre place.
Impact
Lors de tests internes sur des sites qui vérifient l'émetteur de la requête (finance, voyage, grands sites e-commerce), la différence entre unblocker: false et unblocker: true est la différence entre une page de défi et un code 200. Un client HTTP classique reçoit souvent un 403 dès la première tentative. La même URL avec unblocker: true obtient la page, car la requête ressemble au navigateur qu'elle décrit.
Mais pour les sites qui n'utilisent pas de fingerprinting (la plupart des API publiques, les anciens modèles de CMS, tout ce qui est uniquement limité par des rate limits sur l'IP), laisser unblocker désactivé convient parfaitement et économise quelques millisecondes de négociation. Utilisez-le là où vous en avez besoin.
Pour les utilisateurs avancés
Quelques modèles utiles à connaître.
Associez unblocker à un proxy résidentiel lorsque la cible vérifie également la réputation de l'IP. Des IP de datacenter combinées à une signature de connexion parfaite se font toujours repérer sur les ASN que le site a mis sur liste noire. Notre endpoint proxy (/api/proxy) applique une rotation par domaine cible, donc ajouter "proxy": "residential" à la requête suffit généralement.
Ignorez unblocker lors de l'appel d'API JSON qui ne se soucient pas des navigateurs. Les en-têtes supplémentaires peuvent en réalité paraître suspects pour une API qui attend un client programmatique, par exemple un backend appelant son propre microservice.
Si le site vérifie le visiteur avec JavaScript avant d'afficher la page, unblocker seul ne suffira pas. Vous avez besoin de l'endpoint browser, qui exécute le JavaScript de la page dans un navigateur complet. C'est un produit différent avec une tarification en crédits distincte, détaillée dans Browser Tasks : Comment scraper les sites riches en JavaScript.
Et vous pouvez combiner unblocker avec le bloc validate pour rejeter les réponses qui renvoient techniquement un code 200 mais contiennent une page de challenge :
{
"url": "https://example.com/products",
"method": "GET",
"unblocker": true,
"validate": {
"data": { "fail": ["captcha", "Access Denied"] }
}
}
Cela transforme les echecs silencieux en echecs classifies, ce qui est essentiel pour le suivi de votre taux de succes dans le dashboard.
Et ensuite ?
Les navigateurs publient une nouvelle version stable toutes les quatre semaines. Nous mettons a jour notre stack en consequence. Vous n'avez rien a modifier de votre cote : unblocker: true continue de pointer vers la version du navigateur que nous avons validee de bout en bout.
Le travail le plus complexe reste a venir. Les verifications HTTP/3 apparaissent deja sur les sites a fort trafic, le transport QUIC est plus difficile a reproduire que l'ancien transport, et la transition des bundles de headers statiques vers une emulation reellement dynamique a commence. Les sites proteges verifient desormais l'ordre des trames HTTP/2, et l'ecart entre une "bibliotheque qui ressemble a un navigateur" et "un navigateur" va se reduire des deux cotes. Nous publierons un article des que ce sera deploye.