Tous les articles

Au cœur du flag Unblocker : ce que `unblocker: true` fait réellement

Un seul flag active trois fonctions : de vrais headers de navigateur, une signature de connexion correspondante, et l'auto-décompression pour gzip et brotli. Voici son fonctionnement et son utilité.

La plupart des scrapers échouent avant même qu'un seul header ne soit lu.

Le serveur examine la signature au niveau de la connexion que votre client envoie sur le réseau et décide si vous êtes un navigateur ou une librairie client qui prétend l'être. Python requests, net/http de Go, curl basique : tous fournissent une empreinte distinctive dès qu'ils disent bonjour. Les sites qui s'en préoccupent (Datadome, Akamai, Imperva, la partie gérée de Cloudflare) ferment la connexion ou vous servent une page de challenge avant même que votre chaîne User-Agent n'ait de l'importance.

C'est ce que unblocker: true résout sur FourA. Le mois dernier, nous avons fixé les éléments qui assurent son fonctionnement fiable.

Nouveautés

unblocker: true est un flag unique sur n'importe quel appel /api/single. Activez-le et nous faisons trois choses : injecter l'ensemble de headers du navigateur, envoyer la request via un transport qui correspond à ce qu'un vrai navigateur place sur le réseau, et décompresser ce que le serveur retourne (gzip, brotli, deflate). Les deux premières sont disponibles depuis la beta. La troisième (l'auto-décompression brotli) a été déployée le 25 mars, et le travail d'épinglage des versions a suivi le lendemain pour maintenir les headers et le transport synchronisés.

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 fonctionnent en arrière-plan.

Injection de header. Nous définissons l'ensemble complet des headers du 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 librairies de détection le vérifient.

Signature de connexion. Notre transport correspond à la forme au niveau des octets d'une session de navigateur à jour : le même ordre d'extensions, les mêmes préférences de chiffrement, les mêmes particularités de handshake. Le curl standard, Python requests, et net/http de Go produisent des signatures qui sont signalées par les machines en quelques millisecondes sur les infrastructures protégées.

Auto-décompression. Quand unblocker est activé, nous définissons Accept-Encoding à gzip, deflate, br et le transport déballe le corps. Vous récupérez une chaîne décodée (ou un Buffer si vous passez returnBuffer: true). Pas de gestion manuelle de brotli, pas de décalages entre les headers et le corps quand un site choisit deflate au lieu de gzip.

Pourquoi l'épinglage de version compte

Les signatures de connexion sont liées aux versions. Les détails réseau d'un navigateur ce mois-ci ne sont pas ceux du mois dernier, et un site qui fait du fingerprinting avec précision remarquera la dérive. Nous épinglons les pièces mobiles ensemble pour que les headers, les objets navigator, et la signature de connexion rapportent tous la même version de navigateur.

Si cela semble complexe, ça l'est. Nous avons subi un décalage lors de la migration vers le monorepo en mars, quand un élément s'est mis à jour automatiquement et que le reste a été désynchronisé. La correction a nécessité deux commits : épingler la pièce mobile, et ne jamais faire confiance au gestionnaire de paquets pour garder les éléments alignés à votre place.

Impact

Lors de tests internes contre des cibles fortement surveillées (finance, voyage, e-commerce protégé), la différence entre unblocker: false et unblocker: true est la différence entre une page de challenge et un 200. Un simple curl frappant un Cloudflare géré atterrit sur un 403 du premier coup. La même URL avec unblocker: true passe car la connexion ressemble à une session de navigateur au niveau réseau.

Mais pour les sites qui ne font pas de fingerprinting (la plupart des APIs publiques, les anciens templates de CMS, tout ce qui est filtré uniquement par des rate limits IP), laisser unblocker désactivé convient et fait gagner quelques millisecondes de négociation. Utilisez-le là où vous en avez besoin.

Pour les utilisateurs avancés

Quelques modèles méritent d'être connus.

Associez unblocker à un proxy résidentiel quand la cible vérifie aussi la réputation de l'IP. Des IPs de datacenter avec une signature de connexion parfaite sont toujours signalées sur les ASNs que le site a blacklistés. Notre endpoint proxy (/api/proxy) effectue une rotation par domaine cible, donc ajouter "proxy": "residential" à la request est généralement suffisant.

Ignorez unblocker lors de l'appel d'APIs JSON qui ne se soucient pas des navigateurs. Les headers supplémentaires peuvent en fait sembler suspects pour une API qui attend un client programmatique, par exemple un backend appelant son propre microservice.

Si le site exécute des systèmes anti-bot JavaScript (challenges interactifs Turnstile, PerimeterX au plus strict, Akamai Bot Manager avec les heuristiques au maximum), unblocker seul ne suffira pas. Vous avez besoin de l'endpoint navigateur, qui exécute le challenge dans un navigateur complet. C'est un produit différent avec une tarification en crédits différente, et nous l'avons documenté dans Browser Tasks: How to Scrape JavaScript-Heavy Sites.

Et vous pouvez combiner unblocker avec le bloc validate pour rejeter les responses qui retournent techniquement 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 échecs silencieux en échecs classifiés, ce qui est important pour votre suivi de taux de réussite dans le dashboard.

Et ensuite

Les navigateurs publient une nouvelle version stable toutes les quatre semaines. Nous mettons à jour notre stack pour correspondre. Vous n'avez rien à modifier de votre côté : unblocker: true continue de pointer vers n'importe quelle version de navigateur que nous avons vérifiée de bout en bout.

Le travail le plus difficile est à venir. Le fingerprinting HTTP/3 apparaît déjà sur les anti-bots gérés, le transport QUIC est plus complexe à imiter que l'ancien transport, et la migration des ensembles de headers statiques vers une émulation vraiment dynamique commence. Les sites protégés ont commencé à vérifier l'ordre des frames HTTP/2, et l'écart entre "une librairie qui ressemble à un navigateur" et "un navigateur" va se réduire des deux côtés. Nous écrirons à ce sujet lors de son déploiement.