Le taux de réussite sur une cible chute, des pages de challenge apparaissent, et la première pensée raisonnable est que vos IPs ont été bannies. Parfois, c’est exactement ça. Souvent, ce n’est pas le cas, et la différence compte, car les réponses sont opposées : l’une appelle à changer d’adresse, l’autre appelle à ralentir sans rien changer d’autre.
Il y a ensuite le point structurel qui recadre tout le problème. Sur un pool résidentiel rotatif, vous ne possédez pas les adresses, donc il n’y a pas d’adresse à réhabiliter. Récupérer signifie faire accepter la prochaine requête, et la seule façon durable d’y parvenir est de trouver ce qui a fait refuser la dernière.
D’abord, confirmez qu’il s’agit bien d’un bannissement
Quatre choses se ressemblent de l’extérieur et signifient des choses différentes.
Une limitation de débit est temporaire et concerne le rythme. Elle s’annonce généralement par un 429, parfois avec un Retry-After, et elle se résout d’elle-même si vous ralentissez. Y répondre en changeant d’adresse est l’erreur classique, car maintenir le même rythme depuis de nouvelles adresses est le schéma qui transforme une limitation en quelque chose de durable.
Un blocage est un refus visant l’adresse ou la session : une page de challenge, un 403 persistant, un interstitiel. C’est le cas où une identité neuve aide réellement.
Un blocage silencieux est le plus dangereux, car il renvoie un 200. Une page de challenge, un résultat générique, un listing tronqué ou une redirection vers une page d’atterrissage peuvent tous se parser comme des données apparentes, et un pipeline qui compte les codes de statut signalera une bonne santé tout en ne collectant rien. Si vous ne validez pas les corps de réponse, vous ne pouvez absolument pas distinguer cela d’une réussite, voir detecting blocked or fake content.
Votre propre bug vaut la peine d’être écarté tôt. Un indicateur de nom d’utilisateur malformé renvoie 407, un filtre trop étroit renvoie 502, et un changement de parseur peut faire passer de bonnes pages pour vides. Rien de tout cela n’est un bannissement.
Le test rapide : demandez la même URL depuis une route complètement différente, idéalement un pays différent, et depuis une connexion simple. Si tout échoue, la cible a des problèmes ou la forme de votre requête est incorrecte. Si seule votre route de production échoue, vous avez un véritable problème d’identité.
Ensuite, déterminez l’étendue
L’ampleur du problème indique à quelle profondeur se situe la cause.
Une session qui échoue pendant que d’autres réussissent est courant. Retirez cette session, prenez un identifiant neuf, et continuez. Sur un pool rotatif, cela arrive continuellement et ne nécessite aucune intervention au-delà du retrait automatique décrit dans building a proxy manager.
Une route qui se dégrade, c’est-à-dire une combinaison cible et pays dont le taux de réussite a chuté alors que les autres routes tiennent, pointe vers quelque chose dans la manière dont vous approchez cette cible. C’est le cas courant et intéressant, et c’est ce que couvre le reste de cet article.
Toutes les routes vers une cible qui échouent signifie que la cible a changé ses défenses ou traverse un incident, et aucune quantité de rotation n’aidera tant que vous ne changerez pas la façon dont vous regardez, pas d’où vous venez.
Toutes les cibles qui échouent à la fois n’est presque jamais un bannissement. Regardez d’abord votre propre déploiement, vos identifiants et votre réseau.
La santé au niveau des routes est ce qui rend ce diagnostic rapide plutôt que spéculatif, c’est l’argument de monitoring proxy health at scale.
La réponse immédiate
Quand une route est réellement bloquée, l’instinct est de pousser plus fort. Faites l’inverse.
Arrêtez d’envoyer vers cette route. Continuer à marteler une cible qui vous refuse aggrave le problème, gaspille de la bande passante sur des réponses inutilisables, et propage les dégâts car chaque nouvelle adresse que vous touchez se retrouve elle aussi signalée. Un disjoncteur devrait faire cela automatiquement plutôt que d’attendre une intervention humaine.
Ne relancez pas agressivement. Une tempête de tentatives contre une cible qui bloque est le moyen le plus rapide de transformer un problème étroit en problème large, c’est pourquoi les tentatives ont besoin de budgets et de classification plutôt que d’une boucle, voir retry and backoff.
Attendez. La plupart des blocages sont limités dans le temps. Un temps de repos de quelques dizaines de minutes à quelques heures fait fréquemment disparaître complètement l’état, et reprendre pendant un temps de repos redémarre l’horloge.
Changez d’identité, pas seulement d’adresse. Si le blocage a été causé par votre apparence plutôt que par votre provenance, une nouvelle adresse seule ne change rien qui compte.
Trouver la cause réelle
Les blocages viennent de quatre sources, et il vaut la peine de les vérifier dans cet ordre car c’est à peu près leur fréquence.
Le rythme. Trop de requêtes, trop régulièrement, depuis trop peu d’adresses. Un espacement parfaitement régulier est lui-même un signal, car le trafic humain est irrégulier et par rafales. La correction consiste en un taux plus bas par adresse, du jitter et une distribution plus large, voir rate limiting and throttling et les calculs de distribution dans how many proxy IPs you actually need.
La forme de la requête. Des en-têtes qui ne correspondent pas au navigateur que vous prétendez être, des client hints manquants, un Accept-Language qui contredit votre pays de sortie, ou une empreinte TLS qui indique Python alors que votre User-Agent indique Chrome. Ce sont des contradictions plutôt que des absences, et elles sont faciles à détecter, voir setting the right headers et matching geo, timezone and locale.
Le comportement. Accéder à des points d’accès dans un ordre qu’aucune personne n’emploierait, ne jamais charger ce qu’un navigateur chargerait, changer d’identité en plein flux, ou parcourir une séquence de pagination à vitesse machine. Les séquences qui n’ont de sens que pour un script ont tendance à être reconnues comme telles.
La qualité des adresses. Parfois, c’est réellement le pool : les adresses avec une mauvaise réputation attirent les challenges quel que soit votre comportement, et un pool prétendument résidentiel dilué avec de l’espace datacenter se comporte exactement comme de l’espace datacenter, voir spotting datacenter IPs sold as residential.
Si une route est bloquée et que votre rythme et la forme de vos requêtes sont tous deux défendables, c’est à ce moment-là que la qualité des adresses devient l’hypothèse principale plutôt que la première supposition.
Reprendre sans répéter le problème
Revenir maladroitement est la façon dont un blocage résolu devient récurrent.
Commencez par un canari plutôt que par le travail complet : une poignée de requêtes via une session neuve, correctement validées, pour confirmer que la cible vous accepte à nouveau. Si elles passent, montez en puissance progressivement plutôt que de reprendre au rythme précédent, car revenir immédiatement au rythme qui a causé le problème est un schéma reconnaissable en soi. Changez quelque chose avant de reprendre, que ce soit le rythme, les en-têtes, la stratégie de session ou la géographie, puisque reprendre à l’identique revient à parier que le blocage était aléatoire. Et surveillez le taux de réussite validé pendant la montée en puissance, afin de le découvrir dans les premières minutes plutôt que le lendemain matin.
Si une cible se révèle durablement hostile malgré tout cela, les options honnêtes sont de réduire l’ambition à son égard, de l’aborder différemment, ou d’accepter que cela ne vaut pas le coût, ce qui est la logique d’escalade dans scraping heavily protected sites.
L’essentiel
Distinguez d’abord les quatre cas qui se ressemblent, car une limitation de débit à laquelle on répond par une rotation empire, et un blocage silencieux compté comme une réussite est invisible. Établissez l’étendue, car une session en échec est courante, une route dégradée est une cause qui mérite d’être trouvée, et tout qui échoue à la fois relève généralement de votre propre déploiement. Quand une route est réellement bloquée, arrêtez plutôt que de pousser, ne relancez pas dedans, laissez passer un temps de repos, et changez d’identité plutôt que seulement d’adresse. Puis trouvez la cause par ordre de probabilité : rythme, forme de la requête, comportement, et seulement ensuite qualité du pool. Reprenez avec un canari et une montée en puissance progressive, après avoir changé quelque chose, et surveillez le taux de réussite validé pendant ce temps. Sur un pool rotatif, l’adresse n’a jamais été l’atout ; c’est l’accès, et l’accès se gagne en ayant l’air ordinaire.
Avoir un point de reprise propre, c’est ce que fournissent les residential proxies, un vaste pool d’adresses réelles de qualité domestique avec ciblage par pays et par ville, de sorte qu’une session retirée est remplacée plutôt que réutilisée, avec une tarification au GB qui rend une récupération disciplinée moins coûteuse qu’une récupération obstinée.