Comment configurer les proxys Smartproxy sur Linux avec curl et Python pour l'automatisation CLI

Aperçu

Ce tutoriel montre comment envoyer du trafic en ligne de commande et Python via un proxy sur Linux, y compris l'authentification, la vérification de l'IP de sortie, l'épinglage de session et les exécutions planifiées. Smartproxy est utilisé ici comme fournisseur suggéré, car il propose des proxys résidentiels et datacenter via HTTP et SOCKS5 avec une facturation mensuelle forfaitaire et un pool de plus de 65 M d'IP, mais chaque étape fonctionne avec n'importe quel service proxy exposant les mêmes protocoles.

À la fin de ce guide, vous saurez :

• Authentifier votre endpoint proxy depuis le shell avec curl
• Confirmer que le trafic sortant sort depuis l'IP du proxy plutôt que depuis la vôtre
• Utiliser le même endpoint depuis Python avec requests
• Épingler une session sticky ou faire tourner les IP entre les requêtes
• Automatiser les contrôles d'état avec cron ou un timer systemd

Prérequis

• Un hôte Linux (les commandes ci-dessous utilisent Debian/Ubuntu ; les équivalents Fedora et Arch sont indiqués)
• curl et Python 3.8 ou plus récent
• Un compte Smartproxy avec un forfait actif et des identifiants proxy
• L'hôte et les ports de l'endpoint du produit que vous souhaitez utiliser, copiés depuis le tableau de bord de votre compte Smartproxy
• Un accès sortant sur le port du proxy, et aucun pare-feu d'entreprise ni client VPN qui le bloque

Étape 1 — Installer les outils requis

Installez curl et Python, puis créez un environnement isolé pour le client Python.

sudo apt update
sudo apt install -y curl python3 python3-venv

Sur les systèmes Fedora ou RHEL, utilisez :

sudo dnf install -y curl python3

Créez un environnement virtuel et installez le client HTTP ainsi que la prise en charge de SOCKS :

python3 -m venv ~/.venvs/proxy
source ~/.venvs/proxy/bin/activate
pip install --upgrade pip
pip install 'requests[socks]'

L'extra requests[socks] installe PySocks, ce qui permet aux URL socks5h:// de fonctionner en Python.

Étape 2 — Stocker les identifiants en dehors de vos scripts

Coder en dur les identifiants dans les scripts ou les valider dans un dépôt est la façon la plus courante de faire fuiter des comptes proxy. Conservez-les dans un seul fichier avec des permissions restrictives et chargez-le uniquement lorsque c'est nécessaire.

install -d -m 700 ~/.config/smartproxy
install -m 600 /dev/null ~/.config/smartproxy/env

Ouvrez le fichier dans votre éditeur et remplacez chaque espace réservé par les valeurs affichées dans le tableau de bord de votre fournisseur :

# ~/.config/smartproxy/env
# Remplacez chaque valeur REPLACE_WITH_ en utilisant l'endpoint et les identifiants
# depuis le tableau de bord de votre fournisseur. Ne validez pas ce fichier dans le contrôle de version.
export SP_PROXY_HOST="REPLACE_WITH_ENDPOINT_HOST"
export SP_PROXY_PORT_HTTP="REPLACE_WITH_HTTP_PORT"
export SP_PROXY_PORT_SOCKS5="REPLACE_WITH_SOCKS5_PORT"
export SP_PROXY_USER="REPLACE_WITH_PROXY_USERNAME"
export SP_PROXY_PASS="REPLACE_WITH_PROXY_PASSWORD"

Chargez les variables dans votre shell actuel :

set -a; . ~/.config/smartproxy/env; set +a

Si vous utilisez à la fois des produits résidentiels et datacenter, conservez une paire de variables distincte pour chacun, car ils ont généralement des hôtes ou des ports différents.

Étape 3 — Choisir entre HTTP et SOCKS5

Les deux protocoles sont pris en charge par Smartproxy, et le bon choix dépend de ce que vous envoyez via le tunnel.

Si vous ne récupérez que des URL HTTPS, commencez par HTTP et passez à SOCKS5 uniquement si un outil l'exige.

Étape 4 — Tester la connexion avec curl

Envoyez une requête via le proxy HTTP et affichez l'IP de sortie que voit la destination :

curl -sS --max-time 30 \
  --proxy "http://${SP_PROXY_HOST}:${SP_PROXY_PORT_HTTP}" \
  --proxy-user "${SP_PROXY_USER}:${SP_PROXY_PASS}" \
  'https://api.ipify.org?format=json'

Testez maintenant le même endpoint via SOCKS5. La variante --socks5-hostname résout le DNS au niveau du proxy, ce qui évite que les recherches DNS locales ne divulguent votre emplacement réel :

curl -sS --max-time 30 \
  --socks5-hostname "${SP_PROXY_HOST}:${SP_PROXY_PORT_SOCKS5}" \
  --proxy-user "${SP_PROXY_USER}:${SP_PROXY_PASS}" \
  'https://api.ipify.org?format=json'

Comparez le résultat avec une requête directe qui contourne complètement le proxy :

curl -sS 'https://api.ipify.org?format=json'

Si l'IP proxifiée diffère de l'IP directe, le trafic sort bien via le proxy. Exécutez la commande proxifiée plusieurs fois pour voir si l'IP de sortie change ; cela vous indique si vous êtes sur un endpoint rotatif ou sticky.

Étape 5 — Épingler une session sticky ou faire tourner l'IP à chaque requête

Le comportement rotatif est la valeur par défaut sur la plupart des endpoints résidentiels : chaque nouvelle connexion peut sortir via une IP différente. Pour les connexions, les formulaires à plusieurs étapes ou les flux de type paiement, vous voulez généralement la même IP pour toute une séquence de requêtes.

