Comment utiliser cURL avec un proxy : HTTP, HTTPS, SOCKS, authentification et solutions

Remplacez le paramètre de proxy par l’hôte et le port fournis par votre service de proxy. Commencez par interroger un point de terminaison de vérification d’IP fiable pour obtenir l’adresse publique visible sans proxy :

curl "https://api.ipify.org"

Envoyez maintenant la même requête via le proxy :

curl --proxy "http://proxy.example:8080" "https://api.ipify.org"

-x est la forme abrégée de --proxy, cette commande cURL avec proxy est donc équivalente :

curl -x "http://proxy.example:8080" "https://api.ipify.org"

Un deuxième résultat différent confirme généralement que la requête est sortie via une autre adresse. S’il reste inchangé, ne concluez pas pour autant que le proxy est défaillant. Vérifiez si le point de terminaison, le type de proxy, la politique réseau ou le fournisseur utilise une adresse IP de sortie fixe. Il est utile de consulter une liste de contrôle plus complète sur la manière de tester les proxys avant d’intégrer le proxy à votre automatisation.

Si curl --version échoue, passez à la section consacrée à l’installation de la plateforme, puis revenez ici.

Pour l’authentification du proxy avec cURL, placez les identifiants dans l’URL ou transmettez-les séparément :

curl -x "http://demo-user:demo-pass@proxy.example:8080" "https://api.ipify.org"

curl -x "http://proxy.example:8080" \
  --proxy-user "demo-user:demo-pass" \
  "https://api.ipify.org"

Utilisez des espaces réservés fictifs dans la documentation et mettez entre guillemets chaque argument contenant des identifiants. --proxy-user Cela permet d’éviter que les identifiants n’apparaissent dans l’URL du proxy, mais ne rend pas la ligne de commande confidentielle. Pour les mots de passe contenant @, :, %, des espaces ou des métacaractères de shell, vérifiez les règles d’échappement ou d’encodage en pourcentage pour votre shell et votre version de cURL avant toute utilisation en production.

Chaque commande cURL avec une requête via un proxy désigne deux points de terminaison distincts :

curl --proxy "http://proxy.example:8080" "https://target.example/resource"

La valeur après --proxy est l’URL du proxy. Elle indique à cURL où se trouve l’intermédiaire et comment s’y connecter. Le dernier argument est l’URL de destination, qui identifie l’API, la page ou le fichier que vous souhaitez réellement obtenir.

D’un point de vue conceptuel, cURL envoie la requête via le proxy, et le proxy la transmet vers la destination. Modifier le schéma du proxy change la manière dont cURL atteint cet intermédiaire. Modifier la destination change la ressource demandée. Les identifiants du proxy relèvent des paramètres du proxy, et non de l’URL de destination.

Le fait de séparer ces rôles permet d’éviter une erreur courante : modifier le schéma de destination alors que l’on souhaitait modifier le protocole du proxy. Cela rend également l’analyse des journaux plus sûre, car vous pouvez masquer la valeur du proxy contenant les identifiants sans cacher la cible testée.

Une adresse authentifiée se présente sous la forme suivante :

protocol://username:password@host:port

protocol sélectionne HTTP, HTTPS ou une variante SOCKS. host et port indique l’emplacement du proxy. Le nom d’utilisateur et le mot de passe, facultatifs, autorisent l’utilisation de ce proxy. Si vous omettez le schéma, cURL considère le proxy comme HTTP, mais le mentionner explicitement facilite la lecture des scripts.

Les schémas de destination et de proxy sont indépendants. Par exemple, cette commande accède à une destination HTTPS via un proxy HTTP :

curl --proxy "http://proxy.example:8080" "https://target.example/api"

Une https:// URL de proxy signifie que la connexion client-proxy elle-même utilise TLS. Cela ne signifie pas que la destination doit également utiliser HTTPS. Si une authentification est requise, ajoutez --proxy-user "USER:PASS" plutôt que de confondre les identifiants du proxy avec ceux de la destination. Mettez les deux URL entre guillemets, en particulier lorsqu’elles contiennent des chaînes de requête ou des caractères sensibles au shell.

