Skip to content
Article / 12 min de lecture

Passerelle de proxy rotatif : un point de terminaison SOCKS5 ou HTTP local pour tout votre pool de proxys

Dirigez chaque outil vers un point de terminaison SOCKS5 ou HTTP local et laissez un petit service de passerelle choisir un proxy amont par connexion — avec configuration, sessions persistantes, contrôles de santé, DNS et vérification des fuites.

Passerelle de proxy rotatif : un point de terminaison SOCKS5 ou HTTP local pour tout votre pool de proxys

Faire tourner les proxys dans votre code fonctionne très bien jusqu’à l’arrivée du deuxième outil. Vous avez maintenant un scraper avec middleware, un navigateur que vous pilotez manuellement, un vérificateur de classement CLI avec un seul champ proxy, et une tâche cron écrite par quelqu’un d’autre — chacun tournant à sa manière, ou pas du tout.

Une passerelle de proxy rotatif élimine cette duplication. Vous exécutez un petit service localement (ou sur un VPS), pointez tout vers 127.0.0.1:8080, et la passerelle choisit un proxy amont pour chaque connexion. Ce guide couvre ce qu’est ce service, quand le saut supplémentaire en vaut la peine, comment en construire une avec une configuration réellement lisible, et comment prouver la rotation, la résolution DNS et le comportement en matière de fuites avant de lui confier du travail de production.

Ce qu’est réellement une passerelle de proxy rotatif

C’est un répartiteur de charge pour proxys. Le chemin de la requête ressemble à ceci :

  1. Client — navigateur, curl, Scrapy, Selenium, une application de bureau
  2. Passerelle — un écouteur HTTP ou SOCKS5 local sur votre machine
  3. Sélection — la passerelle choisit un amont dans votre pool
  4. Nœud de sortie — le proxy amont effectue la requête sortante
  5. Site cible — voit l’IP du nœud de sortie, pas la vôtre

La passerelle ne rend pas un proxy plus rapide, plus privé ou plus fiable. Elle centralise la sélection, les identifiants et la santé, ce qui est un problème différent de celui que résout la rotation côté client.

Quand une passerelle est préférable à la rotation dans votre code

Utilisez une passerelle lorsque :

  • Plusieurs outils ont besoin de proxys et seuls certains prennent en charge la rotation nativement
  • Vous voulez un seul endroit où mettre à jour les identifiants lorsqu’un fournisseur fait tourner votre mot de passe ou votre port
  • Vous avez besoin de sessions persistantes pour les parcours connectés et d’une rotation par requête pour le scraping, côte à côte
  • Vous voulez un point unique pour exécuter des contrôles de santé, la détection de bannissement et la notation des amonts
  • Vous voulez un comportement DNS identique entre les clients plutôt que des bizarreries propres à chaque bibliothèque
  • Vous pourriez déplacer la charge de travail d’un ordinateur portable vers un VPS ou un runner CI plus tard

Évitez la passerelle lorsque :

  • Vous avez exactement un client et il dispose déjà d’un bon middleware (le middleware de proxy rotatif de Scrapy, par exemple)
  • La rotation dépend de règles métier par requête — cible géographique, compte, niveau de prix
  • Vous avez besoin de statistiques de latence et d’échec par requête pour l’amont exact utilisé, et votre passerelle ne les expose pas

Le saut supplémentaire coûte un peu de latence. Pour la plupart des automatisations, c’est une erreur d’arrondi comparé au temps de réponse du nœud de sortie lui-même.

Choisissez le protocole d’écoute avant toute autre chose

Écouteur Prise en charge client Authentification Comportement DNS Points d’attention
HTTP (CONNECT) Quasiment universel, y compris les applications avec seulement un champ « proxy HTTP » L’authentification basique est largement prise en charge Dépend du connecteur amont Les requêtes HTTP en clair sont lisibles au niveau de la passerelle ; certains outils envoient des URL absolues
SOCKS5 Navigateurs via des options çà et là, curl, la plupart des scrapers et outils CLI Nom d’utilisateur/mot de passe (RFC 1929) Le nom d’hôte peut être transmis à l’amont pour une résolution distante Les boîtes de dialogue de proxy système sur iOS et Android n’ont pas d’option SOCKS5

En cas de doute, exécutez les deux écouteurs sur le même pool sur deux ports. Rien n’est perdu, si ce n’est un bloc de configuration supplémentaire.

Un détail DNS compte plus que les gens ne l’imaginent. Si la passerelle résout elle-même le nom d’hôte cible, alors les résultats géolocalisés reflètent le résolveur de la passerelle, pas l’emplacement du nœud de sortie. Transmettre le nom d’hôte en aval — le comportement de type socks5h — maintient la résolution au niveau du nœud de sortie, ce qui est souhaitable pour les données sensibles à la localisation.

