Hvorfor curl forbinder til localhost i stedet for den eksterne URL

Hvis curl forsøger at forbinde til localhost uanset den URL, du gav den, er VPN det forkerte sted at begynde. En lokal HTTP- eller SOCKS-proxy kan være den tilsigtede første forbindelse, selv når den tjeneste, du vil have, ligger helt et andet sted. Hvis den proxy ikke længere kører, mislykkes localhost-forsøget, før curl overhovedet når destinationen. Et proxy-svar er heller ikke bevis på, at destinationen svarede.

Gå gennem disse trin i rækkefølge, og stop ved det første, der ændrer det første forbindelsesforsøg.

Læs curls egne proxyregler først

curl læser protokolspecifikke proxyvariabler som https_proxy og HTTPS_PROXY, samt ALL_PROXY, når ingen protokolspecifik værdi gælder. Undersøg miljøet for det shell, den tjeneste eller den opgave, der faktisk starter curl, ikke det i din nuværende terminal. Et CI-job, en systemd-unit og et interaktivt shell kan arve tre forskellige sæt. At gætte ud fra det synlige shell er netop, hvordan denne undersøgelse spilder en hel eftermiddag.

Én undtagelse er værd at huske. curl accepterer http_proxy kun med små bogstaver; stort HTTP_PROXY ignoreres, og derfor opfører det samme miljø sig forskelligt i andre værktøjer.

Læs værdierne privat, fordi en proxy-URL ofte bærer legitimationsoplysninger.

Kontroller derefter standard-curl-konfigurationsfilen for proxy- eller forbindelsesoverstyringer, og bekræft, hvilken eksekverbar fil du faktisk kører. Et shell-alias, en funktion eller et wrapper-script kan tilføje valgmuligheder, der aldrig vises på din kommandolinje.

Sammenlign tre kald med TLS slået til

Brug én godkendt diagnostisk destination og den samme binære fil til alle tre kørsler.

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 undertrykker standard-curlrc og skal være den første parameter på linjen for at virke. Det fjerner ikke proxy-miljøvariabler, hvilket overrasker folk, der forventer det. Den tredje form tilføjer en tom --proxy-værdi og overstyrer en proxy, som miljøet har bedt om, kun for dette kald. Sammenlign det første forbindelsesforsøg i hver output, ikke den endelige statuskode.

Detaljeret output kan afsløre headers, tokens og proxy-legitimationsoplysninger, så hold det lokalt, og læs uddrag, før du deler det.

Hvad hvert resultat udelukker

Hvis det ændrer forbindelsen at udelade standardkonfigurationen, er konfigurationsfilen kilden. Hvis det ændrer den udtrykkeligt at slå den arvede proxy fra, er miljøvariablen kilden. Hvis ingen af dem ændrer den, og localhost stadig vises, så se på overstyringer af forbindelsen på kommandolinjen, værtsnavnopløsning og den valgte eksekverbare fil. Hver af dem har en anden rettelse, og ingen af dem er en ændring af routing.

Indlæsning af tilpassede biblioteker eller injiceret netværksadfærd er et senere lag, og en miljøvariabel alene er ikke bevis på det.

Hold proxybeslutningen adskilt fra VPN

Når curl først vælger en direkte destination, router operativsystemet stadig den forbindelse. At slå en applikationsproxy fra slår ikke VPN'ens rute eller dens filtreringspolitik fra. Kør kun direkte adgangs-sammenligninger, hvor den diagnostik er godkendt. En test, der stille omgår politikken, er ikke et gyldigt resultat, det er en hændelse.

Hvis en lokal proxy er påkrævet, gendan dens tjeneste og adresse i stedet for at slette dens indstillinger.

Hvis kun udvalgte private destinationer har brug for direkte adgang, så tilføj en snæver godkendt undtagelse og behold proxyen til alt andet. Bevar den første fejl fra den valgte vej, fordi en localhost-afvisning, en proxy CONNECT-afvisning, en certifikatfejl og en autorisationsfejl viser fire forskellige stadier.