Perché curl si connette a localhost invece dell'URL remoto
Separare il proxy ereditato, il file curlrc predefinito e la destinazione reale prima di dare la colpa alla VPN. Tre esecuzioni controllate mantengono attiva la verifica TLS.
Se curl tenta di connettersi a localhost indipendentemente dall'URL che gli hai fornito, la VPN è il posto sbagliato da cui iniziare. Un proxy HTTP o SOCKS locale può essere la prima connessione prevista, anche quando il servizio che vuoi si trova altrove. Se quel proxy non è più in esecuzione, il tentativo verso localhost fallisce prima che curl raggiunga la destinazione. Inoltre, una risposta del proxy non dimostra che la destinazione abbia risposto.
Segui questi passaggi in ordine e fermati al primo che cambia il primo tentativo di connessione.
Leggi prima le regole proxy di curl stesso
curl legge variabili proxy specifiche del protocollo, come https_proxy e HTTPS_PROXY, oltre a ALL_PROXY quando non si applica alcun valore specifico del protocollo. Ispeziona l'ambiente della shell, del servizio o dell'attività che avvia davvero curl, non quello del terminale corrente. Un job CI, un'unità systemd e una shell interattiva possono ereditare tre insiemi diversi. È proprio tirare a indovinare dalla shell visibile che fa perdere un intero pomeriggio a questa indagine.
Vale la pena memorizzare un'eccezione. curl accetta http_proxy solo in minuscolo; la forma in maiuscolo HTTP_PROXY viene ignorata, ed è per questo che lo stesso ambiente si comporta diversamente in altri strumenti.
Leggi i valori in privato, perché un URL di proxy spesso trasporta credenziali.
Poi controlla il file di configurazione predefinito di curl per eventuali sovrascritture di proxy o connessione, e conferma quale eseguibile stai davvero eseguendo. Un alias della shell, una funzione o uno script wrapper possono aggiungere opzioni che non compaiono mai sulla riga di comando.
Confronta tre invocazioni con TLS attivo
Usa una destinazione diagnostica approvata e lo stesso binario per tutte e tre le esecuzioni.
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 sopprime il curlrc predefinito e deve essere il primo parametro della riga per funzionare. Non rimuove le variabili d'ambiente del proxy, cosa che sorprende chi se lo aspetta. La terza forma aggiunge un valore vuoto di --proxy, sostituendo il proxy richiesto dall'ambiente solo per quella invocazione. Confronta il primo tentativo di connessione in ogni output, non il codice di stato finale.
L'output dettagliato può esporre intestazioni, token e credenziali del proxy, quindi tienilo in locale e leggi estratti prima di condividerlo.
Cosa esclude ogni risultato
Se omettere la configurazione predefinita cambia la connessione, la fonte è il file di configurazione. Se disattivare esplicitamente il proxy ereditato la cambia, la fonte è la variabile d'ambiente. Se nessuna delle due la cambia e localhost compare ancora, esamina le sovrascritture di connessione sulla riga di comando, la risoluzione dei nomi host e l'eseguibile scelto. Ognuna ha una correzione diversa, e nessuna di esse è un cambiamento di routing.
Il caricamento di librerie personalizzate o un comportamento di rete iniettato è uno strato successivo, e una variabile d'ambiente da sola non ne è prova.
Tieni la decisione sul proxy separata dalla VPN
Una volta che curl sceglie una destinazione diretta, il sistema operativo instrada comunque quella connessione. Disattivare un proxy applicativo non disattiva la rotta della VPN né la sua politica di filtro. Fai confronti di accesso diretto solo dove quella diagnostica è autorizzata. Un test che aggira la politica in silenzio non è un risultato valido, è un incidente.
Se è richiesto un proxy locale, ripristina il suo servizio e il suo indirizzo invece di cancellare le sue impostazioni.
Se solo alcune destinazioni private necessitano di accesso diretto, aggiungi un'esclusione ristretta e approvata e mantieni il proxy per tutto il resto. Conserva il primo errore del percorso scelto, perché un rifiuto di localhost, un rifiuto CONNECT del proxy, un errore di certificato e un errore di autorizzazione identificano quattro fasi diverse.