Configurer un proxy dans curl : authentification, CONNECT HTTPS et contrôles fiables

Définissez un proxy curl explicite, séparez -U de -u, faites passer le HTTPS par CONNECT sans -k, et reliez les codes de sortie à la route réellement utilisée.

Ce guide s'adresse à ceux qui ont déjà curl dans le PATH et qui ont besoin d'un saut HTTP ou SOCKS qu'ils puissent prouver. Les contrôles ci-dessous ont utilisé une origine en loopback locale et des proxies factices, pas un compte fournisseur. Top Proxy ne vend pas d'IP, et il n'y a pas de clés gratuites ici. Une page navigateur Mon IP montre la route du navigateur, pas ce processus curl.

01Lancer les contrôles sur un proxy encore actif#

Les chiffres de cet article viennent d'une mesure loopback contrôlée sur curl 8.7.1. Cette mesure est une méthodologie. Ce n'est pas un kit sur cette page, et il n'y a pas de téléchargement public.

Utilisez un curl ordinaire contre un proxy et une origine que vous avez encore en service. Le lab-user:lab-pass factice est une étiquette, pas un compte. Mettez votre hôte, votre port et votre AC réels dans la commande. Ne réutilisez pas les ports de la famille 60585 du passage enregistré. Ces points d'accès n'existaient plus une fois la mesure terminée.

curl -q -sS --noproxy '' -x http://127.0.0.1:PROXY_PORT --proxy-user lab-user:lab-pass http://127.0.0.1:ORIGIN_PORT/identity

Le HTTPS par le même saut HTTP utilise encore CONNECT. Faites confiance à l'AC qui correspond à l'origine à laquelle vous parlez maintenant.

curl -q -sS --noproxy '' -x http://127.0.0.1:PROXY_PORT --proxy-user lab-user:lab-pass --cacert ca.pem https://localhost:ORIGIN_HTTPS_PORT/identity

02Définir un proxy HTTP explicite et vérifier la route#

Démarrez curl avec -q en première option. Le man curl installé de 8.7.1 et la page de manuel de curl disent tous les deux qu'un -q en première position ignore curlrc. Les manuels en ligne peuvent décrire des drapeaux plus récents. Ce tutoriel reste sur 8.7.1. Si votre fichier rc injecte un proxy, un bundle d'AC ou --user, chaque drapeau suivant se bat contre un fantôme. Ne réécrivez pas HOME pour cacher le fichier. -q est l'isolation que le binaire vous donne déjà.

Pointez le saut avec -x / --proxy. Sans schéma, curl traite l'hôte comme un proxy HTTP. Les proxies HTTP dans everything curl décrivent le relais en forme absolue pour les cibles HTTP. Le proxy alpha du laboratoire a journalisé GET http://127.0.0.1:60585/identity puis a renvoyé le JSON d'origine. Un statut 200 à lui seul n'est pas la route. L'origine a renvoyé via_proxy_header: alpha. Un second proxy instrumenté nommé beta est resté inactif sur cet appel.

1. Exécutez curl -q --version et gardez la ligne libcurl. Ce tutoriel a utilisé curl 8.7.1, libcurl 8.7.1, SecureTransport plus LibreSSL 3.3.6. Les fonctionnalités indiquaient HTTPS-proxy. Ce drapeau concerne le TLS vers un proxy. Il ne prouve ni SOCKS, ni CONNECT.
2. Appelez l'origine une fois sans -x. Le HTTP direct a renvoyé le code de sortie 0, HTTP 200, l'id d'origine http-origin, et le proxy factice n'a rien reçu. C'est le témoin.
3. Appelez la même URL avec -x, --noproxy '' et un --proxy-user factice. --noproxy '' force le proxy même quand un NO_PROXY du shell sauterait le loopback. Le corps d'origine a nommé alpha. Le saut a consommé Proxy-Authorization. L'origine ne l'a pas vu.
4. Lisez le journal du proxy, pas seulement stdout. Des identifiants manquants sur ce montage ont renvoyé HTTP 407 avec le code de sortie curl 0, parce que --fail était désactivé.

