Aperçu

IPRoyal propose des proxys résidentiels, datacenter et ISP via HTTP(S), SOCKS5 et un tunnel de type Shadowsocks, facturés soit à l’usage, soit au forfait mensuel, et s’appuyant sur un pool de plus de 32 millions d’IP. Cette étendue de protocoles est exactement pourquoi les gens le choisissent — et c’est aussi la raison la plus courante d’échec d’une première configuration. Coller un point de terminaison SOCKS5 dans un champ HTTP uniquement, ou l’inverse, produit des erreurs qui ressemblent à un proxy mort plutôt qu’à une incompatibilité de configuration.

Ce tutoriel vous guide depuis un nouveau compte IPRoyal jusqu’à une connexion vérifiée et scriptable. Vous choisirez le bon type de proxy et le bon protocole pour votre charge de travail, construirez une URL de proxy fonctionnelle, prouverez que le trafic sort bien via IPRoyal, et vérifierez que le DNS ne résout pas en dehors du tunnel. Toutes les commandes s’exécutent dans un terminal macOS ou Linux ; les URL de proxy sont identiques sous Windows, seule la syntaxe des variables shell diffère.

Ce dont vous avez besoin

Un forfait IPRoyal actif (résidentiel, datacenter ou ISP) et l’accès à votre tableau de bord
L’hôte de passerelle, le port, le nom d’utilisateur et le mot de passe exactement tels que le tableau de bord les affiche
curl compilé avec le support SOCKS5 (les versions standard sur macOS, Debian et Ubuntu l’incluent)
Facultatif : Python 3.8+ avec la bibliothèque requests pour des vérifications scriptées

Choisir le type de proxy et le protocole

Le type de proxy et le protocole sont deux décisions distinctes. Le type détermine quelle IP vous apparaissez ; le protocole détermine comment votre trafic est encapsulé jusqu’à destination. Choisissez d’abord le type, puis le protocole.

Charge de travail	Type de proxy	Protocole	Pourquoi ça convient
Confidentialité du navigateur dans une région	Résidentiel	HTTP(S)	Le plus simple à configurer ; fonctionne dans n’importe quel champ de proxy de navigateur
Outils CLI et scrapers qui ne doivent pas fuiter le DNS	Résidentiel	SOCKS5	Comportement de tunnel complet avec résolution DNS distante
Applications qui n’acceptent qu’un proxy HTTP	ISP	HTTP(S)	Adresses stables de type hébergement, qui paraissent moins inhabituelles
Sessions de longue durée, une IP par compte	ISP ou résidentiel	SOCKS5 ou Shadowsocks	Les connexions persistent sans rotation forcée
Réseaux où les ports de proxy simples sont limités ou bloqués	Tout	Shadowsocks	Tunnel obfusqué lorsqu’un port de proxy brut est filtré

La disponibilité des protocoles peut varier selon le produit et le forfait, donc vérifiez ce que votre tableau de bord spécifique expose avant de construire quoi que ce soit. Lorsque les deux sont proposés, HTTP(S) est plus facile à déboguer et SOCKS5 est plus capable — commencez par HTTP(S), puis passez à SOCKS5 une fois que les identifiants sont prouvés fonctionnels.

Étapes

