Rotation des proxys : quand l’IP change

Rotation des proxys : quand l’IP change

La rotation des proxys change l’IP de sortie qu’un site web voit lorsqu’il reçoit votre trafic. Ce changement peut se produire à chaque nouvelle requête, après un intervalle défini ou lorsque votre application demande une autre adresse. Un déclenchement adapté permet de répartir les requêtes indépendantes entre différentes IP tout en regroupant les actions liées.

Le choix plus général entre une adresse fixe et des adresses changeantes est traité dans Proxys statiques ou rotatifs. Ici, il s’agit de comprendre ce qui déclenche un changement et ses effets sur les requêtes déjà en cours.

Qu’est-ce qui change pendant la rotation ?

Avec une passerelle rotative, l’adresse saisie dans votre logiciel peut rester identique alors que le site web voit différentes IP de sortie. Vous vous connectez au même nom d’hôte et au même port ; le service choisit la sortie utilisée pour la connexion au site web.

Par exemple, un outil de suivi des prix peut récupérer une page produit publique via 192.0.2.14 et une autre via 198.51.100.27. Il s’agit d’adresses d’exemple. L’ordinateur qui exécute cet outil n’a pas changé de connexion Internet ; les requêtes atteignent le site par des sorties différentes.

Deux décisions distinctes déterminent le résultat : quand sélectionner à nouveau une sortie et où obtenir la suivante. Une minuterie peut sélectionner un autre proxy disponible ou reconnecter un modem mobile. Le déclencheur est le même, mais l’opération et l’interruption éventuelle peuvent différer.

Rotation à chaque requête

Avec la rotation par requête, le service sélectionne une nouvelle sortie pour chaque requête qu’il peut acheminer indépendamment. Cela convient aux pages produit, aux annonces publiques ou aux recherches distinctes qui n’ont pas besoin d’une IP commune. Le mot « requête » demande ici de la prudence : pour le trafic TCP en HTTPS et en SOCKS5, la rotation s’applique généralement à l’ouverture d’une nouvelle connexion à la destination.

Imaginez que vous releviez les prix de 500 pages produit. Chaque page fournit un résultat distinct. Le service peut répartir ces requêtes entre les sorties disponibles au lieu de faire passer tout le travail par une seule adresse. Plusieurs requêtes exécutées en même temps peuvent aussi utiliser des sorties différentes.

Une application envoie trois requêtes successives à un même site web par une passerelle unique. Dans cet exemple, chaque requête ouvre une nouvelle connexion. La passerelle sélectionne les IP de sortie 192.0.2.14, 198.51.100.27 et 203.0.113.42.

Une nouvelle sélection peut renvoyer une adresse déjà utilisée. Le pool disponible est fini, et la sélection peut être aléatoire. La rotation par requête ne promet donc pas, à elle seule, 500 IP différentes pour 500 requêtes.

Une requête et une connexion sont deux choses différentes

Une application peut envoyer plusieurs requêtes HTTP sur une même connexion. Pour une connexion HTTPS ordinaire via un proxy, elle ouvre d’abord un tunnel vers la destination. Les requêtes chiffrées circulent ensuite dans ce tunnel, et le proxy transmet leurs données sans lire chaque requête.

La sortie reste donc la même pour ce tunnel. Un service annoncé comme fonctionnant par requête peut choisir une autre sortie lorsque l’application ouvre un nouveau tunnel ou une nouvelle connexion à la destination. La réutilisation du tunnel existant peut conserver l’IP précédente.

Une page de navigateur peut charger de nombreuses ressources sur plusieurs connexions, et son actualisation peut réutiliser des connexions déjà ouvertes. La rotation n’est donc pas liée à un clic, à un onglet ou au chargement complet d’une page.

Rotation à intervalle défini

Avec la rotation temporelle, l’attribution d’une IP dure pendant une période définie. À la fin de cette période, le service sélectionne à nouveau une sortie. Des requêtes liées peuvent partager l’adresse attribuée pendant cette période, à condition que la sortie reste disponible.

