Prøv en HTTP-proxy med curl

Undersøk proxyforbindelse, HTTPS-tunnel, svarstatus og unntaksregler med en tidsbegrenset curl-test, uten å endre enhetens globale proxyoppsett.

Erstatt 127.0.0.1:8080 med et endepunkt fra leverandøren din eller listen over HTTP-proxyer, og kjør kommandoen mot en ufarlig HTTPS-destinasjon:

curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/

Loopback-adressen betyr et lyttepunkt på din egen datamaskin. Denne kommandoen velger det eksplisitt, fjerner curls liste over proxyunntak for akkurat dette kallet og gir fem sekunder til å opprette forbindelsen og femten sekunder i alt. Nettleserens og systemets proxyinnstillinger forblir urørt.

Bruk det virkelige curl-programmet hvis skallet har curl som alias for et annet program; curl --version viser hvilken byggversjon som brukes. Hvis lyttepunktet selv krever TLS, bruker du det dokumenterte proxy-URL-skjemaet.

Se etter fire resultater, ikke ett klarsignal

  1. Forbindelse med valgt proxy: adressen og porten kan nås.
  2. CONNECT akseptert: proxyen har åpnet en tunnel til HTTPS-destinasjonen.
  3. Destinasjonens sertifikat kontrollert: TLS er fullført med de forventede tillitskontrollene.
  4. Destinasjonens svar mottatt: kontroller status og innhold opp mot resultatet applikasjonen trenger.

Selv med en fungerende tunnel kan destinasjonen returnere 403 eller 429. curl kan dessuten avslutte med suksess etter å ha mottatt et HTTP-feilsvar. Noter derfor både svarstatus og feilresultatet fra curl. Bare en TCP-forbindelse eller vellykket CONNECT er ikke nok.

Et kortfattet resultat til flere sammenligninger

På et Unix-lignende skall kan du utelate svarinnholdet og skrive ut status for tunnelen og destinasjonen, forbindelsens motpart og tidsbruken:

curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --silent --show-error --output /dev/null --write-out 'http=%{http_code} connect=%{http_connect} peer=%{remote_ip} total=%{time_total}\n' https://example.com/

http_connect gjelder tunnelsvaret; http_code gjelder det endelige HTTP-svaret. remote_ip er parten curl har forbindelse med, ikke en selvstendig måling av proxyens utgangsadresse. På andre systemer erstatter du /dev/null eller beholder svarinnholdet.

Hvis testen feiler, lokaliser trinnet for oppkobling eller overføring som mislyktes, og sammenlign med en direkte forbindelse til samme destinasjon der denne veien er tillatt:

curl --noproxy '*' --connect-timeout 5 --max-time 15 --verbose https://example.com/

--noproxy '*' går utenom proxyer. Mislykket sertifikatkontroll på begge veier tyder på et felles problem med tillit. En direkte forbindelse som virker mens CONNECT blir avvist, tyder på proxyautentisering eller regler hos proxyen. Kontroller detaljert utdata før du deler dem; de kan inneholde opplysninger som identifiserer deg.

Ta vare på endepunkt, mål og tidspunkt sammen med resultatet. Da har du dokumentert hva som virket for den forespørselen. Fremtidig tilgjengelighet, personvern og kapasitet under belastning trenger særskilt dokumentasjon.

Relaterte artikler