Ce tableau rassemble en un seul endroit les principaux schémas d'utilisation de cURL avec un proxy :

Utiliser -x ou --proxy de manière cohérente dans un script. Ces options sont équivalentes, mais la forme longue est généralement plus claire dans le cadre d'une automatisation partagée. N'oubliez pas que les options cURL sont sensibles à la casse.

Un proxy SOCKS5 cURL peut utiliser -x, et cURL fournit également des options SOCKS dédiées :

curl -x "socks4://proxy.example:1080" "https://target.example"
curl -x "socks5://proxy.example:1080" "https://target.example"
curl -x "socks5h://proxy.example:1080" "https://target.example"
curl --socks5 "proxy.example:1080" --proxy-user "USER:PASS" "https://target.example"

Pour la résolution des noms d’hôtes, socks5:// et --socks5 résolvent normalement le nom de destination localement, tandis que socks5h:// et --socks5-hostname demandent au proxy de le résoudre. De la même manière, SOCKS4a ajoute la résolution de nom d’hôte côté proxy à SOCKS4. Cette distinction est importante lorsque le DNS local ne parvient pas à résoudre la cible ou lorsque vous souhaitez que les requêtes DNS suivent le chemin du proxy.

Consultez le manuel officiel de la ligne de commande cURL en vous référant à la version indiquée par curl --version avant de vous fier à un comportement SOCKS dépendant de la version en production.

Lorsque vous décidez comment configurer le proxy dans cURL, choisissez la portée la plus restreinte adaptée à la tâche. Un indicateur ponctuel est plus facile à auditer, tandis que les variables d’environnement et les fichiers de configuration réduisent les répétitions.

Sous macOS, Linux et autres shells de type POSIX, exportez les variables en minuscules :

export http_proxy="http://USER:PASS@proxy.example:8080"
export https_proxy="http://USER:PASS@proxy.example:8080"

curl "https://target.example"

unset http_proxy
unset https_proxy

Le nom de la variable suit le schéma de l'URL de destination. Par conséquent, https_proxy peut toujours contenir une http:// URL de proxy. Ces variables d’environnement de proxy cURL affectent le shell actuel et ses processus enfants, et non toutes les applications ou tous les utilisateurs.

PowerShell et l’Invite de commandes utilisent une syntaxe différente pour les variables d’environnement. Privilégiez les noms en minuscules pour des raisons de portabilité, et vérifiez la capitalisation dans la version exacte du shell et de cURL que vous déployez. Les variables plus générales telles que ALL_PROXY et NO_PROXY doivent faire l’objet de tests spécifiques à chaque version.

Un fichier de configuration cURL applique des valeurs par défaut à cURL sans rediriger les programmes non concernés. Les emplacements courants pour les utilisateurs sont ~/.curlrc sous Linux et macOS et _curlrc sous %APPDATA% sous Windows :

proxy = "http://USER:PASS@proxy.example:8080"

Considérez ce fichier comme confidentiel s’il contient des identifiants. Sur les systèmes de type Unix, utilisez chmod 600 ~/.curlrc; sous Windows, limitez sa liste d'accès (ACL) au compte prévu. Une instruction explicite --proxy peut remplacer le proxy configuré pour une commande.

Les emplacements de recherche de la configuration et leur ordre de priorité peuvent varier selon la version et le contexte d’exécution ; vérifiez-les donc avant de vous fier à une valeur par défaut cachée dans l’environnement CI.

<!-- Recherches supplémentaires nécessaires : vérifier la casse et la correspondance de ALL_PROXY/NO_PROXY, la recherche dans les fichiers de configuration et la priorité complète des paramètres de proxy pour les versions de cURL et les systèmes d’exploitation pris en charge. -->

Pour utiliser un proxy différent pour une requête, indiquez-le explicitement :

curl --proxy "http://alternate-proxy.example:8080" "https://target.example"

Pour forcer une connexion directe malgré les variables d’environnement ou un fichier de configuration cURL, utilisez le contournement de tous les hôtes basé sur la source :

curl --noproxy "*" "https://target.example"

