Comment utiliser les proxys tournantsPar requête vs sessions collantes, en code

Un proxy tournant est un seul hôte et port qui vous attribue une adresse IP de sortie différente au fil du temps, de sorte qu'un scraper qui envoie mille requêtes ne les envoie pas toutes depuis une adresse que la cible peut limiter en débit et bloquer. Vous pointez votre client HTTP vers l'endpoint tournant plutôt que vers le site, et la rotation se produit en arrière-plan. C'est tout le mécanisme. Tout le reste (par requête ou session collante, résidentiel ou datacenter, construire ou acheter) est un choix ajouté par-dessus.

Ce guide est la version pratique. Il couvre la seule décision qui change réellement votre code : faire tourner une nouvelle IP à chaque requête ou conserver une IP sur une session, montre un exemple Python fonctionnel pour chacune, puis dit clairement quand pointer vers un endpoint tournant géré l'emporte sur l'assemblage et la gestion de votre propre pool. Si vous souhaitez savoir ce qu'est un proxy, what is a proxy server couvre la couche d'indirection sur laquelle tout cela repose.

La seule décision qui compte : par requête vs session collante

Presque toutes les questions sur les proxys tournants se réduisent à un seul choix, et ce n'est pas le fournisseur. C'est de savoir si vous voulez une nouvelle IP à chaque requête ou la même IP conservée sur une séquence de requêtes. Les deux modes résolvent des problèmes opposés, et choisir le mauvais est la raison la plus courante pour laquelle un scraping qui "utilise des proxys tournants" se fait quand même bloquer.