Copiez le point de terminaison et les identifiants depuis le tableau de bord. Ne les retapez pas. Utilisez les boutons de copie afin que les espaces de fin et les caractères ressemblants n’entrent jamais en jeu. Les quatre valeurs dont vous avez besoin sont l’hôte de passerelle, le port, le nom d’utilisateur et le mot de passe.
```
export PROXY_USER="dashboard-username"
export PROXY_PASS="dashboard-password"
export PROXY_HOST="gateway-host-from-dashboard"
export PROXY_PORT="gateway-port-from-dashboard"
```
Construisez l’URL de proxy pour chaque protocole. Le format d’URL est le même partout : identifiants, puis hôte, puis port.
```
http://USERNAME:PASSWORD@HOST:PORT     # proxy HTTP/HTTPS
socks5h://USERNAME:PASSWORD@HOST:PORT  # SOCKS5, DNS résolu au niveau du proxy
```
Si votre mot de passe contient @, :, / ou ?, encodez-le en pourcentage (@ devient %40, : devient %3A). Les caractères spéciaux non encodés sont la cause la plus courante d’échecs d’authentification.
Vérifiez une requête HTTP(S) depuis le terminal. Cela prouve que les identifiants, l’hôte et le port sont tous corrects avant d’impliquer un navigateur ou un script.
```
curl -sS \
  --proxy "http://$PROXY_USER:$PROXY_PASS@$PROXY_HOST:$PROXY_PORT" \
  "https://api.ipify.org?format=json"
```
Vous devriez recevoir un petit objet JSON contenant une valeur ip qui n’est pas votre propre adresse. Si vous voyez votre IP réelle ici, l’option a été ignorée et le trafic est sorti directement.
Vérifiez une requête SOCKS5 et obtenez un DNS distant. Utilisez --socks5-hostname pour que le proxy résolve le nom d’hôte au lieu que votre machine le fasse localement.
```
curl -sS \
  --socks5-hostname "$PROXY_USER:$PROXY_PASS@$PROXY_HOST:$PROXY_PORT" \
  "https://api.ipify.org?format=json"
```
La différence compte : --socks5 résout le DNS sur votre appareil puis tunnelise la connexion, tandis que --socks5-hostname envoie le nom d’hôte au proxy. Pour les travaux de confidentialité, préférez --socks5-hostname et le schéma d’URL équivalent socks5h:// dans les scripts.
Inspectez le tunnel lorsque quelque chose semble anormal. La sortie détaillée montre si le proxy a accepté la requête avant que le contenu de la page n’entre en jeu.
```
curl -v \
  --proxy "http://$PROXY_USER:$PROXY_PASS@$PROXY_HOST:$PROXY_PORT" \
  -o /dev/null "https://example.com"
```
Cherchez une ligne CONNECT suivie de HTTP/1.1 200 Connection established. Un 407 à ce moment est un problème d’authentification ; un délai d’attente à ce moment est un problème d’hôte ou de port.

Scriptez la même vérification en Python. Pour les proxys HTTP, requests n’a besoin d’aucun paquet supplémentaire.

import os
import requests

proxy_url = os.environ["IPROYAL_PROXY_URL"]  # http://user:pass@host:port
proxies = {"http": proxy_url, "https": proxy_url}

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

Pour SOCKS5, installez d’abord la dépendance facultative, puis utilisez une URL socks5h:// afin que le DNS soit résolu au niveau du proxy.

pip install "requests[socks]"

import os
import requests

socks_url = os.environ["IPROYAL_SOCKS_URL"]  # socks5h://user:pass@host:port
proxies = {"http": socks_url, "https": socks_url}

session = requests.Session()
print(session.get("https://api.ipify.org", proxies=proxies, timeout=30).text)

Décidez entre rotation et sessions persistantes. Exécutez l’étape 3 deux fois avec les mêmes identifiants et comparez les deux adresses. Si l’IP est inchangée, votre forfait maintient une session persistante, ce que vous voulez pour les connexions et les formulaires à plusieurs étapes. Si vous avez besoin d’une nouvelle adresse, demandez-en une à l’aide des contrôles de session ou de rotation fournis par votre tableau de bord plutôt que de modifier manuellement les paramètres d’URL — les identifiants générés sont déjà correctement formatés.
Confirmez la région de sortie et vérifiez les fuites DNS. Une requête de trace Cloudflare montre à la fois l’IP de sortie et le pays dans lequel elle est enregistrée, ce qui est le moyen le plus rapide de détecter un forfait mal routé.
```
curl -sS \
  --proxy "http://$PROXY_USER:$PROXY_PASS@$PROXY_HOST:$PROXY_PORT" \
  "https://1.1.1.1/cdn-cgi/trace"
```
Lisez les lignes ip= et loc= : loc= doit correspondre à la région que vous vouliez utiliser. Ensuite, lancez un test public de fuite DNS dans le navigateur que vous avez configuré ; si le résolveur affiché est votre FAI local plutôt que le réseau proxy, basculez ce navigateur vers une configuration SOCKS5 ou un client qui prend en charge le DNS distant de type socks5h.