curl -q -sS --noproxy '' -x http://127.0.0.1:PROXY_PORT --proxy-user lab-user:lab-pass http://127.0.0.1:ORIGIN_PORT/identity

PROXY_PORT et ORIGIN_PORT doivent venir d'un montage encore en service. Ce ne sont pas les ports expirés des résultats enregistrés.

De mauvais identifiants factices ont aussi renvoyé 407 et le code de sortie 0. Le montage a marqué auth: wrong. Les bons identifiants ont renvoyé l'origine 200 et auth: correct. Les caractères réservés du mot de passe factice sont passés par --proxy-user, pas par une URL collée. L'encodage URL composant par composant est l'autre voie légale. Ne mettez pas de vrais mots de passe dans argv si vous pouvez l'éviter. Les listes de processus voient encore l'argument un instant. Le manuel 8.7.1 le dit.

Si vous voulez seulement savoir si un hôte répond en HTTP, utilisez le vérificateur de proxies. C'est un outil de joignabilité. Ce n'est pas ce processus curl.

03Séparer l'authentification du proxy de celle de l'origine#

-U / --proxy-user authentifie auprès du proxy. -u / --user authentifie auprès de l'origine. L'authentification proxy dans everything curl les traite comme indépendants, volontairement. Les mélanger, c'est ainsi que l'on fuit un mot de passe de passerelle dans un login d'application, ou l'inverse.

L'origine du laboratoire servait /origin-auth avec son propre défi Basic. Une commande a envoyé un -U factice à alpha et un -u factice à l'origine. Le JSON d'origine indiquait origin_authorized: true et proxy_authorization_present: false. Le saut a consommé Proxy-Authorization. L'origine ne l'a jamais vu.

1. Placez les identifiants du proxy sur -U ou dans le userinfo de l'URL du proxy, jamais sur -u.
2. Placez les identifiants d'origine sur -u, un netrc que vous avez vraiment voulu, ou l'URL d'origine. Ce laboratoire a utilisé un netrc privé vide et pas de --netrc : un login surprise aurait été un bug.
3. Confirmez l'origine. Un 200 du proxy avec un 401 de l'origine est un échec différent d'un 407 du saut.

curl -q -sS --noproxy '' -x http://127.0.0.1:PROXY_PORT --proxy-user lab-user:lab-pass -u origin-user:origin-pass http://127.0.0.1:ORIGIN_PORT/origin-auth

HTTP 407 sans --fail a laissé curl au code de sortie 0 sur cette compilation. Ajouter -f sur le même appel sans identifiants a renvoyé HTTP 407 et le code de sortie 22. Le manuel installé prévient que 401 et 407 peuvent passer à travers --fail. Ils n'ont pas passé sur 8.7.1 dans cette exécution. N'en faites pas une règle universelle pour chaque curl futur. Enregistrez le statut, le statut CONNECT et le code de sortie séparément. --fail-with-body est le frère qui écrit encore le document. Ce n'était pas le défaut ici.

Les utilisateurs factices de cet article sont des étiquettes. Ce ne sont pas des comptes. Les traces verbeuses du laboratoire avaient les valeurs Authorization et Proxy-Authorization réduites à [REDACTED] avant qu'un fichier ne touche le disque.

04Atteindre le HTTPS par CONNECT sans désactiver le TLS#

Un site HTTPS derrière un proxy HTTP reste un proxy HTTP. curl envoie CONNECT host:port, le proxy ouvre le TCP, puis le TLS s'exécute vers l'origine à travers ce tunnel. Vous n'avez pas besoin d'un schéma de proxy https:// pour cela. Le schéma de proxy https:// est du TLS vers le proxy lui-même. everything curl sur les proxies HTTP et le chapitre proxy HTTPS tiennent ces sauts à part. Ce laboratoire n'a pas levé de proxy HTTPS. --proxy-cacert est resté non mesuré. --cacert a vérifié l'origine après CONNECT.

