Por que o curl se conecta a localhost em vez da URL remota

Se o curl tenta ligar-se a localhost independentemente da URL que lhe deu, a VPN é o lugar errado para começar. Um proxy HTTP ou SOCKS local pode ser a primeira ligação prevista, mesmo quando o serviço que pretende está noutro sítio completamente diferente. Se esse proxy já não estiver a correr, a tentativa para localhost falha antes de o curl chegar ao destino. Além disso, uma resposta do proxy não prova que o destino respondeu.

Siga estes passos por ordem e pare no primeiro que altere a primeira tentativa de ligação.

Leia primeiro as regras de proxy do próprio curl

O curl lê variáveis de proxy específicas do protocolo, como https_proxy e HTTPS_PROXY, além de ALL_PROXY quando não se aplica qualquer valor específico do protocolo. Inspecione o ambiente da shell, do serviço ou da tarefa que realmente lança o curl, e não o do seu terminal atual. Uma tarefa de CI, uma unidade systemd e uma shell interativa podem herdar três conjuntos diferentes. É precisamente adivinhar a partir da shell visível que faz esta investigação perder uma tarde inteira.

Vale a pena memorizar uma exceção. O curl aceita http_proxy apenas em minúsculas; a versão em maiúsculas HTTP_PROXY é ignorada, e é por isso que o mesmo ambiente se comporta de forma diferente noutras ferramentas.

Leia os valores em privado, porque uma URL de proxy transporta frequentemente credenciais.

Depois verifique o ficheiro de configuração predefinido do curl para substituições de proxy ou de ligação, e confirme qual executável está realmente a executar. Um alias da shell, uma função ou um script envolvente podem acrescentar opções que nunca aparecem na sua linha de comandos.

Compare três invocações com TLS ativado

Use um destino de diagnóstico aprovado e o mesmo binário nas três execuções.

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 predefinido e tem de ser o primeiro parâmetro da linha para funcionar. Não remove as variáveis de ambiente de proxy, o que surpreende quem espera isso mesmo. A terceira forma acrescenta um valor vazio de --proxy, substituindo o proxy pedido pelo ambiente apenas para essa invocação. Compare a primeira tentativa de ligação de cada saída, não o código de estado final.

A saída detalhada pode expor cabeçalhos, tokens e credenciais de proxy, por isso mantenha-a local e leia excertos antes de a partilhar.

O que cada resultado exclui

Se omitir a configuração predefinida alterar a ligação, a fonte é o ficheiro de configuração. Se desativar explicitamente o proxy herdado a alterar, a fonte é a variável de ambiente. Se nenhuma das duas a alterar e o localhost continuar a aparecer, veja as substituições de ligação da linha de comandos, a resolução de nomes de anfitrião e o executável escolhido. Cada uma tem uma correção diferente, e nenhuma delas é uma alteração de encaminhamento.

O carregamento de bibliotecas personalizadas ou o comportamento de rede injetado é uma camada posterior, e uma variável de ambiente por si só não é prova disso.

Mantenha a decisão do proxy separada da VPN

Assim que o curl escolhe um destino direto, o sistema operativo continua a encaminhar essa ligação. Desativar um proxy de aplicação não desativa a rota da VPN nem a sua política de filtragem. Faça comparações de acesso direto apenas onde esse diagnóstico estiver autorizado. Um teste que contorne a política em silêncio não é um resultado válido, é um incidente.

Se for necessário um proxy local, restaure o serviço e o endereço em vez de apagar as suas definições.

Se apenas alguns destinos privados precisarem de acesso direto, acrescente uma exclusão estreita e aprovada e mantenha o proxy para todo o resto. Guarde o primeiro erro do caminho escolhido, porque uma recusa de localhost, uma recusa de CONNECT do proxy, uma falha de certificado e um erro de autorização identificam quatro fases diferentes.