La logique est simple. Quand chaque requête est indépendante (vous récupérez une page de produit après l'autre et rien ne se transfère), une nouvelle IP par requête répartit la charge pour qu'aucune adresse ne déclenche une limite de débit. Mais dès que les requêtes dépendent les unes des autres, une connexion qui définit un cookie, un panier auquel vous ajoutez des articles avant de valider, faire tourner en milieu de flux vous casse. Le site voit votre session sauter d'un pays à l'autre entre deux clics et vous rejette. Vous voulez alors une session collante : la même IP de sortie pour toute la séquence, puis une nouvelle pour le prochain utilisateur.

Rotation par requête en Python

La façon la plus propre de faire tourner par requête est de laisser un endpoint géré le faire : vous pointez votre client vers un seul hôte et l'IP de sortie change en arrière-plan. Pour votre code c'est juste un proxy, donc rien dans requests ne change sauf l'URL du proxy. Voici un scraping minimal qui prouve que l'IP change en frappant un service echo quelques fois.

# Per-request rotation: one endpoint, a new exit IP each call.
import requests

token = "_YOUR_TOKEN_"
endpoint = f"http://{token}:@smartproxy.crawlbase.com:8012"
proxies = {"http": endpoint, "https": endpoint}

# Hit an echo service 3 times; each line should show a different IP.
for _ in range(3):
    resp = requests.get("https://httpbin.org/ip", proxies=proxies, verify=False)
    print(resp.json()["origin"])

Remplacez httpbin.org/ip par votre vraie cible et la même configuration de proxy achemine chaque requête via une sortie tournante. Le flag verify=False ignore la vérification TLS car le trafic est relayé via le tunnel du proxy ; en production vous pointeriez requests vers le bundle CA du fournisseur plutôt que de désactiver la vérification. À partir de là, l'analyse est du BeautifulSoup ordinaire ou tout ce que vous utilisez déjà, le proxy lui est invisible.

Sessions collantes en Python

Pour un flux qui doit ressembler à un seul utilisateur, vous conservez l'IP de sortie fixe sur les requêtes qui appartiennent ensemble. Avec un endpoint géré, le mécanisme habituel est d'utiliser une seule requests.Session (pour que les cookies persistent) et de passer un identifiant de session que la passerelle utilise pour fixer une IP pendant une fenêtre. La session est ce qui transporte le cookie de connexion de requête en requête ; l'IP fixée est ce qui empêche le site de voir votre "utilisateur" se téléporter en milieu de flux.

# Sticky session: one IP + one cookie jar across a multi-step flow.
import requests

token = "_YOUR_TOKEN_"
endpoint = f"http://{token}:@smartproxy.crawlbase.com:8012"

session = requests.Session()  # persists cookies across requests
session.proxies = {"http": endpoint, "https": endpoint}

# Step 1: log in (sets a cookie). Step 2: read a gated page.
# Same IP + same cookie jar make both look like one visitor.
session.post("https://example.com/login", data={"user": "u", "pass": "p"}, verify=False)
resp = session.get("https://example.com/account/orders", verify=False)
print(resp.status_code)

La façon exacte dont vous demandez une fenêtre collante (un en-tête, un token de session dans le nom d'utilisateur, ou un port dédié) dépend du fournisseur, vérifiez donc leurs docs pour le nom du paramètre. Le pattern est universel : conservez l'IP pour les requêtes qui partagent un état, libérez-la quand l'utilisateur a terminé.

Faire sa propre rotation

Vous n'avez pas strictement besoin d'un endpoint géré pour faire tourner. Si vous avez une liste de proxys, vous pouvez en choisir un par requête vous-même. Cela vaut la peine de comprendre car cela montre exactement ce qu'un endpoint géré fait pour vous, et là où cela se dégrade.

# Manual rotation: cycle a list of proxies yourself.
import requests, itertools

pool = [
    "http://user:pass@ip1:port",
    "http://user:pass@ip2:port",
    "http://user:pass@ip3:port",
]
rotation = itertools.cycle(pool)  # round-robin instead of random

def fetch(url):
    proxy = next(rotation)
    return requests.get(url, proxies={"http": proxy, "https": proxy}, timeout=15)

Le round-robin avec itertools.cycle est plus prévisible qu'un choix aléatoire car il répartit la charge uniformément plutôt que de surcharger ce que le générateur de nombres aléatoires favorise. Mais notez ce que ce code ne gère pas : une IP morte dans le pool, un proxy qui retourne une page de blocage avec un statut 200, les réessais d'une requête échouée sur une sortie différente, ou l'élagage des IPs qui ont été signalées. Dans une vraie exécution ces cas représentent la majeure partie du travail, et c'est exactement ce qu'un endpoint tournant géré absorbe pour vous. Si vous souhaitez voir le pattern complet pour faire cycler des adresses, how to rotate an IP address va plus loin sur la mécanique.

Quand un endpoint géré l'emporte sur une solution maison

La version manuelle ci-dessus convient pour une petite liste stable contre un site tolérant. Elle cesse de convenir dès que l'une des conditions suivantes est vraie : la cible combat activement les bots, vous avez besoin d'IPs d'utilisateurs réels (résidentielles ou mobiles) plutôt que datacenter, votre pool est assez grand pour que la vérification de vivacité et de santé devienne une corvée, ou vous avez besoin de réessais et d'une sélection d'IP par requête sans écrire cette orchestration vous-même.

Un endpoint tournant géré réduit tout cela à un seul hôte et port. Vous pointez votre client vers lui, et il sélectionne une IP de sortie, tourne par requête ou conserve une session collante, et réessaie en arrière-plan quand une IP se fait bloquer. Votre logique de scraping ne change pas, c'est toujours juste une URL de proxy, mais la gestion du pool, les vérifications de santé et la politique de rotation cessent d'être votre code. Le compromis honnête : vous abandonnez le contrôle fin sur les IPs individuelles en échange de ne pas maintenir une flotte. Pour la plupart des scrapings c'est un bon échange, car la plomberie IP n'est pas la partie du travail qui crée de la valeur.

Il y a un niveau encore au-dessus. Quand la cible nécessite également un navigateur rendu, envoie des défis CAPTCHA ou a besoin d'une empreinte crédible, faire tourner l'IP n'est qu'une partie du combat, et backconnect proxy vs a crawling API est la comparaison à lire. Un endpoint tournant vous donne une IP propre et s'efface ; une crawling API gère la rotation, le rendu et les réessais de bout en bout et vous remet la page finalisée.

Pannes courantes et comment les lire

Les proxys tournants échouent d'un petit nombre de façons reconnaissables. Savoir laquelle vous rencontrez économise des heures de devinettes.

Vous vous faites quand même bloquer. Généralement l'une de deux choses : vous faites tourner par requête sur un flux qui nécessite une session collante (le site voit donc votre session sauter d'IP), ou votre type d'IP est mauvais pour la cible. Un site renforcé rejettera les IPs datacenter peu importe la vitesse de rotation ; il veut des IPs d'utilisateurs réels. Faites correspondre le type d'IP aux défenses, pas la vitesse de rotation. Le compromis de type est exposé dans datacenter vs residential proxies.

Un 200 qui est en réalité un blocage. De nombreux sites retournent une page CAPTCHA ou "êtes-vous humain" avec un statut 200, donc vérifier status_code == 200 ne suffit pas. Inspectez le corps pour des marqueurs de blocage connus (une chaîne de défi, une redirection inattendue, une réponse anormalement courte) avant de faire confiance à la réponse. Traitez-les comme des échecs et réessayez sur une nouvelle IP.

Erreurs d'authentification. Un 407 (ou une connexion qui se bloque) signifie presque toujours que les identifiants dans l'URL du proxy sont incorrects ou mal formés. Vérifiez doublement le token et la forme user:pass@host:port. Si vous déboguez les codes d'état proxy en général, how to solve proxy status error codes mappe les plus courants à leurs causes.

Lent ou qui expire. Les sorties résidentielles et mobiles s'acheminent via des connexions de consommateurs et sont plus lentes que le datacenter par conception. Définissez un timeout raisonnable (l'exemple utilise 15s) et un réessai, plutôt que de laisser une seule sortie lente bloquer l'exécution. Si un endpoint géré expire largement, c'est un signal fournisseur, pas un bug de code.

