Utiliser cURL avec un proxyFlags, authentification et SOCKS dans le terminal

La réponse courte tient en un seul flag : curl -x "http://host:port" "https://example.com" achemine la requête via un proxy, de sorte que la cible voit l'adresse IP du proxy plutôt que la vôtre. Le flag -x (ou --proxy) résume toute la fonctionnalité. Tout le reste dans ce billet est une variation : comment ajouter des identifiants, comment changer de protocole, comment le définir une seule fois pour tout un shell, et comment confirmer que la configuration a bien pris effet.

Si vous savez déjà ce qu'est un serveur proxy et que vous cherchez simplement des commandes correctes à copier-coller, passez directement au tableau de syntaxe ci-dessous. Les exemples utilisent 127.0.0.1 et des espaces réservés explicites pour que vous puissiez substituer votre propre hôte, port et identifiants sans hésiter sur les champs.

Le seul flag nécessaire : -x

cURL achemine les requêtes via un proxy quand vous passez -x (forme courte) ou --proxy (forme longue). Ils sont identiques ; choisissez celui qui se lit le mieux dans vos scripts. La valeur est une URL : schéma, identifiants optionnels, hôte et port.

# Route one request through an HTTP proxy
curl -x "http://127.0.0.1:8080" "https://example.com"

# Same request, long-form flag
curl --proxy "http://127.0.0.1:8080" "https://example.com"

Le schéma devant l'hôte du proxy (http://, https://, socks5://) indique à cURL comment parler au proxy, pas ce qu'il récupère. Un proxy http:// ordinaire récupère très bien les URLs https:// : cURL ouvre un tunnel CONNECT et exécute TLS de bout en bout, de sorte que le proxy ne voit jamais vos octets chiffrés. Cette distinction déroute souvent les utilisateurs, et il vaut la peine de lire HTTP vs HTTPS proxies si la frontière n'est pas claire.

Ajouter une authentification proxy

La plupart des proxys payants exigent des identifiants. Vous avez deux façons de les fournir, et leur comportement diffère légèrement.

La première place l'utilisateur et le mot de passe directement dans l'URL du proxy, avant l'hôte, séparés par deux-points et terminés par @ :

# Credentials inline in the proxy URL
curl -x "http://user:[email protected]:8080" "https://example.com"

# Credentials in a separate flag (keeps them out of the URL)
curl -x "http://127.0.0.1:8080" -U "user:pass" "https://example.com"

La forme -U (ou --proxy-user) vaut la peine d'être adoptée comme habitude : elle garde le mot de passe hors de l'URL, ce qui tend à fuiter dans l'historique shell et les journaux. Si votre nom d'utilisateur ou votre mot de passe contient des caractères spéciaux (@, :, /), encodez-les en URL, sinon cURL mal interprétera l'emplacement de l'hôte. Un @ littéral dans un mot de passe, par exemple, devient %40.

HTTP, HTTPS et SOCKS en un seul endroit

Les proxys SOCKS fonctionnent de la même façon ; seul le schéma change. SOCKS se situe une couche en dessous de HTTP et transfère du TCP brut, ce qui lui permet de transporter n'importe quel protocole sans pouvoir lire ni réécrire vos requêtes. Utilisez socks5h:// plutôt que socks5:// lorsque vous souhaitez que le proxy résolve le DNS (afin que votre machine ne révèle jamais le nom d'hôte qu'elle recherche) ; le h signifie "résolution de nom d'hôte côté proxy". Pour la comparaison approfondie, consultez what is a SOCKS5 proxy.

Il existe aussi un flag dédié --socks5 (et --socks4) qui prend un simple host:port sans schéma. Il est équivalent à -x "socks5://..." et existe surtout pour la lisibilité quand un script jongle avec plusieurs types de proxy.

Définir un proxy pour tout le shell avec des variables d'environnement

Passer -x à chaque commande devient fastidieux. Exportez le proxy une seule fois et chaque appel cURL dans cette session shell l'utilisera, ainsi que la plupart des autres outils en ligne de commande qui respectent ces variables (wget, git, les gestionnaires de paquets, etc.).

# Apply to every request in this shell session
export http_proxy="http://user:[email protected]:8080"
export https_proxy="http://user:[email protected]:8080"

