Hvorfor curl kobler til localhost i stedet for den eksterne URL-en

Hvis curl prøver å koble til localhost uansett hvilken URL du ga den, er VPN-en feil sted å begynne. En lokal HTTP- eller SOCKS-proxy kan være den tiltenkte første forbindelsen, selv når tjenesten du vil ha ligger helt et annet sted. Hvis den proxyen ikke kjører lenger, mislykkes localhost-forsøket før curl i det hele tatt når målet. Et proxysvar er heller ikke bevis for at målet svarte.

Gå gjennom disse trinnene i rekkefølge, og stopp ved det første som endrer det første tilkoblingsforsøket.

Les curls egne proxyregler først

curl leser protokollspesifikke proxyvariabler som https_proxy og HTTPS_PROXY, samt ALL_PROXY når ingen protokollspesifikk verdi gjelder. Undersøk miljøet til skallet, tjenesten eller oppgaven som faktisk starter curl, ikke det i den gjeldende terminalen. En CI-jobb, en systemd-enhet og et interaktivt skall kan arve tre ulike sett. Nettopp det å gjette ut fra det synlige skallet er hvordan denne undersøkelsen mister en hel ettermiddag.

Ett unntak er verdt å huske. curl godtar http_proxy bare med små bokstaver; store bokstaver HTTP_PROXY ignoreres, og derfor oppfører det samme miljøet seg annerledes i andre verktøy.

Les verdiene privat, fordi en proxy-URL ofte bærer på legitimasjon.

Sjekk deretter standard curl-konfigurasjonsfil for proxy- eller tilkoblingsoverstyringer, og bekreft hvilken kjørbar fil du faktisk kjører. Et skallalias, en funksjon eller et wrapper-skript kan legge til alternativer som aldri vises på kommandolinjen.

Sammenlign tre kall med TLS på

Bruk ett godkjent diagnostisk mål og samme binærfiler for alle tre kjøringene.

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 må være den første parameteren på linjen for å virke. Det fjerner ikke proxy-miljøvariabler, noe som overrasker folk som forventer det. Den tredje formen legger til en tom --proxy-verdi og overstyrer en proxy miljøet ba om, bare for det kallet. Sammenlign det første tilkoblingsforsøket i hver utskrift, ikke den endelige statuskoden.

Detaljert utskrift kan avsløre headere, tokens og proxy-legitimasjon, så hold det lokalt og les utdrag før du deler det.

Hva hvert resultat utelukker

Hvis det å utelate standardkonfigurasjonen endrer tilkoblingen, er konfigurasjonsfilen kilden. Hvis det å uttrykkelig slå av den arvede proxyen endrer den, er miljøvariabelen kilden. Hvis ingen av dem endrer den og localhost fortsatt vises, se på overstyringer av tilkoblingen på kommandolinjen, vertsnavnoppslag og den valgte kjørbare filen. Hver av dem har en annen rettelse, og ingen av dem er en endring i rutingen.

Innlasting av egendefinerte biblioteker eller injisert nettverksatferd er et senere lag, og en miljøvariabel alene er ikke bevis på det.

Hold proxybeslutningen atskilt fra VPN-en

Når curl først velger et direkte mål, ruter operativsystemet fortsatt den tilkoblingen. Å slå av en applikasjonsproxy slår ikke av VPN-ens rute eller filtreringspolicyen dens. Gjør direkte tilgang-sammenligninger bare der den diagnostikken er autorisert. En test som stille omgår policyen, er ikke et gyldig resultat, det er en hendelse.

Hvis en lokal proxy er nødvendig, gjenopprett tjenesten og adressen i stedet for å slette innstillingene.

Hvis bare utvalgte private mål trenger direkte tilgang, legg til et smalt godkjent unntak og behold proxyen for alt annet. Bevar den første feilen fra den valgte veien, fordi en localhost-avvisning, en proxy CONNECT-avvisning, en sertifikatfeil og en autorisasjonsfeil viser fire ulike stadier.