Vous avez configuré un proxy rotatif, vous envoyez dix requêtes, et chacune renvoie la même adresse de sortie. La conclusion évidente est que la rotation est cassée. Ce n’est généralement pas le cas. Dans la plupart des cas, la passerelle distribue bien de nouvelles adresses comme demandé, et quelque chose entre votre code et elle empêche que cela se produise, et le coupable le plus courant est une fonctionnalité de votre client HTTP qui existe pour accélérer les choses.
Voici les causes dans l’ordre où il vaut la peine de les vérifier, avec la solution pour chacune.
D’abord, vérifiez correctement
Avant de diagnostiquer, assurez-vous que le test lui-même est valide. Une seule requête en ligne de commande par invocation est la vérification la plus propre, car chaque exécution est un processus distinct sans état partagé :
for i in 1 2 3 4 5; do
curl -s -x customer-USERNAME:PASSWORD@p.shifter.io:443 https://ipinfo.io/json \
| python3 -c "import sys,json; print(json.load(sys.stdin)['ip'])"
doneCinq adresses différentes signifient que la rotation fonctionne et que votre application est le problème. Cinq adresses identiques signifient que c’est la configuration. Cette seule distinction fait gagner la majeure partie du temps de débogage, donc lancez ce test en premier.
Cause un : un identifiant de session dans le nom d’utilisateur
L’explication la plus simple. Si votre nom d’utilisateur contient un indicateur sid, vous avez explicitement demandé une session persistante, et le maintien de l’adresse est le comportement correct plutôt qu’un défaut.
customer-USERNAME-country-us-sid-abc123 # persistant : même IP par conception
customer-USERNAME-country-us # rotatif : nouvelle IP à chaque requêteCela concerne les personnes qui ont copié un exemple depuis la documentation, ou qui ont construit le nom d’utilisateur avec un assistant qui ajoute une session par défaut. Retirez l’indicateur sid, et le ttl avec lui puisque le TTL n’a de sens qu’associé à une session. La sémantique est expliquée dans sticky versus rotating et la documentation des sessions.
Une version plus subtile : votre identifiant de session est constant alors que vous vouliez qu’il varie. Si vous en générez un par tâche mais que la tâche exécute de nombreuses requêtes, chaque requête de cette tâche partage une adresse, ce qui est correct mais peut ne pas être ce que vous vouliez.
Cause deux : la réutilisation de connexion, celle qui piège tout le monde
C’est la réponse la plupart du temps lorsque la boucle curl ci-dessus effectue la rotation et que votre code ne le fait pas.
Les clients HTTP modernes maintiennent les connexions ouvertes et les réutilisent, car ouvrir une nouvelle connexion TCP et TLS pour chaque requête est lent. Lorsque votre client réutilise un tunnel existant vers le proxy, la requête voyage à travers la connexion déjà établie, et cette connexion a déjà une adresse de sortie attachée. La rotation se fait par connexion, pas par requête envoyée dans une connexion existante, donc un objet de session qui conserve un pool de connexions enverra fidèlement chaque requête à travers la même sortie.
La solution dépend du niveau de contrôle souhaité. Soit désactivez le keep-alive, soit forcez une nouvelle connexion par requête, soit faites en sorte que chaque requête logique utilise un client neuf.
import requests
PROXY = "http://customer-USERNAME:PASSWORD@p.shifter.io:443"
PROXIES = {"http": PROXY, "https": PROXY}
# Réutilise une connexion : même adresse de sortie pour chaque requête
s = requests.Session()
for _ in range(5):
print(s.get("https://ipinfo.io/json", proxies=PROXIES).json()["ip"])
# Nouvelle connexion par requête : rotation comme attendu
for _ in range(5):
r = requests.get("https://ipinfo.io/json", proxies=PROXIES,
headers={"Connection": "close"}, timeout=20)
print(r.json()["ip"])La même chose s’applique ailleurs : un http.Agent avec keep-alive dans Node, un HttpClient partagé dans .NET ou Java, un pool de connexions dans Go. Si votre langage dispose d’un client par défaut qui met les connexions en pool, et c’est le cas de tous, c’est la première chose à vérifier dans le code applicatif.
Il vaut la peine de le dire clairement : c’est un compromis plutôt qu’un bug. La réutilisation de connexion est plus rapide et moins coûteuse. Si votre travail nécessite véritablement une nouvelle adresse par requête, vous payez le prix d’une nouvelle connexion à chaque fois ; si ce n’est pas le cas, la réutilisation convient et est souvent préférable.
Cause trois : vous vérifiez trop vite, ou le pool est plus petit que vous le pensez pour ce filtre
Deux effets liés.
Si vous avez resserré le filtre, vers une petite ville ou un ASN spécifique, l’ensemble des adresses pouvant vous servir est bien plus petit que le pool global, donc la même adresse réapparaît légitimement plus souvent. Ce n’est pas un échec, c’est de l’arithmétique. Élargissez le filtre et la répétition disparaît.
Rappelez-vous aussi qu’un pool résidentiel est constitué de connexions réelles qui vont et viennent, donc voir une adresse deux fois sur de nombreuses requêtes est attendu plutôt que suspect. La rotation signifie que la requête suivante est sélectionnée indépendamment, pas qu’une adresse ne peut jamais réapparaître. Si vous avez besoin d’une distinction garantie pour une charge de travail, c’est une contrainte de conception à gérer dans votre propre code.
Cause quatre : quelque chose en amont met en cache
Si vous testez via un navigateur, une extension, un paramètre de proxy au niveau du système, ou un réseau d’entreprise, la requête peut ne pas passer là où vous le pensez. Les navigateurs en particulier maintiennent les connexions ouvertes de manière agressive et les réutilisent entre les onglets, donc un navigateur est le pire environnement pour vérifier la rotation. Testez d’abord en ligne de commande, puis dans votre application, et seulement ensuite dans un navigateur.
De même, si votre code définit des variables d’environnement de proxy en plus de passer une configuration explicite, l’une peut écraser l’autre et envoyer le trafic vers autre chose que la passerelle que vous avez configurée.
Cause cinq : l’adresse est la même mais la requête n’est jamais partie
Une cause brute qu’il vaut la peine d’écarter : si le proxy n’est en réalité pas utilisé, chaque requête rapporte la même adresse, à savoir la vôtre. Confirmez que l’adresse que vous voyez n’est pas celle de votre propre serveur. Si c’est le cas, la configuration du proxy n’est pas appliquée du tout, ce qui est un problème différent et il s’agit généralement d’une entrée https manquante à côté de l’entrée http, ou d’un client qui ignore le paramètre de proxy pour le schéma que vous utilisez.
Cause six : une session persistante qui n’a pas encore expiré
Si vous utilisez délibérément des sessions persistantes et vous attendez à ce qu’elles pivotent après un certain temps, rappelez-vous que l’adresse est maintenue jusqu’à l’expiration du TTL. La durée de vie par défaut est de 120 secondes sauf si vous définissez ttl explicitement. Si vous voulez une nouvelle adresse plus tôt, changez l’identifiant de session plutôt que d’attendre, puisqu’un nouvel identifiant signifie une nouvelle session.
Notez également qu’une adresse persistante peut disparaître avant son TTL si la connexion sous-jacente se coupe, puisqu’il s’agit de vraies connexions résidentielles plutôt que d’infrastructure dédiée. Persistant signifie effort maximal pour la durée demandée, pas une garantie.
Un parcours de décision rapide
Lancez la boucle curl. Si elle pivote et que votre code ne le fait pas, vous avez un problème de réutilisation de connexion, c’est-à-dire la cause deux. Si aucune des deux ne pivote, vérifiez le nom d’utilisateur pour un indicateur sid, puis confirmez que vous ne voyez pas votre propre adresse, puis élargissez tout filtre géographique restreint. Si la rotation se produit moins souvent que vous ne le souhaiteriez, mais qu’elle se produit tout de même, vous êtes face à une question de taille de pool pour ce filtre plutôt qu’à un défaut.
Pour tout le reste, le comportement environnant est documenté dans how rotation works, et si les requêtes échouent plutôt que de se répéter, why requests time out et fixing 407 errors couvrent les deux modes d’échec les plus courants.
L’essentiel à retenir
Les problèmes de rotation ne sont généralement pas des problèmes de rotation. Testez d’abord avec des processus séparés pour établir si la passerelle effectue une rotation, et si c’est le cas, regardez votre client HTTP, car la réutilisation de connexion est de loin la favorite : les requêtes envoyées dans un tunnel déjà ouvert conservent l’adresse de sortie que ce tunnel possède déjà. Ensuite, vérifiez la présence d’un indicateur sid égaré, confirmez que vous ne regardez pas votre propre adresse, et rappelez-vous qu’un filtre géographique très restreint puise dans un ensemble bien plus petit, donc les répétitions sont normales. Les sessions persistantes qui maintiennent leur adresse fonctionnent comme prévu, et changer l’identifiant vous donne immédiatement une nouvelle adresse.
Le modèle de rotation lui-même, et les indicateurs qui le contrôlent, se trouvent sur le residential proxy network, où le comportement de session est un paramètre par requête plutôt qu’un réglage de forfait, facturé per GB quelle que soit la fréquence de rotation.