1. Gardez -x sur http://127.0.0.1:PORT même quand l'URL est https://localhost:PORT/identity.
2. Faites confiance à l'AC du laboratoire avec --cacert. N'ajoutez pas -k.
3. Exigez une ligne de journal CONNECT avant de faire confiance au 200. Alpha a enregistré CONNECT localhost:60586 avec auth: correct et le statut 200, puis le corps d'origine a nommé https-origin.
4. Répétez une fois sans --cacert. CONNECT a encore réussi. curl a ensuite quitté avec 60, l'échec de certificat pair TLS. Le tunnel était bon. Le certificat ne l'était pas.

curl -q -sS --noproxy '' -x http://127.0.0.1:PROXY_PORT --proxy-user lab-user:lab-pass --cacert ca.pem https://localhost:ORIGIN_HTTPS_PORT/identity

--cacert doit être l'AC d'un montage encore en service. Ne le pointez pas vers un evidence/ca.pem restant après la sortie du lanceur à usage unique, et ne réutilisez pas le chemin temporaire supprimé de l'exécution enregistrée.

Des identifiants proxy manquants sur CONNECT n'ont pas ressemblé au chemin HTTP 407 plus code de sortie 0. Le montage a quand même répondu 407 sur CONNECT. curl 8.7.1 a quitté avec 56, et le code HTTP write-out était 000. De mauvais identifiants ont fait de même. Traitez les échecs CONNECT comme du transport, pas comme un HTML 407 silencieux que vous pourrez parser plus tard.

Le HTTPS direct avec l'AC du laboratoire a renvoyé 200. Le HTTPS direct sans elle a renvoyé le code de sortie 60. Cette paire est le témoin TLS. Elle est indépendante du proxy.

Un onglet navigateur Mon IP ne montrera toujours pas ce tunnel. Si vous vouliez le navigateur, vous configureriez le navigateur.

05Comprendre les proxies d'environnement et le contournement volontaire#

curl lit http_proxy, https_proxy, all_proxy et NO_PROXY. Les variables d'environnement de proxy sont claires sur le piège CGI. Les en-têtes Proxy: entrants deviennent HTTP_PROXY en majuscules. curl n'accepte donc que http_proxy en minuscules pour HTTP. HTTPS_PROXY et ALL_PROXY en majuscules restent valides pour leurs schémas.

Le laboratoire a démarré chaque enfant depuis un environnement propre. Il a retiré les deux casses des variables de proxy, les restes CGI REQUEST_METHOD, CURL_CA_BUNDLE, SSL_CERT_FILE, SSL_CERT_DIR, SSLKEYLOGFILE et REQUESTS_CA_BUNDLE. Puis il a injecté une valeur factice nommée à la fois. curl n'a pas d'interrupteur trust_env=. Le trust_env=False de Requests change aussi la recherche d'AC et de netrc. Ne copiez pas ce drapeau sur curl. -q plus un environnement enfant propre est l'isolation équivalente.

1. Définissez http_proxy en minuscules vers alpha, passez --proxy-user, et ajoutez --noproxy ''. L'origine a nommé alpha. C'est le routage par l'environnement seul.
2. Définissez HTTP_PROXY en majuscules vers la même URL alpha et omettez -x. L'origine est revenue en direct. Le compteur d'événements d'alpha n'a pas bougé. C'est la convention de sécurité documentée, mesurée sur ce binaire.
3. Définissez http_proxy vers alpha et passez un -x explicite vers beta. L'origine a nommé beta. Alpha n'était pas le saut sélectionné. Deux identités de proxy battent une conjecture « 200 venu de quelque part ».
4. Définissez http_proxy vers alpha et NO_PROXY=127.0.0.1 sans --noproxy ''. L'origine était directe et alpha est resté inactif. C'est le cas de contournement, exécuté exprès.
5. Gardez NO_PROXY=127.0.0.1 et ajoutez --noproxy ''. La liste vide remplace la variable, comme le dit le manuel 8.7.1 depuis 7.53.0. L'origine a de nouveau nommé alpha.