Supposons qu’une session commence à 10:00 pour une durée de cinq minutes. Un test ouvre un catalogue, applique un filtre et consulte la page de résultats suivante en utilisant la même sortie. À 10:05, l’attribution expire ; une nouvelle connexion après l’expiration peut recevoir une autre adresse. Les cinq minutes sont ici un exemple, pas un intervalle standard pour tous les services.

Une application utilise une passerelle avec rotation temporisée. Dans cet exemple, les requêtes 1, 2 et 3 utilisent 192.0.2.14 pendant les cinq premières minutes. Après l’expiration, les requêtes 4, 5 et 6 utilisent 198.51.100.27.

Vérifiez quand la minuterie démarre. Elle peut compter depuis la première requête d’une session ou suivre un calendrier associé à un port proxy. Si le prochain changement programmé est prévu dans une minute, commencer une tâche maintenant ne vous donne pas une période complète de cinq minutes. Un délai d’inactivité distinct peut aussi mettre fin à une attribution plus tôt.

L’intervalle s’applique généralement à une session, à un port ou à un paramètre de connexion au proxy précis. Il ne déclenche pas nécessairement la rotation de toutes les connexions d’un compte en même temps. Si plusieurs tâches ont besoin d’attributions d’IP distinctes, le service doit prendre en charge la séparation correspondante.

Le maintien d’une sortie attribuée sur plusieurs requêtes est généralement appelé session persistante. Un service rotatif peut utiliser ce mode pour conserver une adresse pendant un temps, puis effectuer une nouvelle sélection.

Rotation à la demande

Avec la rotation à la demande, vous ou votre application choisissez quand demander une autre sortie. Selon le service, la commande peut prendre la forme d’un bouton dans le tableau de bord, d’une URL de rotation ou d’une commande API. Certains services attribuent aussi une nouvelle sortie lorsque vous démarrez une autre session proxy.

Cela est utile lorsqu’une tâche comporte plusieurs étapes liées, mais une durée imprévisible. Un test peut ouvrir un formulaire, l’envoyer et attendre la page de confirmation. Il peut conserver la sortie actuelle pendant toute la séquence, puis demander une autre attribution avant de commencer le test indépendant suivant.

Trois étapes liées de la première tâche utilisent la sortie 192.0.2.14. L’application envoie une commande Change IP une fois la tâche terminée. Les étapes de la tâche suivante utilisent 198.51.100.27.

La rotation à la demande peut être automatisée : l’application envoie la commande de changement après une tâche terminée ou un nombre choisi de requêtes. « À la demande » indique qui décide du moment du changement. Cela n’exige pas qu’une personne appuie sur un bouton à chaque fois.

La portée de la commande compte aussi. Une commande peut concerner une seule session, un port proxy entier ou un modem physique partagé par plusieurs connexions. Si elle modifie l’attribution pour toutes ces connexions, les autres tâches utilisant cette ressource peuvent aussi être affectées.

Qu’advient-il d’une requête déjà en cours ?

Pour une connexion TCP ordinaire à un site web, l’IP de sortie reste un élément de cette connexion. Une requête et sa réponse utilisent la même connexion établie. La rotation ne peut pas simplement déplacer l’échange inachevé vers une autre IP de sortie.

Un service peut gérer le passage d’une attribution à l’autre de différentes manières. Il peut laisser une connexion existante se terminer sur sa sortie actuelle et appliquer la nouvelle attribution aux connexions suivantes. Il peut au contraire fermer la connexion, obligeant l’application à se reconnecter. La reconnexion d’un modem peut aussi interrompre le trafic qui le traverse.

Prenez un téléchargement qui commence juste avant une rotation temporisée. Si la connexion reste ouverte, il peut se poursuivre par l’ancienne sortie après l’expiration de la minuterie. Si la connexion est fermée, l’application doit recommencer ou reprendre le téléchargement lorsque cette fonction est prise en charge. L’intervalle de rotation ne suffit pas à indiquer le comportement d’un transfert actif.

D’où vient l’IP suivante ?

Sélection d’une autre sortie dans un pool