Cette utilisation de cURL avec contournement du proxy est plus sûre que la suppression temporaire d’une configuration que vous pourriez oublier de restaurer. cURL prend également en charge des règles de contournement sélectives via des options de commande et des paramètres d’environnement, mais la correspondance des noms d’hôte, des domaines et des adresses peut s’avérer délicate. Testez-les avec la version de cURL utilisée en production plutôt que de supposer que le NO_PROXY s’applique partout.

Une passerelle de proxys rotatifs conserve une seule adresse de connexion tout en sélectionnant une adresse IP de sortie parmi un pool pour chaque requête ou selon une politique définie par le fournisseur :

curl -x "http://USER:PASS@gateway.example:8000" "https://target.example/page/1"
curl -x "http://USER:PASS@gateway.example:8000" "https://target.example/page/2"

Cela facilite la création de scripts pour un workflow cURL avec proxy rotatif, car la rotation s’effectue en arrière-plan de la passerelle. Cela ne garantit pas l’accès, n’empêche pas la limitation de débit et ne rend pas acceptable un scraper agressif. Vous devez toujours veiller à une concurrence raisonnable, à des tentatives de reconnexion, à un rythme de requêtes adapté, à des sessions stables lorsque cela est nécessaire, et au respect des règles de la destination. Pour une discussion plus approfondie sur la conception, les proxys rotatifs pour le scraping web constituent un sujet utile à aborder ensuite.

Lorsqu’un proxy cURL ne fonctionne pas, commencez par la plus petite requête ayant échoué et activez les diagnostics détaillés :

curl --verbose --proxy "http://proxy.example:8080" "https://target.example"

Nettoyez les sorties détaillées avant de les partager, car elles peuvent révéler des noms d’hôtes, des en-têtes ou des informations d’authentification. Travaillez ensuite en fonction des symptômes plutôt que de modifier plusieurs options à la fois.

Comparez les vérifications d’IP directes et via proxy, puis essayez une destination connue et accessible. curl -I "URL" En-têtes des requêtes ; des en-têtes de réponse HTTP plus complets dans le workflow cURL peuvent révéler des redirections, des défis d’authentification et des métadonnées de limitation de débit. Une référence aux erreurs d’état de proxy est utile lorsqu’un intermédiaire renvoie sa propre réponse.

Ne posez pas de diagnostic en vous basant uniquement sur un code d’état ou un code de sortie. Des symptômes similaires peuvent apparaître à différents sauts. Consultez le manuel d’installation ou le manuel officiel de cURL pour connaître la signification exacte des codes de sortie et des indicateurs de diagnostic dans votre version.

Ne publiez jamais de noms d’utilisateur, de mots de passe ou de jetons de proxy en production. Utilisez des espaces réservés dans les exemples, mettez les arguments entre guillemets et n’oubliez pas que l’historique des commandes, l’inspection des processus, les journaux d’intégration continue, les sauvegardes d’environnement et les sauvegardes de configuration peuvent exposer des informations confidentielles. --proxy-user Cela améliore la lisibilité, mais pas la confidentialité. Privilégiez un gestionnaire de secrets, une variable d’exécution protégée ou une invite interactive lorsque votre workflow le permet.

Si une requête cURL via un proxy échoue à la validation du certificat, corrigez la chaîne de confiance ou fournissez les éléments de l’autorité de certification (CA) de confiance appropriés. Le -k option « or » --insecure désactive la vérification des certificats ; réservez-la donc à des diagnostics courts et contrôlés. Elle ne doit pas devenir la solution de routine en production. Avec un proxy HTTPS, identifiez quelle connexion TLS a échoué avant de choisir une mesure corrective, car le proxy et la destination constituent des contextes de validation de certificats distincts.

Exécutez curl --version ; chaque commande cURL via un proxy nécessite un exécutable fonctionnel. Windows fournit souvent curl.exe, mais sa disponibilité et sa résolution dans PowerShell varient selon la version et le profil. Utilisez Get-Command curl et curl.exe --version; s’il manque, utilisez les téléchargements officiels de cURL pour Windows.

Sous macOS, effectuez l'installation avec brew install curl. Sous Ubuntu ou Debian, utilisez sudo apt install curl.