En construire une avec gost

gost est un seul binaire Go qui parle HTTP, SOCKS5, et peut chaîner ou équilibrer une liste de nœuds amont. La version compte : la branche v3 utilise un fichier de configuration YAML, tandis que les anciennes versions s’appuyaient sur des options en ligne de commande. Vérifiez d’abord ce que vous avez.

curl -s https://api.github.com/repos/go-gost/gost/releases/latest | grep tag_name
gost -V

Voici une configuration minimale de rotation avec deux sorties SOCKS5 amont, exposées à la fois comme écouteur HTTP et SOCKS5 :

services:
  - name: pool-http
    addr: ":8080"
    handler:
      type: http
      chain: pool
    listener:
      type: tcp

  - name: pool-socks
    addr: ":1080"
    handler:
      type: socks5
      chain: pool
    listener:
      type: tcp

chains:
  - name: pool
    hops:
      - name: hop-0
        selector:
          strategy: round
        nodes:
          - name: exit-a
            addr: 203.0.113.10:1080
            connector:
              type: socks5
              metadata:
                username: user
                password: pass
          - name: exit-b
            addr: 203.0.113.11:1080
            connector:
              type: socks5
              metadata:
                username: user
                password: pass

Exécutez-le au premier plan pendant vos tests :

gost -C /etc/gost/gateway.yaml

Les stratégies de sélection diffèrent selon les versions — round parcourt les nœuds dans l’ordre, et certaines versions ajoutent une sélection aléatoire ou basée sur un hachage. Consultez la documentation du sélecteur pour votre version exacte plutôt que de supposer qu’un nom de stratégie existe ; si une fonctionnalité dont vous avez besoin manque, l’astuce d’un port par stratégie dans la section suivante vous y mènera généralement quand même.

Pour tout ce qui tourne longtemps, un fichier unit est préférable à une fenêtre de terminal :

[Unit]
Description=Rotating proxy gateway
After=network-online.target

[Service]
ExecStart=/usr/local/bin/gost -C /etc/gost/gateway.yaml
Restart=on-failure
User=gost
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

Des sessions persistantes sans fonctionnalité spéciale

De nombreuses tâches veulent l’inverse de la rotation : un parcours de paiement, un tableau de bord authentifié ou un formulaire en plusieurs étapes a besoin de la même IP de sortie pendant quelques minutes. Au lieu de courir après une option de session persistante, exécutez deux écouteurs sur deux chaînes — une équilibrée, une épinglée.

services:
  - name: pool-http
    addr: ":8080"
    handler:
      type: http
      chain: pool
    listener:
      type: tcp

  - name: pinned-http
    addr: ":8081"
    handler:
      type: http
      chain: pinned
    listener:
      type: tcp

chains:
  - name: pool
    hops:
      - name: hop-0
        selector:
          strategy: round
        nodes:
          - name: exit-a
            addr: 203.0.113.10:1080
            connector:
              type: socks5
          - name: exit-b
            addr: 203.0.113.11:1080
            connector:
              type: socks5

  - name: pinned
    hops:
      - name: hop-0
        nodes:
          - name: exit-a
            addr: 203.0.113.10:1080
            connector:
              type: socks5

Le port 8080 tourne pour le scraping, le port 8081 reste sur une seule sortie pour le travail de session. Pour épingler une autre sortie, changez une adresse et rechargez. Le même schéma vous donne des passerelles par pays pour le suivi de classement : un port par pays cible, chacun épinglé à des sorties dans ce pays.

Vérifier la rotation, le DNS et les fuites

Ne supposez jamais que la passerelle fait ce que la configuration dit. Deux minutes de vérification économisent une semaine de données déroutantes.

Commencez par une boucle shell contre l’écouteur HTTP :

for i in 1 2 3 4 5; do
  curl -s --max-time 15 --proxy http://127.0.0.1:8080 https://api.ipify.org?format=json
  echo
done

Cinq exécutions devraient afficher plus d’une IP de sortie. Si chaque ligne est identique, votre sélecteur ne tourne pas, ou vous n’avez qu’un seul nœud sain.

Confirmez ensuite la même chose depuis les bibliothèques clientes que vous utilisez réellement :

import requests

GATEWAY = "http://127.0.0.1:8080"
proxies = {"http": GATEWAY, "https": GATEWAY}

for i in range(5):
    r = requests.get(
        "https://www.cloudflare.com/cdn-cgi/trace",
        proxies=proxies,
        timeout=20,
    )
    trace = dict(line.split("=", 1) for line in r.text.strip().splitlines())
    print(i, trace.get("ip"), trace.get("loc"))

