Voici la liste de vérification préalable pour un premier projet de proxy résidentiel : les points à confirmer, dans l’ordre qui rend chacun peu coûteux à corriger. Elle suppose que vous savez à peu près ce qu’est un proxy, et si ce n’est pas le cas, commencez par les proxies résidentiels pour débutants et revenez ensuite.
Parcourez-la dans l’ordre et vous éviterez les échecs qui coûtent habituellement plusieurs semaines à un premier projet : un plan dimensionné pour la mauvaise charge de travail, une tâche qui semble fonctionner tout en ne collectant rien, et une facture que personne n’avait prévue.
Avant d’écrire du code
1. Confirmez que vous avez réellement besoin de résidentiel. Si vos cibles n’examinent pas le trafic de près, une infrastructure moins chère fera aussi bien l’affaire. Testez d’abord une cible depuis une connexion classique puis depuis une adresse datacenter ; si les deux fonctionnent, vous vous êtes épargné la prime. La comparaison se trouve dans résidentiel contre datacenter.
2. Décidez entre rotatif ou statique. Rotatif pour la collecte en volume, adresses ISP statiques quand quelque chose doit persister, comme un compte ou une session longue. Se tromper sur ce point n’est pas rattrapable en achetant davantage de la mauvaise option, selon partagé contre dédié.
3. Dressez la liste de vos marchés. Quels pays, et si un travail nécessite une précision au niveau de la ville. Cela déterminera à la fois votre ciblage et s’il faut vérifier la profondeur du pool sur ces marchés, selon disponibilité par pays.
4. Estimez la bande passante avant de choisir un plan. Taille de la réponse multipliée par le volume de requêtes, plus une marge pour les nouvelles tentatives. Le facteur le plus déterminant est de savoir si vous récupérez des points de terminaison de données ou si vous rendez des pages complètes, ce qui peut varier d’un facteur cent, alors réglez cela en premier, selon estimer la bande passante mensuelle.
Première connexion
5. Faites fonctionner une requête nue. Aucun indicateur de ciblage, aucune session, rien de sophistiqué :
curl -x customer-USERNAME:PASSWORD@p.shifter.io:443 https://ipinfo.io/jsonSi cela échoue, rien d’autre n’a d’importance pour l’instant. Un 407 signifie des identifiants incorrects ou un nom d’utilisateur mal formé ; retirez tout et rajoutez chaque élément un par un, selon corriger les erreurs 407.
6. Confirmez la rotation. Exécutez cette commande plusieurs fois et vérifiez que l’adresse change. Si ce n’est pas le cas, et surtout si c’est le cas depuis la ligne de commande mais pas depuis votre code, la cause est presque certainement la réutilisation de connexion dans votre client HTTP plutôt que le proxy, selon l’IP ne tourne pas.
7. Confirmez la géographie. Demandez un pays et vérifiez deux choses : que l’adresse de sortie signale bien ce pays, et surtout qu’une cible sensible à la géolocalisation se comporte comme si vous étiez là, avec la devise et la langue locales. Les bases de données et l’avis propre de la cible ne concordent pas toujours, et c’est celui de la cible qui compte.
8. Configurez les deux entrées proxy et gérez les caractères spéciaux. Dans le code, configurez les entrées HTTP et HTTPS, pas seulement une, et encodez en pourcentage un mot de passe contenant des caractères qui ont une signification particulière dans une URL. La référence de format se trouve dans comment se connecter.
Avant de monter en charge
9. Faites correspondre votre requête à votre sortie. Envoyez un ensemble complet d’en-têtes de type navigateur plutôt qu’un simple User-Agent, et liez Accept-Language au pays de sortie afin que les deux ne se contredisent pas. Si vous pilotez un navigateur, réglez aussi la locale et le fuseau horaire en conséquence. Détails dans définir les bons en-têtes.
10. Validez le contenu des réponses, pas les codes de statut. C’est la vérification qui distingue un pipeline fonctionnel d’un pipeline qui collecte silencieusement rien. Définissez, pour chaque cible, un marqueur qui n’apparaît que sur une page réellement valide, et ne comptez une réponse comme réussie que si elle le passe. Une page de challenge qui renvoie 200 est l’échec le plus coûteux dans ce domaine, selon détecter un contenu bloqué ou factice.
11. Ajoutez un cadencement et des nouvelles tentatives raisonnables avant la montée en volume, pas après. Une limite de débit par cible avec un peu d’aléa, un plafond de concurrence, et une logique de nouvelle tentative qui classe les échecs plutôt que de boucler. Précisément : attendez en réponse aux signaux de limite de débit plutôt que de faire tourner les adresses pour garder le même rythme, et ne relancez jamais une erreur terminale. Voir limitation de débit et throttling et logique de nouvelle tentative.
12. Mettez en place un garde-fou de coût. Suivez les octets par requête et déclenchez une alerte bien avant l’allocation de votre plan, car la surprise typique d’un premier projet est une tâche de rendu consommant un mois de bande passante en trois jours. Les leviers se trouvent dans réduire les coûts de bande passante.
La vérification de cinq minutes
Avant de laisser quoi que ce soit tourner sans surveillance, confirmez tous les points suivants en une courte exécution :
- L’adresse de sortie n’est pas la vôtre
- Elle change entre les requêtes lorsque vous n’avez pas demandé de session
- Le pays correspond à ce que vous avez demandé, et la cible est d’accord
- Une requête délibérément mauvaise est classée comme un échec plutôt que comptée comme un succès
- Le nombre d’octets par requête correspond à peu près à votre estimation
- Une réponse de limite de débit provoque une attente plutôt qu’une nouvelle tentative immédiate
Si l’un de ces points est incorrect, corrigez-le maintenant. Chacun devient considérablement plus coûteux une fois qu’un mois de données a été construit par-dessus.
Erreurs fréquentes d’un premier projet
Quatre erreurs qui expliquent la majorité des problèmes.
Aller à pleine vitesse immédiatement. Les nouveaux pipelines sont généralement écrits pour tourner aussi vite que le code le permet, ce qui est le chemin le plus rapide vers le blocage. Démarrez lentement et augmentez délibérément.
Faire confiance aux codes de statut. Déjà évoqué plus haut, et cela vaut la peine de le répéter car c’est le point que tout le monde saute et celui qui corrompt un jeu de données en silence.
Rendre des pages qui n’avaient pas besoin d’être rendues. Vérifiez si les données sont disponibles depuis un point de terminaison sous-jacent avant d’automatiser un navigateur, selon quand vous avez besoin d’un navigateur headless.
Traiter une session persistante comme garantie. Les sessions fonctionnent au mieux sur de vraies connexions de foyers, donc un flux doit tolérer que l’adresse change en cours de séquence, selon persistant contre rotatif.
En résumé
Confirmez que vous avez réellement besoin de résidentiel, choisissez délibérément entre rotatif ou statique, dressez la liste de vos marchés, et dimensionnez la bande passante avant de choisir un plan. Ensuite, faites fonctionner une requête nue avant d’ajouter quoi que ce soit, confirmez la rotation et la géographie, et configurez les deux entrées proxy dans le code. Avant de monter en charge, faites en sorte que vos en-têtes concordent avec votre sortie, validez le contenu des réponses plutôt que les codes de statut, ajoutez un cadencement et des nouvelles tentatives classifiées, et mettez en place une alerte de coût. Effectuez la vérification de cinq minutes avant de laisser quoi que ce soit sans surveillance. Presque tous les échecs coûteux d’un premier projet correspondent à une de ces étapes sautées, et chacune est moins coûteuse à faire maintenant qu’à corriger après coup.
Le produit que ces étapes configurent, ce sont les proxies résidentiels, une passerelle unique avec ciblage par pays et par ville et sessions persistantes lorsqu’un flux en a besoin, facturée par GB afin qu’un petit premier projet reste une petite première facture.