Pourquoi curl se connecte à localhost au lieu de l'URL distante

Si curl tente de se connecter à localhost quelle que soit l'URL que vous lui avez donnée, le VPN est le mauvais point de départ. Un proxy HTTP ou SOCKS local peut être la première connexion prévue, même lorsque le service que vous voulez se trouve ailleurs. Si ce proxy ne tourne plus, la tentative vers localhost échoue avant que curl n'atteigne la destination. Une réponse du proxy ne prouve pas non plus que la destination a répondu.

Suivez ces étapes dans l'ordre et arrêtez-vous à la première qui modifie la première tentative de connexion.

Lisez d'abord les règles de proxy propres à curl

curl lit des variables de proxy propres au protocole, comme https_proxy et HTTPS_PROXY, ainsi que ALL_PROXY lorsqu'aucune valeur propre au protocole ne s'applique. Inspectez l'environnement du shell, du service ou de la tâche qui lance réellement curl, et non celui de votre terminal courant. Une tâche CI, une unité systemd et un shell interactif peuvent hériter de trois ensembles différents. Deviner à partir du shell visible est précisément ce qui fait perdre un après-midi entier à cette enquête.

Une exception mérite d'être mémorisée. curl accepte http_proxy uniquement en minuscules ; la version en majuscules HTTP_PROXY est ignorée, ce qui explique pourquoi le même environnement se comporte différemment dans d'autres outils.

Lisez les valeurs en privé, car une URL de proxy porte souvent des identifiants.

Vérifiez ensuite le fichier de configuration par défaut de curl pour y chercher des substitutions de proxy ou de connexion, et confirmez quel exécutable vous lancez réellement. Un alias de shell, une fonction ou un script d'enveloppe peut ajouter des options qui n'apparaissent jamais sur votre ligne de commande.

Comparez trois appels avec TLS activé

Utilisez une destination de diagnostic approuvée et le même binaire pour les trois exécutions.

curl -v https://service.corp.example/status
curl -q -v https://service.corp.example/status
curl -q --proxy '' -v https://service.corp.example/status

-q supprime le curlrc par défaut et doit être le premier paramètre de la ligne pour fonctionner. Il ne retire pas les variables d'environnement de proxy, ce qui surprend ceux qui l'attendent. La troisième forme ajoute une valeur vide de --proxy, en remplaçant le proxy demandé par l'environnement pour cet appel uniquement. Comparez la première tentative de connexion dans chaque sortie, pas le code d'état final.

La sortie détaillée peut exposer des en-têtes, des jetons et des identifiants de proxy, alors gardez-la en local et lisez des extraits avant de la partager.

Ce que chaque résultat écarte

Si omettre la configuration par défaut change la connexion, la source est le fichier de configuration. Si désactiver explicitement le proxy hérité la change, la source est la variable d'environnement. Si ni l'un ni l'autre ne la change et que localhost apparaît toujours, examinez les substitutions de connexion de la ligne de commande, la résolution des noms d'hôte et l'exécutable choisi. Chacun a une correction différente, et aucune n'est un changement de routage.

Le chargement de bibliothèques personnalisées ou un comportement réseau injecté est une couche ultérieure, et une variable d'environnement seule n'en est pas la preuve.

Gardez la décision de proxy séparée du VPN

Une fois que curl choisit une destination directe, le système d'exploitation route toujours cette connexion. Désactiver un proxy applicatif ne désactive pas la route du VPN ni sa politique de filtrage. Ne faites des comparaisons d'accès direct que là où ce diagnostic est autorisé. Un test qui contourne discrètement la politique n'est pas un résultat valide, c'est un incident.

Si un proxy local est requis, restaurez son service et son adresse au lieu de supprimer ses réglages.

Si seules certaines destinations privées ont besoin d'un accès direct, ajoutez une exclusion étroite et approuvée, et conservez le proxy pour tout le reste. Conservez la première erreur du chemin choisi, car un refus de localhost, un refus de CONNECT par le proxy, une défaillance de certificat et une erreur d'autorisation désignent quatre étapes différentes.