Un service fondé sur un pool choisit une sortie disponible. La connexion suivante peut utiliser une autre IP sur le même serveur de centre de données, un autre serveur, une connexion domestique ou un appareil mobile. Sélectionner une sortie dans un pool n’exige pas de reconnecter l’appareil qui a acheminé la requête précédente.

Lorsque des filtres géographiques ou réseau sont pris en charge, ils restreignent les sorties admissibles. Sélectionner une autre IP dans un pays n’oblige pas à changer de pays. Un choix plus restreint peut aussi réduire l’ensemble des adresses disponibles et augmenter les répétitions.

Reconnexion d’un modem mobile

Certains services de proxys mobiles effectuent la rotation en coupant puis en rétablissant la connexion de données cellulaires du modem. Le trafic sur cette connexion peut être suspendu pendant l’opération. L’opérateur détermine l’adressage public ; la reconnexion peut donc redonner la même IP publique.

D’autres services mobiles sélectionnent un autre appareil disponible dans un pool. Ce sont deux formes de rotation des proxys mobiles, mais leurs effets sur le travail en cours peuvent différer. Le seul terme « rotation mobile » ne précise pas quel mécanisme est utilisé.

Qui contrôle le changement ?

Avec une passerelle rotative, le fournisseur choisit la sortie selon le mode demandé. Votre application peut conserver la même passerelle dans ses paramètres pendant que le service gère les adresses de sortie.

Votre application peut aussi assurer elle-même la rotation d’une liste de proxys fixes. Par exemple, elle peut utiliser la première adresse pour une tâche, la deuxième pour la suivante, puis poursuivre dans la liste. Elle peut choisir dans l’ordre ou au hasard, changer après chaque requête indépendante ou conserver un proxy jusqu’à la fin d’une tâche.

Une liste de proxys statiques de centre de données ou ISP permet donc un fonctionnement avec rotation. L’IP propre à chaque proxy reste fixe ; votre logiciel change de proxy pour acheminer la connexion suivante. Cela est utile lorsque vous souhaitez contrôler vous-même l’affectation des adresses aux tâches.

Le remplacement des adresses achetées dans un abonnement est une opération distincte. Un renouvellement planifié des adresses modifie l’ensemble des IP auxquelles vous avez accès. Il ne fait pas automatiquement passer votre application de l’une à l’autre pendant son travail.

Adaptez le moment du changement à la tâche

Commencez par repérer les actions qui doivent conserver la même sortie. Placez ensuite le changement au moment où la requête ou la tâche suivante peut utiliser une autre IP.

TâcheMoment adaptéRaison
Collecter des pages produit publiques distinctesÀ chaque requête ou nouvelle connexion à la destinationChaque résultat peut être récupéré par une sortie sélectionnée séparément.
Exécuter plusieurs vérifications liées pendant une durée connueUne attribution temporisée couvrant ces vérificationsLes requêtes peuvent partager une sortie tant que l’attribution reste active.
Terminer une séquence de durée variableÀ la demande, une fois la séquence terminéeVotre application sait quand les étapes liées sont terminées.

Pour un transfert long, la gestion des connexions existantes compte davantage qu’un intervalle de rotation court. Pour plusieurs tâches simultanées, vérifiez si la commande de rotation s’applique à chaque tâche séparément ou à une ressource qu’elles partagent.

Changer d’IP n’efface ni les cookies du navigateur ni les données du compte. Un site web peut toujours associer les requêtes à la même session ou au même compte. La rotation répartit le trafic entre les sorties ; elle ne réinitialise pas toutes les restrictions et ne garantit pas la réussite d’une requête.

Vérifiez le mode choisi avec un petit test avant une exécution complète. Notez l’IP de sortie et l’heure pour les nouvelles connexions, puis répétez la vérification au passage prévu de la minuterie ou après une commande de changement. Vérifiez aussi si une connexion ouverte reste active. Ces observations permettent de déterminer si le changement réel convient à la tâche ; des IP répétées ne prouvent pas à elles seules que la rotation ne fonctionne pas.

Retour à la base de connaissances