# Skip the proxy for these hosts, comma-separated
export NO_PROXY="localhost,127.0.0.1,.internal.example.com"

# Stop using the proxy
unset http_proxy https_proxy

http_proxy et https_proxy prennent la même valeur : le schéma est le protocole utilisé par cURL pour atteindre le proxy, tandis que le nom de la variable sélectionne les URLs cibles auxquelles elle s'applique. NO_PROXY est la porte de sortie : tout hôte correspondant à la liste se connecte directement. Un point initial (.internal.example.com) correspond à tous les sous-domaines, et NO_PROXY="*" désactive complètement le proxy sans supprimer les autres variables.

Rendre le proxy permanent avec .curlrc

Les variables d'environnement disparaissent avec le shell. Pour que cURL utilise toujours un proxy, ajoutez-le dans le fichier de configuration de cURL. Sous Linux et macOS, c'est ~/.curlrc ; sous Windows, c'est _curlrc dans le répertoire %APPDATA%.

# ~/.curlrc  (Linux / macOS)
proxy = "http://user:[email protected]:8080"
proxy-user = "user:pass"

Toutes les commandes cURL passent désormais par le proxy sans flags. Cette commodité a un revers : il est facile d'oublier que le fichier existe, puis de passer une heure à se demander pourquoi une machine se comporte différemment d'une autre. Si une requête dysfonctionne, vérifiez ~/.curlrc en premier. Pour contourner le fichier pour un seul appel, passez --noproxy "*" ou exécutez avec -q, ce qui indique à cURL d'ignorer entièrement le fichier de configuration.

Contourner le proxy pour des requêtes spécifiques

