C’est la question qui revient avant presque tout achat de proxys : de combien d’IP ai-je besoin ? Cela sonne comme le genre de chose qui devrait avoir un nombre pour réponse, et cela semble être le nombre qui détermine si le travail va marcher. En pratique c’est le plus souvent la mauvaise question, et les équipes qui commencent par elle achètent souvent la mauvaise chose. Ce qui décide réellement si votre scraping tourne proprement n’est pas combien d’adresses vous possédez, c’est comment vos requêtes se répartissent entre celles que vous utilisez, et si une cible donnée voit jamais assez de trafic venant d’une seule adresse pour s’en soucier.
Voici comment y penser correctement, y compris le seul cas où compter les IP est vraiment la bonne approche.
Pourquoi la question est mal posée
L’instinct de compter les IP est un reste d’un modèle de tarification plus ancien. Quand les proxys se vendaient au port ou à l’adresse statique, vous achetiez un nombre précis d’IP et ce nombre était votre capacité, donc compter avait du sens. Les réseaux résidentiels modernes ne fonctionnent pas ainsi. Vous puisez dans un grand pool partagé, vous êtes facturé sur la bande passante que vous déplacez plutôt que sur les adresses que vous touchez, et le nombre d’IP distinctes que vous finissez par utiliser est un résultat de la façon dont vous configurez la rotation, pas une quantité que vous achetez d’avance. Ce basculement, traité plus en profondeur dans l’article sur pourquoi l’ère du par-port est finie, est la raison pour laquelle “combien d’IP” ne correspond plus à rien que vous achetiez réellement.
Il y a une deuxième raison pour laquelle ce cadrage induit en erreur. Un site cible ne voit pas votre pool. Il voit les requêtes qui arrivent à sa propre porte, et se forge une opinion par adresse selon la façon dont ces requêtes se comportent. Dix mille IP ne sauveront pas un travail qui envoie tout son volume par une poignée d’entre elles, et un nombre modeste d’adresses bien réparties fera tourner confortablement un travail qu’un montage naïf ne pourrait pas. La répartition est la variable, pas l’inventaire.
Ce qui détermine réellement vos besoins
Quatre choses décident de ce dont un travail a besoin. Parcourez-les dans l’ordre et la réponse tombe.
La première est votre débit de requêtes par cible. Pas votre volume total de requêtes toutes cibles confondues, mais combien de requêtes vous envoyez à un seul site dans une fenêtre donnée, parce que les limites de débit sont appliquées par IP et par cible. La deuxième est la concurrence, c’est-à-dire combien de requêtes vous avez en vol à la fois, ce qui fixe combien d’adresses sont en usage simultané. La troisième, ce sont les exigences de session : si votre travail a besoin d’une IP maintenue pour un flux multi-étapes, ce qui est le seul cas qui devient un décompte réel. La quatrième est l’étendue géographique, parce qu’un travail couvrant de nombreux marchés a besoin que son volume soit réparti sur chacun de ces marchés plutôt que d’un grand pool concentré ailleurs, et là où le ciblage au niveau ville est en jeu, la question pertinente est la disponibilité dans cette ville, pas la taille du réseau dans son ensemble.
Le calcul approximatif pour le travail rotatif
Pour la collecte rotative ordinaire, le calcul utile n’est pas “combien d’IP existent” mais “de combien d’adresses distinctes mon volume a-t-il besoin pour rester poli sur chaque cible”.
Prenez votre débit de requêtes vers un seul site, puis divisez par le débit que vous acceptez d’envoyer depuis une seule adresse. Si un travail envoie 60 000 requêtes par heure vers une cible, et que vous voulez qu’aucune adresse n’envoie plus d’environ une requête toutes les 20 secondes vers cette cible, soit 180 par heure, alors ce volume doit être réparti sur de l’ordre de 330 adresses distinctes à tout moment donné. Changez l’une des entrées et la réponse bouge : divisez le volume par deux et il vous en faut moitié moins, ralentissez chaque adresse et il vous en faut plus. Les chiffres ici sont illustratifs, puisque chaque cible tolère un débit différent et que vous devriez ajuster à ce qu’un site précis accepte réellement, mais c’est la forme du calcul qui compte. Vous résolvez pour la répartition, et le pool doit simplement être assez grand et assez bien réparti dans vos marchés cibles pour la fournir.
C’est exactement ce que fait pour vous l’équilibrage de charge, et pourquoi les connexions concurrentes illimitées comptent plus qu’un nombre d’IP en gros titre : la contrainte qui mord est combien de requêtes une adresse envoie à un site, pas combien d’adresses existent au total. Si vous frappez de nombreuses cibles différentes, le calcul s’applique par cible, et un volume réparti sur cinquante sites est bien moins exigeant que le même volume pointé vers un seul.
Le cas où vous comptez vraiment : les sessions sticky
Il existe une situation où un nombre est véritablement la bonne réponse, et il vaut la peine d’être précis à son sujet. Quand votre travail a besoin d’une identité maintenue, une recherche multi-étapes, un flux de login, une séquence de type checkout, ou tout processus où un site suit un état à travers les requêtes, chacun de ces flux concurrents a besoin de sa propre session sticky sur sa propre IP pendant toute la durée du flux. Ici le décompte est direct : cinquante sessions simultanées signifient cinquante adresses maintenues à cet instant, et cinq cents en signifient cinq cents.
Donc la version honnête de la question n’est pas “de combien d’IP ai-je besoin” mais “de combien de sessions sticky concurrentes ai-je besoin”, ce qui est une question sur la forme de votre charge de travail plutôt que sur le réseau. Tout ce qui n’exige pas une identité maintenue devrait tourner, parce que la rotation répartit la charge automatiquement et c’est ainsi que le modèle de rotation est conçu pour être utilisé.
Pourquoi la taille brute du pool est une métrique de comparaison faible
Les fournisseurs affichent des tailles de pool, et les nombres sont assez grands pour être difficiles à comparer utilement. Trois choses comptent plus que le chiffre en gros titre.
La répartition dans vos marchés vient en premier. Un très grand pool qui est mince dans le pays ou la ville dont vous avez réellement besoin est pire pour votre travail qu’un réseau plus petit qui y est dense, donc la seule taille de pool qui compte est celle disponible là où vous collectez. La qualité vient en deuxième, puisque des adresses signalées ou surexploitées attirent des challenges et des réponses déformées quel qu’en soit le nombre, ce qui explique pourquoi la réputation d’IP affecte votre taux de succès plus directement que le volume, et pourquoi il aide de comprendre ce qu’est réellement une IP résidentielle. La disponibilité concurrente vient en troisième : ce qui est utilisable au moment où vous envoyez du trafic compte, pas un décompte cumulé de toute adresse que le réseau a jamais vue.
La conséquence pratique est que vous ne devriez pas choisir un fournisseur d’après la taille du pool. Faites tourner votre propre charge de travail sur un petit achat et mesurez-la, ce à quoi sert le guide pour tester la vitesse, le taux de succès et la précision de localisation.
Ce qu’il faut dimensionner à la place : la bande passante
Puisque vous êtes facturé sur les données déplacées plutôt que sur les adresses utilisées, le nombre qui vaut la peine d’être prévu est la bande passante. Estimez la taille de page ou de réponse pour vos cibles, multipliez par le volume que vous prévoyez de collecter, et vous avez un chiffre qui correspond à ce que vous paierez réellement, ce qui est l’approche exposée dans estimer la bande passante mensuelle. Cela rend aussi évident le plus grand levier de coût, et ce n’est pas le nombre d’IP : ne récupérer que ce dont vous avez besoin plutôt que des pages rendues entières est là où sont les économies, comme traité dans réduire les coûts de bande passante de proxy.
La configuration
Les deux modes viennent du même gateway, et la différence est un champ dans le nom d’utilisateur. Omettez un identifiant de session et chaque requête tourne, ce que la plupart de la collecte devrait faire :
import requests
# Rotating: every request exits through a different addressROTATING = "http://customer-USERNAME-country-us:PASSWORD@p.shifter.io:443"r = requests.get("https://example.com/page", proxies={"http": ROTATING, "https": ROTATING}, timeout=15)
# Sticky: one held IP per concurrent flow, counted per sessiondef sticky(session_id): url = (f"http://customer-USERNAME-country-us-sid-{session_id}:" f"PASSWORD@p.shifter.io:443") return {"http": url, "https": url}
# 50 concurrent flows means 50 distinct session identifiersfor i in range(50): proxies = sticky(f"flow{i}") # run one multi-step sequence on this held addressTournez par défaut, ne maintenez une session que là où un flux en a véritablement besoin, et laissez le pool gérer la répartition plutôt que d’essayer de gérer vous-même une liste fixe d’adresses.
Valider la réponse
Quel que soit le nombre auquel vous arrivez, c’est une hypothèse de départ, et la seule confirmation fiable est la mesure. Surveillez le taux de succès par cible et par région, parce qu’une baisse est le signal que votre débit par adresse est trop agressif pour ce site bien avant que cela devienne un trou de données, ce que vous donne la surveillance du pipeline. Quand une route se dégrade, le failover garde le travail en marche pendant que vous ajustez. Et si vous voyez des blocages, la correction est plus souvent le rythme et l’hygiène de requête que davantage d’adresses, ce qui est la substance d’éviter les blocages.
Une courte checklist
- Combien de requêtes par heure vers votre cible la plus sollicitée ? Cela, divisé par le débit par adresse que cette cible tolère, est à peu près la répartition dont vous avez besoin.
- Combien de flux concurrents ont besoin d’une identité maintenue ? C’est votre décompte de sessions sticky, et c’est le seul nombre qui vaut la peine d’être énoncé.
- De quels pays et villes avez-vous besoin, et le pool est-il dense à ces endroits plutôt que simplement grand dans l’ensemble ?
- Combien de données allez-vous déplacer ? C’est le nombre qui détermine le coût.
- Avez-vous mesuré le taux de succès sur votre propre charge de travail plutôt que de vous fier à un chiffre en gros titre ?
En résumé
“De combien d’IP ai-je besoin” est une question héritée d’un modèle de tarification qui ne s’applique plus. Sur un réseau résidentiel moderne facturé à la bande passante, vous n’achetez pas un décompte d’adresses, vous achetez l’accès à un pool et payez pour les données que vous y faites transiter, donc ce pour quoi il faut concevoir est la répartition : assez d’étalement pour qu’aucune cible isolée ne voie jamais plus qu’un trafic ordinaire venant d’une seule adresse. Tournez pour le volume, ne comptez que vos sessions sticky concurrentes, jugez un réseau par sa densité dans les marchés où vous collectez réellement et par le taux de succès qu’il délivre sur votre propre charge de travail, et dimensionnez votre budget en bande passante plutôt qu’en adresses. Réussissez la répartition et le décompte d’IP cesse d’être quelque chose à quoi vous devez penser.
C’est ce que les proxys résidentiels sont faits pour fournir, un grand pool d’IP réelles de niveau domestique avec ciblage par pays et par ville, rotation par défaut, et sessions sticky pour les flux qui en ont besoin. La tarification au Go est le nombre autour duquel il vaut la peine de planifier, parce que vous payez pour les données que vous tirez réellement plutôt que pour une quantité d’adresses dont vous espérez qu’elle suffira.