Varför curl ansluter till localhost i stället för den externa URL:en

Om curl försöker ansluta till localhost oavsett vilken URL du angav, är VPN:en fel plats att börja på. En lokal HTTP- eller SOCKS-proxy kan vara den avsedda första anslutningen, även när tjänsten du vill nå finns någon helt annanstans. Om den proxyn inte längre körs misslyckas localhost-försöket innan curl ens når målet. Ett proxysvar är inte heller bevis för att målet svarade.

Gå igenom de här stegen i ordning och stanna vid det första som ändrar det första anslutningsförsöket.

Läs curls egna proxyregler först

curl läser protokollspecifika proxyvariabler, som https_proxy och HTTPS_PROXY, samt ALL_PROXY när inget protokollspecifikt värde gäller. Granska miljön för det skal, den tjänst eller den uppgift som faktiskt startar curl, inte den i din nuvarande terminal. Ett CI-jobb, en systemd-enhet och ett interaktivt skal kan ärva tre olika uppsättningar. Just att gissa utifrån det synliga skalet är vad som gör att den här undersökningen förlorar en hel eftermiddag.

Ett undantag är värt att komma ihåg. curl accepterar http_proxy endast med små bokstäver; stora bokstäver HTTP_PROXY ignoreras, vilket är anledningen till att samma miljö beter sig annorlunda i andra verktyg.

Läs värdena privat, eftersom en proxy-URL ofta bär autentiseringsuppgifter.

Kontrollera sedan standardkonfigurationsfilen för curl efter proxy- eller anslutningsöverstyrningar och bekräfta vilken körbar fil du faktiskt kör. Ett skalalias, en funktion eller ett omslagsskript kan lägga till alternativ som aldrig syns på din kommandorad.

Jämför tre anrop med TLS på

Använd ett godkänt diagnostiskt mål och samma binärfil för alla tre körningarna.

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 undertrycker standard-curlrc och måste vara den första parametern på raden för att fungera. Det tar inte bort proxy-miljövariabler, vilket överraskar dem som förväntar sig det. Den tredje formen lägger till ett tomt --proxy-värde och åsidosätter en proxy som miljön begärde, bara för det anropet. Jämför det första anslutningsförsöket i varje utdata, inte den slutliga statuskoden.

Detaljerad utdata kan avslöja rubriker, tokens och proxyautentiseringsuppgifter, så håll den lokal och läs utdrag innan du delar den.

Vad varje resultat utesluter

Om det att utelämna standardkonfigurationen ändrar anslutningen är konfigurationsfilen källan. Om det att uttryckligen stänga av den ärvda proxyn ändrar den är miljövariabeln källan. Om ingen av dem ändrar den och localhost fortfarande visas, titta på överstyrningar av anslutningen på kommandoraden, värdnamnsuppslagning och den valda körbara filen. Var och en av dem har en annan åtgärd, och ingen av dem är en ändring av routingen.

Inläsning av anpassade bibliotek eller injicerat nätverksbeteende är ett senare lager, och en miljövariabel ensam är inte bevis på det.

Håll proxybeslutet åtskilt från VPN:en

När curl väljer ett direkt mål dirigerar operativsystemet fortfarande den anslutningen. Att stänga av en programproxy stänger inte av VPN:ens rutt eller dess filtreringspolicy. Gör jämförelser av direkt åtkomst bara där den diagnostiken är tillåten. Ett test som tyst kringgår policyn är inte ett giltigt resultat, det är en incident.

Om en lokal proxy krävs, återställ dess tjänst och adress i stället för att radera dess inställningar.

Om bara utvalda privata mål behöver direkt åtkomst, lägg till ett snävt godkänt undantag och behåll proxyn för allt annat. Bevara det första felet från den valda vägen, eftersom en localhost-vägran, en proxy CONNECT-vägran, ett certifikatfel och ett auktoriseringsfel pekar på fyra olika faser.