Por que curl se conecta a localhost en lugar do URL remoto

Se curl tenta conectarse a localhost independentemente do URL que lle deu, a VPN é o lugar equivocado para comezar. Un proxy HTTP ou SOCKS local pode ser a primeira conexión prevista, mesmo cando o servizo que quere está noutro lugar completamente distinto. Se ese proxy xa non se executa, o intento a localhost falla antes de que curl chegue sequera ao destino. Ademais, unha resposta do proxy non demostra que o destino respondese.

Siga estes pasos en orde e detéñase no primeiro que cambie o primeiro intento de conexión.

Lea primeiro as regras de proxy do propio curl

curl le variables de proxy específicas do protocolo, como https_proxy e HTTPS_PROXY, ademais de ALL_PROXY cando non se aplica ningún valor específico do protocolo. Inspeccione o ambiente do intérprete, o servizo ou a tarefa que realmente lanza curl, non o da súa terminal actual. Un traballo de CI, unha unidade de systemd e un intérprete interactivo poden herdar tres conxuntos distintos. Supoñelo a partir do intérprete visible é xustamente o que fai que esta investigación perda unha tarde enteira.

Vale a pena memorizar unha excepción. curl acepta http_proxy só en minúsculas; a versión en maiúsculas HTTP_PROXY ignórase, e por iso o mesmo ambiente compórtase de forma distinta noutras ferramentas.

Lea os valores en privado, porque un URL de proxy adoita levar credenciais.

Despois revise o ficheiro de configuración predeterminado de curl por se contén anulacións de proxy ou de conexión, e confirme que executábel está executando en realidade. Un alias do intérprete, unha función ou un script envoltorio poden engadir opcións que nunca aparecen na súa liña de ordes.

Compare tres invocacións con TLS activado

Use un destino de diagnóstico aprobado e o mesmo binario para as tres execucións.

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 suprime o curlrc predeterminado e debe ser o primeiro parámetro da liña para funcionar. Non elimina as variables de ambiente de proxy, o que sorprende a quen espera exactamente iso. A terceira forma engade un valor baleiro de --proxy, substituíndo o proxy solicitado polo ambiente só para esa invocación. Compare o primeiro intento de conexión de cada saída, non o código de estado final.

A saída detallada pode expor cabeceiras, tokens e credenciais de proxy, así que mantéñaa en local e lea fragmentos antes de compartila.

Que descarta cada resultado

Se omitir a configuración predeterminada cambia a conexión, a fonte é o ficheiro de configuración. Se desactivar explicitamente o proxy herdado a cambia, a fonte é a variable de ambiente. Se ningunha das dúas a cambia e localhost segue aparecendo, revise as anulacións de conexión da liña de ordes, a resolución de nomes de host e o executábel seleccionado. Cada unha ten unha solución distinta, e ningunha delas é un cambio de encamiñamento.

A carga de bibliotecas personalizadas ou o comportamento de rede inxectado é unha capa posterior, e unha variable de ambiente por si soa non é proba diso.

Manteña a decisión do proxy aparte da VPN

Unha vez que curl elixe un destino directo, o sistema operativo segue encamiñando esa conexión. Desactivar un proxy de aplicación non desactiva a ruta da VPN nin a súa política de filtrado. Faga comparacións de acceso directo só onde ese diagnóstico estea autorizado. Unha proba que elude a política en silencio non é un resultado válido, é un incidente.

Se se require un proxy local, restaure o seu servizo e o seu enderezo en lugar de borrar os seus axustes.

Se só algúns destinos privados necesitan acceso directo, engada unha exclusión estreita e aprobada, e conserve o proxy para todo o demais. Garde o primeiro erro do camiño elixido, porque un rexeitamento de localhost, un rexeitamento de CONNECT do proxy, un fallo de certificado e un erro de autorización identifican catro etapas distintas.