Meilleures pratiques qui font vraiment la différence

La plupart des listes de "meilleures pratiques" ne sont que du remplissage. Ces quelques-unes changent genuinement votre taux de blocage. Espacez vos requêtes plutôt que de les envoyer en rafale (la rotation répartit les IPs, mais mille requêtes en une seconde depuis n'importe quel pool paraît quand même automatisé). Faites tourner votre User-Agent avec l'IP, puisqu'un UA fixe sur des milliers d'"IPs différentes" est révélateur. Faites correspondre le type d'IP à la cible plutôt que d'acheter réflexivement le niveau le plus cher. Et en production, utilisez un fournisseur avec une politique de journalisation claire plutôt que des listes de proxys gratuits scrapées, qui sont lentes, éphémères et un vrai risque de sécurité, abordé dans are proxies safe. Si votre objectif final va au-delà de la rotation seule, how to scrape websites without getting blocked les replace en contexte.

Foire aux questions

Comment utiliser un proxy tournant en Python ?

Pointez votre client HTTP vers l'endpoint tournant plutôt que vers la cible. Avec requests, construisez un dict de proxies ({"http": url, "https": url}) où l'URL est l'hôte, le port et les identifiants de votre fournisseur, et passez-le à chaque requests.get ou requests.post. L'IP de sortie change en arrière-plan, donc votre code d'analyse ne change pas du tout. Testez-le en demandant un service echo comme httpbin.org/ip quelques fois et en confirmant que l'IP diffère.

Quelle est la différence entre la rotation par requête et une session collante ?

La rotation par requête vous donne une nouvelle IP de sortie à chaque requête, ce qui répartit la charge et convient aux lectures sans état à fort volume. Une session collante conserve une IP sur une séquence de requêtes, ce dont vous avez besoin pour les connexions, les paniers et tout flux en plusieurs étapes qui doit ressembler à un seul utilisateur. Utilisez par requête pour les lectures indépendantes et collante chaque fois que les requêtes dépendent les unes des autres.

Pourquoi est-ce que je me fais encore bloquer avec un proxy tournant ?

Les deux causes habituelles sont la rotation par requête sur un flux qui nécessite une session collante (le site voit donc votre session sauter d'IP en milieu de flux) et l'utilisation du mauvais type d'IP. Une cible renforcée rejette les IPs datacenter peu importe la vitesse de rotation. Faites correspondre le type d'IP aux défenses, conservez une session collante pour les flux avec état, et vérifiez si une réponse "200" est en réalité une page CAPTCHA.

Dois-je faire tourner les proxys moi-même ou utiliser un endpoint géré ?

Faire soi-même fonctionne pour une petite liste stable contre un site tolérant. Un endpoint géré gagne dès que vous avez besoin d'IPs d'utilisateurs réels, d'un grand pool, de vérifications de santé, de réessais ou d'une sélection d'IP par requête, car il absorbe tout cela derrière un seul hôte et port. Les performances et les plages de coûts varient selon la cible et le fournisseur ; ce ne sont pas des constantes fixes. Le compromis est d'abandonner le contrôle au niveau IP contre ne pas maintenir une flotte.

Les proxys tournants fonctionnent-ils pour le scraping derrière une connexion ?

Oui, mais vous devez utiliser une session collante, pas la rotation par requête. Conservez la même IP de sortie et le même cookie jar sur la connexion et les pages protégées qui suivent, pour que le site voie un visiteur cohérent. Si vous avez besoin d'une IP qui reste fixe sur plusieurs exécutions séparées, c'est un proxy résidentiel statique (ISP) plutôt qu'un proxy tournant.

À quelle vitesse puis-je envoyer des requêtes via un proxy tournant ?

Plus vite que depuis une seule IP, car la rotation répartit les requêtes sur de nombreuses adresses, mais la rotation n'est pas une licence pour envoyer des rafales. Mille requêtes en une seconde depuis n'importe quel pool paraît quand même automatisé. Espacez vos requêtes, définissez un timeout et un réessai, et faites tourner votre User-Agent avec l'IP. Les sorties résidentielles et mobiles sont plus lentes que le datacenter par conception, prenez-le en compte dans vos timeouts.

HR

Hassan Rehan

Ingénieur logiciel · Crawlbase

Ingénieur logiciel chez Crawlbase, il rédige des guides pratiques sur les proxys rotatifs, le scraping et les détails concrets de l'intégration de proxys dans du vrai code.