Per què curl es connecta a localhost en lloc de l'URL remot

Si curl intenta connectar-se a localhost independentment de l'URL que li doneu, la VPN és el lloc equivocat per començar. Un proxy HTTP o SOCKS local pot ser la primera connexió prevista, fins i tot quan el servei que voleu és en un lloc completament diferent. Si aquest proxy ja no s'executa, l'intent a localhost falla abans que curl arribi mai a la destinació. A més, una resposta del proxy no demostra que la destinació hagi respost.

Seguiu aquests passos en ordre i atureu-vos al primer que canviï el primer intent de connexió.

Llegiu primer les regles de proxy del mateix curl

curl llegeix variables de proxy específiques del protocol, com ara https_proxy i HTTPS_PROXY, a més de ALL_PROXY quan no s'aplica cap valor específic del protocol. Inspeccioneu l'entorn de l'intèrpret, el servei o la tasca que realment llança curl, no el del vostre terminal actual. Una feina de CI, una unitat de systemd i un intèrpret interactiu poden heretar tres conjunts diferents. Endevinar-ho a partir de l'intèrpret visible és com aquesta investigació perd una tarda sencera.

Val la pena memoritzar una excepció. curl accepta http_proxy només en minúscules; la versió en majúscules HTTP_PROXY s'ignora, i per això el mateix entorn es comporta de manera diferent en altres eines.

Llegiu els valors de manera privada, perquè un URL de proxy sovint porta credencials.

Després reviseu el fitxer de configuració predeterminat de curl per si té substitucions de proxy o de connexió, i confirmeu quin executable esteu executant realment. Un àlies de l'intèrpret, una funció o un script embolcall poden afegir opcions que mai no apareixen a la línia d'ordres.

Compareu tres invocacions amb TLS activat

Feu servir una destinació de diagnòstic aprovada i el mateix binari per a les tres execucions.

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 suprimeix el curlrc predeterminat i ha de ser el primer paràmetre de la línia per funcionar. No elimina les variables d'entorn de proxy, cosa que sorprèn qui espera justament això. La tercera forma afegeix un valor buit de --proxy, substituint el proxy sol·licitat per l'entorn només per a aquesta invocació. Compareu el primer intent de connexió de cada sortida, no el codi d'estat final.

La sortida detallada pot exposar capçaleres, testimonis i credencials de proxy, així que mantingueu-la en local i llegiu-ne fragments abans de compartir-la.

Què descarta cada resultat

Si ometre la configuració predeterminada canvia la connexió, la font és el fitxer de configuració. Si desactivar explícitament el proxy heretat la canvia, la font és la variable d'entorn. Si cap de les dues la canvia i localhost encara apareix, mireu les substitucions de connexió de la línia d'ordres, la resolució de noms d'amfitrió i l'executable seleccionat. Cadascuna té una solució diferent, i cap d'elles no és un canvi d'encaminament.

La càrrega de biblioteques personalitzades o el comportament de xarxa injectat és una capa posterior, i una variable d'entorn sola no en és cap prova.

Manteniu la decisió del proxy separada de la VPN

Un cop curl tria una destinació directa, el sistema operatiu encara encamina aquesta connexió. Desactivar un proxy d'aplicació no desactiva la ruta de la VPN ni la seva política de filtratge. Feu comparacions d'accés directe només on aquest diagnòstic estigui autoritzat. Una prova que eludeix la política en silenci no és un resultat vàlid, és un incident.

Si cal un proxy local, restaureu-ne el servei i l'adreça en lloc de suprimir-ne la configuració.

Si només algunes destinacions privades necessiten accés directe, afegiu una exclusió estreta aprovada i manteniu el proxy per a tota la resta. Conserveu el primer error del camí triat, perquè un rebuig de localhost, un rebuig de CONNECT del proxy, un error de certificat i un error d'autorització identifiquen quatre etapes diferents.