Dépannage

407 Proxy Authentication Required — Les identifiants sont erronés, révoqués ou contiennent des caractères spéciaux non encodés. Encodez le mot de passe en pourcentage et recopiez les deux valeurs.
curl: (7) Failed to connect ou un délai d’attente — Hôte ou port incorrect, ou le protocole et le port ne correspondent pas (un port HTTP utilisé avec une URL SOCKS5). Vérifiez la colonne protocole dans le tableau de bord.
curl: (97) Can't complete SOCKS5 connection — curl a atteint quelque chose qui n’est pas un point de terminaison SOCKS5. Confirmez que vous êtes sur le port SOCKS5 et non sur le port HTTP.
Fonctionne dans curl, échoue dans le navigateur — La plupart des champs de proxy des navigateurs n’acceptent que HTTP(S). Utilisez soit le point de terminaison HTTP, soit configurez SOCKS5 au niveau du système d’exploitation ou du client.
403 ou 429 répétés depuis un site cible — Le site limite le débit de l’adresse ou de la session. Ralentissez le rythme des requêtes, ou conservez une session pour une séquence plus longue au lieu de tourner à chaque requête.
L’IP de sortie ne change jamais — Une session persistante est active, ou le pool sélectionné est géographiquement restreint. Utilisez les contrôles de session du tableau de bord pour demander une sortie différente.
HTTPS fonctionne mais les pages affichent toujours votre région locale — Le DNS est résolu localement. Passez à socks5h/--socks5-hostname, ou déplacez le client vers une configuration de tunnel complet.
Le client Shadowsocks ne démarre pas — Généralement un chiffrement ou une clé mal saisi. Collez la configuration générée au lieu de la retranscrire, et assurez-vous que le port d’écoute local que vous avez choisi n’est pas déjà utilisé.
Des frais qui augmentent de façon inattendue — Les forfaits à l’usage comptabilisent l’utilisation, donc une boucle emballée dans un scraper ou un navigateur qui se synchronise en arrière-plan peut consommer rapidement le quota. Vérifiez l’utilisation après votre première exécution de vérification.

Résumé

Le type de proxy (résidentiel, datacenter, ISP) choisit l’IP sous laquelle vous apparaissez ; le protocole (HTTP, SOCKS5, Shadowsocks) choisit comment le trafic est encapsulé. Décidez des deux délibérément.
Copiez l’hôte, le port, le nom d’utilisateur et le mot de passe depuis le tableau de bord, encodez les caractères spéciaux en pourcentage et construisez un format d’URL par protocole.
Vérifiez avec une seule requête curl vers un service d’écho IP avant de toucher à un navigateur ou à un script — cela isole les erreurs d’identifiants des erreurs d’application.
Utilisez socks5h:// ou --socks5-hostname chaque fois que la confidentialité DNS compte, et confirmez la région de sortie avec une requête de trace.
Testez tôt la rotation par rapport aux sessions persistantes, car ce choix détermine comment vos outils doivent gérer les nouvelles tentatives et les connexions.

Une fois qu’une seule requête vérifiée réussit, les mêmes identifiants s’intègrent directement dans un navigateur, une bibliothèque de scraping ou un outil de chaînage de proxys. IPRoyal est un fournisseur raisonnable pour ce flux de travail compte tenu de sa gamme de protocoles et de ses options de facturation ; les étapes de vérification ci-dessus s’appliquent à tout fournisseur auquel vous le comparez.