Utilisez cette référence des commandes cURL pour les proxys, en remplaçant chaque variable en majuscules.

• Commencez chaque commande cURL par une configuration de proxy en comparant les résultats obtenus avec l’adresse IP publique directe et ceux obtenus via le proxy. Cela permet de distinguer les problèmes de routage des échecs liés à la destination.
• Considérez l’URL du proxy et l’URL de destination comme des valeurs indépendantes. Le schéma de chacune d’elles détermine une décision de connexion différente.
• Utilisez --proxy pour les requêtes isolées, des variables d’environnement shell pour les workflows temporaires, et un fichier de configuration cURL protégé pour des paramètres par défaut stables au niveau de l’utilisateur.
• Optez socks5h:// lorsque la résolution du nom d’hôte côté proxy est requise, et vérifiez le comportement par rapport à la version de cURL déployée en production.
• Diagnostiquez l’authentification, la connectivité, le DNS, le TLS et les réponses de destination comme des étapes distinctes. Ne procédez pas à -k de correction permanente du certificat.

Non. Un proxy HTTP peut acheminer une requête vers une destination HTTPS. Le schéma d’URL du proxy décrit la manière dont cURL se connecte au proxy, tandis que le schéma de destination décrit la ressource demandée. Choisissez un proxy HTTPS lorsque vous avez spécifiquement besoin de TLS sur la connexion client-proxy, et non simplement parce que l’URL cible commence par https://.

Oui. -x est la forme abrégée de --proxy, et les deux fournissent l’adresse du proxy pour cette requête. L’option longue est plus facile à lire dans les scripts et les configurations d’intégration continue (CI), tandis que l’option courte est pratique en ligne de commande. Les options sont sensibles à la casse ; ainsi, -x ne doit pas être remplacée par sa variante en majuscules.

Utilisez curl --noproxy "*" "https://target.example". L’astérisque entre guillemets indique à cURL de ne pas utiliser de proxy pour toutes les destinations de cette commande, même lorsqu’un proxy est défini via des variables d’environnement ou un fichier de configuration. Les guillemets empêchent également le shell de développer * en noms de fichiers locaux.

cURL lit généralement .curlrc le répertoire personnel de l’utilisateur sous Linux et macOS et _curlrc dans un emplacement de configuration utilisateur Windows tel que %APPDATA%. Les chemins de recherche exacts peuvent varier selon la version et le contexte d’exécution. Consultez le manuel de la version que vous avez installée et protégez tout fichier contenant des identifiants de proxy.

La méthode la plus fiable pour utiliser cURL avec un proxy consiste à définir explicitement la configuration et à tester chaque couche indépendamment. Commencez par curl --version, effectuez une vérification directe de l’adresse IP publique, répétez l’opération avec --proxy, puis ajoutez seulement ensuite les identifiants ou la persistance. Séparez l’URL du proxy de celle de la destination, choisissez le protocole en fonction de la manière dont vous devez accéder au proxy, et utilisez SOCKS5h lorsque la résolution du nom d’hôte de destination doit s’effectuer côté proxy.

Pour un travail reproductible, adaptez la portée de la configuration à la tâche. Les options de commande sont les plus sûres pour les opérations ponctuelles, les variables d’environnement conviennent aux workflows shell temporaires, et un fichier de configuration verrouillé permet d’éliminer les répétitions liées aux valeurs par défaut de cURL. Lorsqu’une requête échoue, isolez les réponses relatives à l’authentification, à l’accessibilité, au DNS, au TLS et à la destination au lieu d’essayer des options au hasard. En particulier, considérez -k comme une exception de diagnostic contrôlée, et non comme une valeur par défaut en production.

Si un pipeline de scraping consacre plus de temps d’ingénierie à la rotation des proxys, aux CAPTCHA et aux requêtes bloquées qu’à l’analyse du code HTML renvoyé, WebScrapingAPI fournit une API de scraping qui gère ces problèmes au niveau de la couche des requêtes et renvoie du code HTML brut, la facturation étant liée à la réussite de l’extraction. Il s’agit d’une étape pratique à franchir lorsque la configuration manuelle d’un proxy cURL cesse d’être l’option la plus légère.