Ne déduisez jamais le saut d'un HTTP 200. Succès direct et succès proxifié se ressemblent dans le corps, sauf si vous avez tamponné la route. Le montage a tamponné X-Lab-Proxy sur le HTTP relayé. CONNECT ne peut pas tamponner l'origine à l'intérieur du TLS, donc le journal CONNECT est la preuve.

06Comparer SOCKS5 et SOCKS5h avec la preuve de la négociation#

SOCKS n'est pas un relais HTTP et ce n'est pas CONNECT. Le chapitre SOCKS d'everything curl garde le tableau court. SOCKS5 résout en local. SOCKS5h envoie le nom d'hôte au proxy. --socks5 et --socks5-hostname sont les formes drapeau. socks5:// et socks5h:// sur -x sont les formes URL.

Le curl 8.7.1 d'Apple omet socks de la liste des protocoles et livre quand même les options de proxy SOCKS. Une requête SOCKS réussie n'est pas une preuve de l'endroit où le DNS s'est produit. L'ATYP de la négociation l'est.

1. --socks5 127.0.0.1:PORT vers http://127.0.0.1:ORIGIN/identity s'est terminé avec HTTP 200. Le montage a enregistré ATYP ipv4 et l'adresse 127.0.0.1.
2. --socks5-hostname 127.0.0.1:PORT vers http://lab.curl-fixture.test:ORIGIN/identity s'est terminé avec HTTP 200. Le montage a enregistré ATYP domain et l'adresse lab.curl-fixture.test. Le proxy a mappé ce nom d'hôte de laboratoire vers loopback. Ce mapping est de la plomberie du montage, pas une fuite mesurée vers le DNS public.
3. Arrêtez-vous là. Cet article ne revendique pas une capture de résolveur externe.

curl -q -sS --noproxy '' --socks5-hostname 127.0.0.1:SOCKS_PORT http://lab.curl-fixture.test:ORIGIN_PORT/identity

La documentation des fournisseurs suit la même scission. Les protocoles résidentiels Oxylabs documentent socks5h://pr.oxylabs.io:7777 comme passant le nom d'hôte, et socks5:// comme passant une IP résolue. Les protocoles résidentiels Decodo, encore listés dans le catalogue comme Smartproxy, documentent socks5h:// sur gate.decodo.com:7000 et disent que les hôtes pays tels que us.decodo.com ne fonctionnent pas pour SOCKS5. Ce sont des notes d'adéquation documentées. Ce n'est pas cette exécution loopback.

Le protocole n'est pas le type d'IP. Les pages mobile et résidentiel décrivent des pools de sortie. SOCKS5 contre HTTP est la négociation du client. Vous pouvez avoir un saut HTTP résidentiel ou un saut SOCKS datacenter. Ne confondez pas ces deux axes.

07Distinguer l'échec de connexion du délai de transfert#

--connect-timeout borne le DNS plus le TCP plus, pour le TLS, la négociation. --max-time borne tout le transfert. Les délais dans everything curl disent que --max-time se déclenche encore pendant que les données bougent. Le code de sortie 28 est ce minuteur. Ce n'est pas un délai de lecture façon Requests.

Ce laboratoire n'a pas mesuré de délai de connexion et n'a pas capturé de paquets. Le code de sortie 7 est venu d'une connexion TCP vers un port loopback éphémère détenu par un socket UDP. curl a affiché Couldn't connect to server avec le code HTTP 000. C'est une erreur de connexion. Ce n'est pas le code de sortie 28.