Le champ loc vous indique de quel pays Cloudflare a vu venir la requête — utile pour repérer une passerelle qui résout discrètement le DNS localement et fait atterrir le trafic dans la mauvaise région.

Pour les écouteurs SOCKS5, comparez délibérément les deux formes de nom d’hôte :

curl -s --proxy socks5h://127.0.0.1:1080 https://api.ipify.org
curl -s --proxy socks5://127.0.0.1:1080 https://api.ipify.org

Les deux devraient atteindre Internet ; la différence est de savoir si le nom d’hôte ou l’adresse résolue voyage jusqu’au nœud de sortie. Pour le travail sensible à la géolocalisation, la résolution distante est celle que vous voulez, et elle doit être prise en charge de bout en bout — passerelle et amont tous les deux.

Une courte liste de contrôle des fuites :

  • Aucune réponse ne doit jamais afficher votre véritable IP attribuée par le FAI
  • Les exécutions répétées doivent montrer une variation (ou une constante délibérée, pour les ports épinglés)
  • Les champs géographiques doivent correspondre au pool que vous avez configuré, pas à votre propre emplacement
  • Les tests dans le navigateur nécessitent une vérification distincte de WebRTC et du DNS — une passerelle ne peut pas corriger les fuites WebRTC
  • Les amonts authentifiés doivent échouer bruyamment, pas retomber silencieusement sur une connexion directe

L’exploiter : durcissement, contrôles de santé et honnêteté sur les limites

Une passerelle fonctionnelle est facile. Une passerelle sûre demande quelques décisions supplémentaires :

  • Liez à 127.0.0.1 par défaut. Un proxy non authentifié sur 0.0.0.0 est un relais ouvert dès que votre pare-feu flanche.
  • Si votre version prend en charge l’authentification de l’écouteur, activez-la. Sinon, accédez à la passerelle via un tunnel SSH au lieu d’exposer le port.
  • Gardez les identifiants dans un seul fichier avec des permissions restrictives, pas dispersés dans les scripts.
  • Ajoutez une rotation des journaux, et réfléchissez à deux fois avant de journaliser les URL complètes si le trafic touche à quoi que ce soit de sensible.
  • Rappelez-vous que la passerelle n’ajoute pas de capacité. Les limites de concurrence de votre pool amont restent le plafond.

Un contrôle de santé simple vaut mieux qu’un contrôle astucieux. Ce script signale les amonts morts afin que vous puissiez les retirer de la configuration :

#!/usr/bin/env bash
while read -r host port; do
  if curl -s --max-time 8 --proxy "socks5h://${host}:${port}" https://api.ipify.org >/dev/null; then
    echo "ok   ${host}:${port}"
  else
    echo "dead ${host}:${port}"
  fi
done < upstreams.txt

Exécutez-le selon un planning, filtrez les entrées mortes et rechargez. Cette seule habitude évite la plupart des matins « pourquoi mon scraper s’est-il soudainement fait bloquer ».

Enfin, restez dans les clous : n’utilisez que des proxys que vous êtes autorisé à utiliser, et respectez les conditions, les directives robots et les limites de débit de chaque site cible. Une passerelle facilite l’envoi de trafic — elle ne rend pas le trafic indésirable acceptable.

Comment cela s’articule avec les outils que vous utilisez déjà

Si une bibliothèque tourne déjà bien, gardez-la. La passerelle complète plutôt qu’elle ne remplace le middleware par requête dans requests de Python, Scrapy ou Selenium ; elle couvre les outils qui n’ont aucune histoire de rotation, et elle donne aux charges de travail de type suivi de classement une sortie épinglée par pays. Si vous comparez la rotation côté client et la rotation par passerelle pour le scraping en particulier, notre guide sur les proxys rotatifs pour le web scraping couvre les modèles de middleware, et le tutoriel sur les proxys rotatifs avec Selenium couvre les contraintes de lancement du navigateur qui rendent une passerelle attrayante au départ.

La version courte

  • Une passerelle de proxy rotatif est un répartiteur de charge local pour les proxys : un point de terminaison, de nombreux amonts
  • Exécutez à la fois un écouteur HTTP et un écouteur SOCKS5 ; exécutez un second port épinglé à un nœud pour le travail persistant
  • Gardez la résolution DNS au niveau du nœud de sortie lorsque la localisation compte
  • Vérifiez avec une boucle contre api.ipify.org et cdn-cgi/trace avant de faire confiance à la configuration
  • Liez à localhost, authentifiez si possible, et planifiez un contrôle de santé pour que les sorties mortes quittent le pool