Quand un proxy est défini globalement (variable d'environnement ou .curlrc), vous voudrez parfois qu'une requête passe en direct, un contrôle de santé interne, par exemple, ou un service localhost. --noproxy gère cela par commande :

# Ignore the proxy entirely for this one request
curl --noproxy "*" "http://localhost:3000/health"

# Bypass only for one domain, proxy stays on for the rest
curl --noproxy "internal.example.com" "http://internal.example.com/api"

Vérifier que le proxy fonctionne réellement

Ne partez jamais du principe que le routage a pris effet : confirmez-le. La vérification la plus rapide consiste à demander à un service echo l'adresse IP qu'il voit et à la comparer à la vôtre. Si l'adresse renvoyée est celle du proxy, vous êtes routé.

# Your real IP, no proxy
curl "https://httpbin.org/ip"

# The IP seen through the proxy: should differ
curl -x "http://user:[email protected]:8080" "https://httpbin.org/ip"

# Add -v to watch the CONNECT handshake and headers
curl -v -x "http://user:[email protected]:8080" "https://httpbin.org/ip"

Le flag verbeux (-v) est le vrai outil de diagnostic. Il affiche la connexion au proxy, la ligne CONNECT pour les cibles HTTPS, la réponse du proxy et la requête qui part finalement, ce qui vous indique exactement où les choses se bloquent quand elles se bloquent.

Erreurs courantes de proxy cURL et comment les lire

La plupart des échecs de proxy se manifestent sous un petit nombre de formes reconnaissables. Lire le message plutôt que de réessayer aveuglément économise un temps réel.

Cette dernière ligne est la plus importante pour le scraping. Un 403 ou un 429 signifie que votre commande cURL est parfaite : la cible ne fait simplement pas confiance à l'IP depuis laquelle vous venez. Aucun flag ne corrige cela ; vous avez besoin d'une meilleure IP ou d'une IP tournante. Si vous continuez à le rencontrer, how to scrape without getting blocked et proxy status error codes vont plus loin qu'une seule commande ne peut l'atteindre.

Concernant la ligne SSL : cURL a un flag -k (--insecure) qui ignore la vérification des certificats. C'est acceptable pour tester sur une machine locale et un vrai danger contre tout ce qui vous importe, car il désactive exactement la vérification qui détecte une attaque de l'homme du milieu. Traitez-le comme un outil de débogage, jamais comme un défaut.

D'un seul proxy à un pool tournant

Tout ce qui précède fonctionne contre un seul proxy. Dès que vous scraper à volume, une seule IP devient le goulot d'étranglement : la cible la limite en débit, puis la bloque, et vous voilà à permuter manuellement des adresses. L'étape suivante habituelle est une liste de proxys que vous faites tourner vous-même, ce qui implique d'écrire la logique de rotation, de réessai et de vérification de santé à la main. Consultez how to use rotating proxies pour cette approche.

L'autre option est de placer un seul endpoint devant l'ensemble du pool et de le laisser effectuer la rotation pour vous. Votre commande cURL ne change pas du tout ; vous pointez simplement -x vers une passerelle plutôt que vers un hôte unique, et une nouvelle IP de sortie est choisie par requête en arrière-plan.

# Same -x flag, pointed at a rotating gateway.
# Your token is the proxy username; password is empty.
curl -x "http://_USER_TOKEN_:@smartproxy.crawlbase.com:8012" -k \
     "https://httpbin.org/ip"

C'est le seul changement dans votre flux de travail : la passerelle permute l'IP de sortie en arrière-plan pendant que votre commande reste un appel cURL ordinaire. Si la cible nécessite également un vrai navigateur ou des réessais côté serveur, un fetch géré comme l'Crawling API prend une URL et retourne le résultat rendu au lieu de simplement vous fournir une IP propre. La configuration de l'un ou l'autre se fait via la documentation API.

Foire aux questions

Comment utiliser un proxy avec cURL ?

Passez le flag -x (ou --proxy) avec l'URL du proxy : curl -x "http://host:port" "https://example.com". Ajoutez les identifiants en ligne sous la forme http://user:pass@host:port ou, mieux, avec un flag séparé -U "user:pass". Le schéma dans l'URL du proxy (http, https, socks5) est la façon dont cURL parle au proxy, pas ce qu'il récupère.

Comment ajouter un nom d'utilisateur et un mot de passe à un proxy cURL ?

Soit vous les intégrez dans l'URL du proxy avant l'hôte (-x "http://user:pass@host:port"), soit vous les fournissez séparément avec -U "user:pass". Le flag séparé garde le mot de passe hors de votre historique shell. Encodez en URL tous les caractères spéciaux dans les identifiants ; un @ littéral devient %40, par exemple, afin que cURL analyse correctement l'hôte.

Comment définir un proxy avec des variables d'environnement ?

Exportez http_proxy et https_proxy avec l'URL du proxy, et cURL (ainsi que la plupart des autres outils en ligne de commande) les utilisera pour chaque requête dans ce shell. Utilisez NO_PROXY pour lister les hôtes qui doivent se connecter directement, et unset http_proxy https_proxy pour désactiver. Préférez http_proxy en minuscules pour éviter un conflit lié au CGI avec la forme majuscule.

cURL peut-il utiliser un proxy SOCKS5 ?

Oui. Utilisez -x "socks5://host:port", ou le flag dédié --socks5 "host:port". Pour que le proxy résolve le DNS (afin que votre machine ne révèle jamais le nom d'hôte), utilisez socks5h:// à la place. SOCKS transfère du TCP brut, ce qui lui permet de transporter n'importe quel protocole mais pas de lire ou de réécrire vos requêtes comme un proxy HTTP peut le faire.

Comment faire en sorte que cURL utilise toujours un proxy ?

Ajoutez une ligne proxy = "http://host:port" dans le fichier de configuration de cURL : ~/.curlrc sous Linux et macOS, ou _curlrc dans %APPDATA% sous Windows. Chaque commande cURL passe alors par ce proxy sans flags. Pour ignorer la configuration pour un appel, passez -q, ou utilisez --noproxy "*" pour contourner le proxy uniquement pour cette requête.

Pourquoi mon proxy renvoie-t-il des erreurs 403 ou 429 ?

Ces codes proviennent du site cible, pas de cURL ni du proxy, ce qui signifie que la connexion a fonctionné mais que l'IP de sortie a été bloquée ou limitée en débit. Une seule IP proxy est rapidement signalée sous charge. La solution est une IP différente ou tournante, soit en gérant vous-même un pool, soit en pointant cURL vers une passerelle tournante qui permute l'IP de sortie par requête.

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.