Le chemin du corps retardé est l'autre forme. /slow-body a envoyé les en-têtes complets immédiatement, a vidé le premier octet de corps H, puis a attendu au-delà de --max-time 1.5 avant le reste. curl a rapporté HTTP 200, pas 000, et a quitté avec 28. L'événement first-byte de l'origine était posé. Alpha avait relayé GET .../slow-body. C'est un délai de transfert après le début du corps.

1. Pour un saut mort, attendez-vous à une erreur de connexion. Ici, c'était le code de sortie 7 contre un port loopback détenu.
2. Pour un corps lent, exigez les en-têtes et un premier octet, puis --max-time, puis le code de sortie 28 avec un vrai HTTP 200. Le code 000 aurait fait échouer l'assertion.
3. Laissez --connect-timeout comme documenté sauf si vous bloquez réellement la négociation. Cette exécution ne l'a pas fait.

curl -q -sS --noproxy '' -x http://127.0.0.1:PROXY_PORT --proxy-user lab-user:lab-pass --max-time 1.5 http://127.0.0.1:ORIGIN_PORT/slow-body

Les nouvelles tentatives sont un réglage à part. --retry réinitialise le compteur --max-time à chaque tentative sur 8.7.1. Bornez la fenêtre de nouvelle tentative avec --retry-max-time si vous l'activez. Ne traitez pas un drapeau de nouvelle tentative comme une idempotence pour POST.

08Choisir un point d'accès d'après le protocole et l'authentification documentés#

Choisissez le saut comme le fournisseur le documente, puis prouvez curl contre un montage que vous possédez. Les passerelles payantes n'ont pas été appelées. Le ciblage pays, le folklore anti-bot et les classements du « meilleur service » sont hors périmètre.

Les protocoles résidentiels Oxylabs, récupérés le 14 octobre 2026, placent HTTP sur pr.oxylabs.io:7777 avec -U customer-USERNAME:PASSWORD. La même page ajoute https://pr.oxylabs.io:7777 quand vous voulez du TLS vers la passerelle, et socks5h://pr.oxylabs.io:7777 quand le proxy doit voir le nom d'hôte. SOCKS5 n'utilise pas d'hôtes d'entrée spécifiques au pays sur cette page.

Les protocoles résidentiels Decodo, le même jour, placent HTTP sur gate.decodo.com:7000 et SOCKS5h sur le même hôte. Comparez ces schémas documentés sur les fiches anglaises en direct d'Oxylabs et Smartproxy / Decodo. C'est l'adéquation au catalogue, pas un test de passerelle.

1. Faites correspondre le schéma au support du client. curl 8.7.1 ici parlait relais HTTP, CONNECT, SOCKS5 et SOCKS5h. Le TLS vers un proxy HTTPS reste une ligne documentation seulement.
2. Faites correspondre l'authentification à -U, avec les préfixes d'identifiant que le fournisseur documente. Le -u d'origine reste hors de cette chaîne.
3. Contrôlez le saut avec le vérificateur de proxies si vous avez seulement besoin de HTTP contre SOCKS sur un hôte. Contrôlez l'IP de sortie dans curl, pas dans un onglet navigateur. Prouvez le saut sur un proxy encore actif que vous possédez avant de pointer curl vers un point d'accès payant.

Oxylabs — proxies résidentiels et datacenter4.0771

Oxylabs vend des proxies résidentiels, mobiles, ISP et datacenter sous un seul abonnement mensuel dès $30. Paiements acheteur : cartes, virement, AliPay, PayPal.

10 pays

0,45 $US

par 1 GB

Decodo (Smartproxy) — proxies résidentiels et datacenter4.22118

Decodo (anciennement Smartproxy) vend des proxies résidentiels et datacenter. Résidentiel : $4/GB sans forfait mensuel, ou packs mensuels dès $3.75/GB pour 3 GB. Paiements : cartes, PayPal, Alipay, Google/Apple Pay, crypto (avec limites).

83 pays

0,38 $US

par 1 GB