Votre fournisseur construit des noms d'utilisateur sticky à partir d'un jeton de session. Ajoutez le jeton au nom d'utilisateur proxy en utilisant le modèle exact affiché dans le générateur de session de votre tableau de bord, qui ressemble généralement à un suffixe sur le nom d'utilisateur :

export SP_SESSION_ID="$(openssl rand -hex 4)"
export SP_SESSION_USER="${SP_PROXY_USER}-session-${SP_SESSION_ID}"

Remplacez ensuite $SP_SESSION_USER partout où les commandes ci-dessus utilisent $SP_PROXY_USER. Réutilisez le même jeton pendant toute la durée de la tâche, et générez un nouveau jeton lorsque vous voulez une nouvelle IP de sortie.

Étape 6 — Utiliser le proxy depuis Python

Une fois le fichier d'environnement chargé, les mêmes variables sont disponibles pour Python. Cet exemple utilise le proxy HTTP pour une requête HTTPS :

import os
from urllib.parse import quote

import requests

host = os.environ['SP_PROXY_HOST']
port = os.environ['SP_PROXY_PORT_HTTP']
user = quote(os.environ['SP_PROXY_USER'], safe='')
password = quote(os.environ['SP_PROXY_PASS'], safe='')

proxies = {
    'http': f'http://{user}:{password}@{host}:{port}',
    'https': f'http://{user}:{password}@{host}:{port}',
}

response = requests.get(
    'https://api.ipify.org?format=json',
    proxies=proxies,
    timeout=30,
)
response.raise_for_status()
print(response.json())

Pour passer à SOCKS5, modifiez uniquement le schéma et le port. Le schéma socks5h effectue une résolution DNS distante, ce qui correspond à curl --socks5-hostname :

socks_port = os.environ['SP_PROXY_PORT_SOCKS5']
socks_proxies = {
    'http': f'socks5h://{user}:{password}@{host}:{socks_port}',
    'https': f'socks5h://{user}:{password}@{host}:{socks_port}',
}

Deux remarques pratiques :

• Définissez toujours un timeout explicite. Les réseaux proxy sont vastes et certains nœuds de sortie peuvent être lents ou indisponibles ; un timeout manquant transforme un mauvais nœud en processus bloqué.
• Encodez en pourcentage le nom d'utilisateur et le mot de passe, comme montré avec quote(), car les délimiteurs de session et les caractères spéciaux cassent les URL de proxy s'ils sont transmis bruts.

Un petit wrapper de nouvelle tentative rend les scripts beaucoup plus résilients :

import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry

session = requests.Session()
session.proxies.update(proxies)
session.mount('https://', HTTPAdapter(max_retries=Retry(
    total=3,
    backoff_factor=1,
    status_forcelist=[429, 500, 502, 503, 504],
)))

Étape 7 — Exécuter le contrôle selon un planning

Enregistrez l'extrait de vérification sous ~/scripts/check_proxy.py, puis planifiez-le avec cron afin que les problèmes d'identifiants et les endpoints morts apparaissent tôt.

# Faire tourner un journal des IP de sortie toutes les heures
0 * * * * set -a; . $HOME/.config/smartproxy/env; set +a; $HOME/.venvs/proxy/bin/python $HOME/scripts/check_proxy.py >> $HOME/proxy-check.log 2>&1

La même tâche en tant que service et timer systemd, ce qui est plus facile à surveiller avec journalctl :

# ~/.config/systemd/user/proxy-check.service
[Unit]
Description=Vérifier l'IP de sortie du proxy

[Service]
Type=oneshot
EnvironmentFile=%h/.config/smartproxy/env
ExecStart=%h/.venvs/proxy/bin/python %h/scripts/check_proxy.py

# ~/.config/systemd/user/proxy-check.timer
[Unit]
Description=Exécuter la vérification du proxy toutes les heures

[Timer]
OnCalendar=hourly
Persistent=true

[Install]
WantedBy=timers.target

Activez et démarrez-le avec :

systemctl --user daemon-reload
systemctl --user enable --now proxy-check.timer
systemctl --user list-timers proxy-check.timer

Dépannage

Contrôles supplémentaires à effectuer lorsque quelque chose se comporte de manière inattendue :

1. Affichez les variables résolues avec env | grep SP_PROXY pour écarter les erreurs de portée du shell.
2. Testez les deux protocoles ; si SOCKS5 fonctionne et HTTP non, le problème vient de la configuration du client plutôt que de l'endpoint.
3. Journalisez l'IP de sortie avec l'horodatage dans la sortie de votre tâche afin de pouvoir corréler les échecs avec des nœuds spécifiques.

Résumé

• Smartproxy expose des proxys résidentiels et datacenter via HTTP et SOCKS5 avec une facturation mensuelle forfaitaire, ce qui en fait un fournisseur suggéré raisonnable pour les workflows en CLI et de scripting.
• Conservez les identifiants dans un fichier d'environnement en chmod 600 et chargez-les avec set -a; . file; set +a au lieu de les intégrer dans les scripts.
• Utilisez le proxy HTTP pour les outils HTTPS uniquement et --socks5-hostname ou socks5h:// lorsque vous avez besoin d'un transfert agnostique au protocole ou d'une résolution DNS distante.
• Vérifiez la configuration en comparant une requête proxifiée à une requête directe ; des IP identiques signifient que le proxy a été contourné.
• Ajoutez un jeton de session au nom d'utilisateur pour les workflows sticky, et générez un nouveau jeton par worker pour les tâches rotatives parallèles.
• Intégrez le même contrôle dans cron ou un timer systemd afin que l'expiration des identifiants et les endpoints morts soient détectés avant qu'une exécution en production n'échoue.