Aperçu

Smartproxy fournit des endpoints proxy résidentiels et datacenter via HTTP(S) et SOCKS5 (plus de 65 millions d'IP côté résidentiel) sur un forfait mensuel fixe. Deux décisions initiales déterminent si votre configuration fonctionne du premier coup : le mode d'authentification que vous utilisez, et si une requête doit conserver la même IP de sortie ou basculer vers une nouvelle.

Ce guide couvre ces deux décisions et les vérifie avec de vraies requêtes en ligne de commande, afin que vous puissiez confirmer que l'endpoint fonctionne avant de le connecter à un scraper, un outil de suivi de position ou un profil de navigateur.

Authentification : nom d'utilisateur/mot de passe ou liste blanche d'IP

Les deux styles d'authentification sont configurés dans le tableau de bord :

Nom d'utilisateur/mot de passe — les identifiants sont envoyés à chaque requête. Fonctionne depuis n'importe quelle machine, conteneur ou runner CI, et résiste à un changement de réseau ou d'adresse FAI.
Liste blanche d'IP — aucun identifiant ne voyage avec la requête, mais votre IP publique actuelle doit être enregistrée. Cela cesse de fonctionner dès que votre FAI change votre adresse ou que vous passez à un autre réseau.

Utilisez le nom d'utilisateur/mot de passe, sauf si vous disposez d'une IP de bureau fixe et d'un outil qui ne peut pas du tout envoyer d'identifiants proxy.

Types de session : rotative ou sticky

Rotative — les requêtes peuvent partir d'une IP différente à chaque fois. C'est le comportement lorsqu'aucun jeton de session n'est attaché, et c'est ce que vous voulez pour la collecte à grande échelle où le nombre de requêtes par IP doit rester faible.
Sticky — la même IP de sortie est conservée pendant toute la durée de vie d'un jeton de session, ce qui maintient les flux avec état tels que la connexion, l'ajout au panier et le paiement sur une seule adresse.

Smartproxy encode les détails de session et de ciblage dans le nom d'utilisateur du proxy. La syntaxe exacte des paramètres est générée pour vous et peut changer, donc copiez toujours la chaîne prête à l'emploi depuis le générateur d'endpoint du tableau de bord au lieu de la taper de mémoire. Les exemples ci-dessous ne montrent que la forme générale.

Choisir entre endpoints résidentiels et datacenter

	Résidentiel	Datacenter
Pool	Plus de 65 M d'IP	Plages plus petites et stables
Vitesse	Modérée	Rapide
Idéal pour	Collecte géo-précise, vérification publicitaire, contrôle des prix	Crawling à haut volume de cibles tolérantes, tests internes
Risque de blocage	Plus faible, les IP sont largement distribuées	Plus élevé, les plages sont bien connues

Les deux types d'endpoint sont accessibles de la même manière ; seuls l'hôte, le port et les identifiants diffèrent.

Étapes

Localisez votre endpoint et vos identifiants dans le tableau de bord.

Connectez-vous, ouvrez la page de configuration proxy du produit que vous avez acheté, et copiez l'hôte et le port de l'endpoint, votre nom d'utilisateur et mot de passe proxy, ainsi que toute chaîne de session ou de ciblage que le générateur injecte dans le nom d'utilisateur.
```
export SP_USER='votre-nom-utilisateur-proxy'
export SP_PASS='votre-mot-de-passe-proxy'
export SP_ENDPOINT='host:port'   # collez la valeur exacte depuis le tableau de bord
```
Conservez les identifiants dans des variables d'environnement ou un gestionnaire de secrets plutôt que de les valider dans un script.
Choisissez votre mode d'authentification.

Nom d'utilisateur/mot de passe est la recommandation par défaut. Si vous préférez la liste blanche, notez votre IP publique actuelle et ajoutez-la dans les paramètres d'authentification du tableau de bord.
```
curl -sS https://ipinfo.io/ip
```
Revérifiez et rajoutez cette adresse chaque fois que votre FAI la change ; une entrée de liste blanche obsolète est la cause la plus fréquente d'une erreur 407 soudaine.
Vérifiez une requête HTTP rotative.

Envoyez une requête via l'endpoint et confirmez que vous voyez une IP de proxy plutôt que la vôtre.
```
curl -sS -x \"http://${SP_USER}:${SP_PASS}@${SP_ENDPOINT}\" https://ipinfo.io/json
```
Exécutez-le plusieurs fois en boucle pour confirmer que l'IP de sortie change réellement entre les requêtes.
```
for i in 1 2 3; do
  curl -sS -x \"http://${SP_USER}:${SP_PASS}@${SP_ENDPOINT}\" https://ipinfo.io/ip
  echo
done
```
Si l'adresse ne change jamais, vérifiez si un jeton de session est encore intégré dans votre nom d'utilisateur.
Épinglez une IP de sortie avec une session sticky.

Copiez le nom d'utilisateur de session sticky depuis le générateur du tableau de bord (c'est votre nom d'utilisateur plus un identifiant de session) et exportez-le dans une variable distincte afin de pouvoir basculer entre les chaînes rotative et sticky sans modifier les identifiants eux-mêmes.
```
export SP_USER_STICKY='votre-nom-utilisateur-avec-paramètres-de-session'   # copiez depuis le tableau de bord

for i in 1 2 3; do
  curl -sS -x \"http://${SP_USER_STICKY}:${SP_PASS}@${SP_ENDPOINT}\" https://ipinfo.io/ip
  echo
done
```
Les trois réponses doivent afficher la même IP de sortie pendant toute la durée de vie de ce jeton de session.
Testez le géo-ciblage.

Le ciblage par pays, ville et région passe également par la chaîne de nom d'utilisateur générée. Confirmez que la requête arrive là où vous l'attendez avant de construire un workflow par marché par-dessus.
```
export SP_USER_DE='votre-nom-utilisateur-avec-paramètre-de-pays'   # copiez depuis le tableau de bord
curl -sS -x \"http://${SP_USER_DE}:${SP_PASS}@${SP_ENDPOINT}\" https://ipinfo.io/json
```
Le champ country dans la réponse doit correspondre à la cible que vous avez configurée.
Testez l'endpoint SOCKS5.

Utilisez le schéma socks5h:// afin que la résolution DNS se fasse au niveau du proxy plutôt qu'en local, ce qui évite les fuites et les blocages basés sur le DNS.
```
curl -sS -x \"socks5h://${SP_USER}:${SP_PASS}@${SP_ENDPOINT}\" https://ipinfo.io/json
```
Si votre client ne prend en charge que socks5://, le DNS est résolu localement ; préférez socks5h dans les scripts.
Passez à un endpoint datacenter lorsque le débit compte.

Les identifiants et hôtes datacenter sont listés séparément dans le tableau de bord. Relancez la boucle de vérification sur l'hôte et le port datacenter ; seules les valeurs de l'endpoint changent, pas le format de la requête.
```
export SP_DC_ENDPOINT='hôte-datacenter:port'
curl -sS -x \"http://${SP_USER}:${SP_PASS}@${SP_DC_ENDPOINT}\" https://ipinfo.io/ip
```

Utilisez l'endpoint depuis Python.

Réutilisez les mêmes variables d'environnement afin que rien ne change lorsque vous passez du shell à un script.

import os
import requests

auth = f\"{os.environ['SP_USER']}:{os.environ['SP_PASS']}@\"
endpoint = os.environ['SP_ENDPOINT']
proxies = {
    \"http\": f\"http://{auth}{endpoint}\",
    \"https\": f\"http://{auth}{endpoint}\",
}

response = requests.get(\"https://ipinfo.io/json\", proxies=proxies, timeout=30)
response.raise_for_status()
print(response.json())

Pour un travail en sticky, construisez un second dictionnaire proxies à partir de SP_USER_STICKY et utilisez-le pour toute la session.

Ajoutez une logique de nouvelle tentative et de rotation.

Gérez les réponses 429 et 5xx avec un court backoff exponentiel, et laissez les sessions rotatives fournir naturellement une nouvelle IP à chaque tentative au lieu de réessayer la même session à plusieurs reprises.

import time

for attempt in range(4):
    try:
        response = requests.get(\"https://ipinfo.io/json\", proxies=proxies, timeout=30)
        if response.status_code < 400:
            break
    except requests.RequestException:
        pass
    time.sleep(2 ** attempt)

Dépannage

407 Proxy Authentication Required — le nom d'utilisateur ou le mot de passe est incorrect, une chaîne de session ou de ciblage a été collée dans le mauvais champ, ou votre IP en liste blanche ne correspond plus à votre adresse actuelle. Recopiez la chaîne depuis le générateur du tableau de bord.
Identifiants rejetés après avoir bien fonctionné — les mots de passe contenant @, :, / ou # doivent être encodés en URL dans l'URL proxy (@ devient %40, : devient %3A). Préférez un mot de passe sans caractères spéciaux si votre outil ne peut pas les encoder.
curl: (7) Failed to connect — l'hôte ou le port est incorrect, ou vous avez copié un endpoint résidentiel dans un emplacement datacenter (ou l'inverse). Chaque produit a son propre hôte et port.
Chaque requête renvoie la même IP — un jeton de session sticky est encore présent dans le nom d'utilisateur, ou vous utilisez l'ensemble d'identifiants sticky au lieu de celui rotatif.
La session sticky change d'IP en cours de workflow — les durées de vie des sessions expirent. Démarrez délibérément un nouveau jeton de session et réauthentifiez-vous au lieu de supposer que l'ancien persiste indéfiniment.
Les requêtes expirent uniquement en SOCKS5 — le client peut ne pas prendre en charge le DNS distant. Passez à socks5h:// ou revenez à l'endpoint HTTP pour cet outil.
L'authentification par liste blanche échoue par intermittence — les réseaux mobiles et les connexions domestiques changent d'IP publique. Utilisez le nom d'utilisateur/mot de passe pour les tâches sans surveillance.

Résumé

L'intégration de Smartproxy se résume à deux choix et une habitude. Choisissez le nom d'utilisateur/mot de passe, sauf si vous avez une IP véritablement statique, et choisissez des sessions rotatives pour les charges de collecte ou des sessions sticky pour les flux avec état. L'habitude consiste à copier l'endpoint et la chaîne de nom d'utilisateur directement depuis le générateur du tableau de bord, car les paramètres de session et de géo-ciblage résident dans cette chaîne. Vérifiez le chemin rotatif, le chemin sticky, le chemin SOCKS5 et l'hôte datacenter avec les courtes boucles curl ci-dessus avant d'y pointer un scraper ou un outil de suivi de position.