Un essai gratuit représente une petite quantité fixe de bande passante, et la façon dont vous la dépensez détermine si vous apprenez quelque chose ou non. L’approche courante consiste à la pointer vers un point de test qui renvoie une adresse IP, à confirmer que l’adresse change, puis à conclure que les proxies fonctionnent. Cela ne vous apprend presque rien de ce que vous deviez savoir, et c’est la raison pour laquelle on finit par acheter un plan qui déçoit sur les sites qui comptent réellement.
Un essai existe pour répondre à une seule question : est-ce que cela fonctionnera sur mes cibles, à mon volume, dans mes marchés ? Tout ce qui suit est ordonné de sorte que les réponses les plus utiles arrivent en premier, au cas où vous manqueriez de bande passante avant de manquer de curiosité.
Avant de commencer : préparez-vous pour ne pas la gaspiller
Deux minutes de préparation changent la valeur d’un essai.
Notez vos cibles réelles, les sites ou points de terminaison réels dont dépend votre projet, et incluez le plus difficile plutôt que seulement les plus faciles. Notez vos marchés réels, les pays précis et, si pertinent, les villes dont vous avez besoin. Et décidez à l’avance à quoi ressemble une réussite, par exemple quatre-vingt-dix pour cent de réponses valides sur votre cible principale depuis deux pays, car un seuil fixé au préalable vous empêche de rationaliser un résultat médiocre par la suite.
Puis mettez en place une validation des réponses avant votre première requête. C’est l’étape de préparation la plus importante, car une page de challenge, un résultat vide, un listing tronqué ou une redirection vers une page générique arrivera souvent avec un statut 200, et un test qui compte les codes de statut rapportera un succès tout en ne récoltant rien. Vérifiez la présence d’un marqueur qui n’apparaît que sur une page authentiquement bonne : un élément attendu, une longueur de contenu plausible, un champ connu dans le JSON. Les modes d’échec sont recensés dans detecting blocked or fake content.
import requests
PROXY = "http://customer-USERNAME-country-us:PASSWORD@p.shifter.io:443"
PROXIES = {"http": PROXY, "https": PROXY}
def is_valid(html):
return "product-price" in html and len(html) > 20_000 # your own marker
ok = 0
for i in range(100): # a small, honest sample
r = requests.get("https://your-real-target.example/item/123",
proxies=PROXIES, timeout=20)
if r.status_code == 200 and is_valid(r.text):
ok += 1
print(f"validated success rate: {ok}%") # not "did it return 200"Test un : taux de réussite sur vos propres cibles
C’est le test qui compte plus que tous les autres réunis, et il devrait consommer la majeure partie de votre essai.
Effectuez un échantillon significatif, une centaine de requêtes environ, contre chaque cible réelle et mesurez le taux de réussite validé plutôt que le taux HTTP. Incluez votre cible la plus défendue, car un pool qui gère les sites faciles et s’effondre sur le difficile n’est pas un pool qui résout votre problème. Si vous disposez déjà d’une configuration en place, faites passer le même échantillon à travers elle comme témoin afin de comparer plutôt que de deviner.
Surveillez le schéma où le succès commence élevé puis se dégrade au fil de l’exécution, car cela signifie généralement que votre rythme est trop agressif pour la cible plutôt que le pool est mauvais, et c’est une leçon de rythme qu’il vaut mieux apprendre pendant un essai plutôt qu’en production.
Test deux : précision géographique
Si votre projet dépend de la localisation, et c’est le cas pour la plupart, vérifiez que le pays que vous demandez est bien le pays que vous obtenez, et vérifiez chaque marché dont vous avez réellement besoin plutôt qu’un exemple pratique. Un pool peut être excellent dans une région et pauvre dans une autre, et le chiffre global d’une page marketing ne vous dit rien sur l’endroit précis où vous collectez.
Deux niveaux méritent d’être vérifiés. D’abord, est-ce que l’adresse de sortie se géolocalise dans le pays demandé, échantillonnée sur suffisamment de requêtes pour détecter une incohérence. Ensuite, et c’est plus significatif, est-ce que le site cible se comporte comme si vous étiez là-bas : devise correcte, prix locaux, catalogue régional, résultats de recherche locaux. Le second est le vrai test, car les bases de données de géolocalisation IP et l’avis propre de la cible ne concordent pas toujours, et c’est l’avis de la cible que vous payez. Si vous avez besoin d’un ciblage au niveau de la ville, vérifiez-le à cette granularité plutôt que de supposer que la précision au niveau du pays l’implique.
Test trois : le pool est-il ce qu’il prétend être
Dépensez un peu de bande passante à échantillonner les adresses de sortie et à les regrouper par organisation à laquelle elles appartiennent. Les fournisseurs d’accès internet grand public sont ce que vous voulez voir ; une part significative d’organisations d’hébergement ou de cloud indique que le pool est dilué avec de l’espace datacenter, ce qui compte car ce sont ces adresses que vos cibles traiteront comme du trafic machine. La méthode complète se trouve dans spotting datacenter IPs sold as residential, et la distinction sous-jacente se trouve dans the anatomy of a residential IP.
Pendant que vous y êtes, notez que la qualité de l’adresse est un axe distinct du type d’adresse : un pool authentiquement résidentiel mais qui a été abusé jusqu’à une mauvaise réputation attirera quand même des challenges, ce qui est exactement ce que mesure le test un vu de l’extérieur.
Test quatre : comportement des sessions
Si une partie de votre projet implique un flux à plusieurs étapes, une recherche paginée, une connexion, un contexte de localisation que vous fixez puis relisez, confirmez deux choses pendant l’essai.
Confirmez que la rotation tourne réellement lorsque vous ne spécifiez pas de session, et confirmez qu’une session persistante conserve réellement une adresse pendant la durée dont vous avez besoin. Puis exécutez de bout en bout l’une de vos séquences réelles à plusieurs étapes sur une session tenue, car un pool peut sembler correct sur des requêtes uniques et pourtant casser un flux si l’adresse change en cours de route. Si votre travail nécessite de nombreuses identités tenues simultanément, vérifiez que les sessions concurrentes se comportent indépendamment.
Test cinq : performance et consommation
Deux chiffres à noter, qui affectent tous deux le plan que vous finirez par acheter.
La latence et le débit comptent si votre travail est sensible au temps, mesurez donc les temps de réponse à travers le proxy sur vos cibles réelles plutôt que sur un point de test de vitesse, et attendez-vous à ce que le résidentiel soit plus lent qu’une connexion directe puisque le trafic emprunte un chemin plus long. Ce qui compte, c’est si c’est assez rapide pour votre tâche, pas si cela correspond à un benchmark datacenter. L’approche de mesure se trouve dans testing speed, success rate, and location accuracy.
Puis mesurez les octets par requête, qui est le chiffre qui transforme une estimation de plan en décision de plan. Multipliez votre moyenne mesurée par votre volume de requêtes mensuel attendu et vous obtenez un chiffre de bande passante réel plutôt qu’une supposition, ce qui constitue l’entrée pour estimating monthly bandwidth. Si le résultat est inconfortable, c’est aussi le moment de découvrir que récupérer un point de terminaison de données plutôt que de rendre des pages complètes vous fait descendre d’un palier, comme expliqué dans cutting proxy bandwidth costs.
Ce sur quoi ne pas dépenser un essai
Quelques éléments brûlent de la bande passante sans rien vous apprendre.
Tester contre un point de terminaison d’écho IP prouve que le proxy est connecté, ce qui est une vérification de bon sens de trente secondes plutôt qu’une évaluation. Tester uniquement des cibles faciles flatte le pool et cache la réponse dont vous aviez besoin. Faire passer un volume énorme sur une seule cible ne mesure pas la qualité et peut faire bloquer cette adresse, ce qui rend alors le pool pire qu’il ne l’est. Et juger sur une poignée de requêtes vous donne du bruit, car un échantillon de cinq requêtes ne peut pas distinguer un pool à quatre-vingt-quinze pour cent d’un pool à soixante-dix pour cent.
Une dernière chose : n’évaluez pas un fournisseur sur des affirmations de taille de pool. Un chiffre affiché n’est pas quelque chose qu’un essai peut vérifier et ce n’est pas ce qui détermine vos résultats. La densité dans vos pays et le succès sur vos cibles, voilà ce qui compte.
Une liste de vérification pour l’essai
- Préparer : cibles réelles incluant la plus difficile, marchés réels, un seuil de réussite, et une validation des réponses écrite avant la première requête.
- Mesurer le taux de réussite validé, environ une centaine de requêtes par cible, avec un témoin si vous en avez un.
- Vérifier la géographie pour chaque marché dont vous avez besoin, à la fois la localisation de sortie et le comportement de la cible.
- Échantillonner les organisations de sortie pour confirmer que le pool est authentiquement résidentiel.
- Exercer un flux réel à plusieurs étapes sur une session persistante, et confirmer la rotation sans en avoir une.
- Enregistrer la latence et les octets par requête, puis dimensionner votre plan à partir de chiffres mesurés.
Si un essai réussit les six sur vos propres cibles, la décision de plan devient de l’arithmétique plutôt qu’un acte de foi. L’ensemble complet des choix au niveau du plan se trouve dans choosing the right residential proxy plan.
L’essentiel
Un essai, c’est de la bande passante, et de la bande passante dépensée sur un point de terminaison d’écho IP répond à une question que vous n’aviez pas. Dépensez-la sur vos cibles réelles avec une validation des réponses réelle, vérifiez les marchés dont vous avez réellement besoin, vérifiez que le pool est authentiquement résidentiel, exercez un flux de session si votre travail en comporte un, et enregistrez les octets par requête pour que votre plan soit dimensionné à partir de la mesure. Fixez le seuil de réussite avant de commencer. Faites cela et vous terminerez l’essai en sachant si le produit résout votre problème, ce qui est la seule chose à laquelle sert un essai.
Si vous voulez exécuter cette liste de vérification, vous pouvez le faire sur un essai gratuit des proxies résidentiels Shifter, avec ciblage par pays et par ville, rotation par défaut, et sessions persistantes pour les flux qui en ont besoin. Une fois les chiffres obtenus, la tarification au Go fait que le plan que vous choisissez suit la bande passante que vous avez mesurée plutôt qu’une supposition.