Test en HTTP-proxy med curl

Bruk en tidsavgrenset curl-test til å undersøke proxytilkobling, HTTPS-tunnel, svarstatus og unntaksregler uten å endre enhetens globale proxy.

Bytt ut 127.0.0.1:8080 med et endepunkt fra tjenesten din eller listen over HTTP-proxyer, og kjør dette 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 viser til et lyttepunkt på din egen maskin. Kommandoen velger det uttrykkelig, tømmer curls unntaksliste for dette kallet og tillater fem sekunder til tilkoblingsoppsett og femten sekunder totalt. Proxyinnstillingene i nettleseren og systemet endres ikke.

Bruk den faktiske curl-programfilen hvis skallet ditt gjør curl til et alias for et annet program; curl --version identifiserer byggversjonen. Krever selve lyttepunktet TLS, bruker du proxy-URL-skjemaet som står i dokumentasjonen.

Les fire resultater, ikke bare ett grønt lys

  1. Tilkoblet valgt proxy: adressen og porten er tilgjengelige.
  2. CONNECT godtatt: proxyen åpnet en tunnel til HTTPS-destinasjonen.
  3. Destinasjonens sertifikat verifisert: TLS ble fullført med forventede tillitskontroller.
  4. Svar fra destinasjonen mottatt: undersøk status og innhold for å se om resultatet oppfyller applikasjonens behov.

En fungerende tunnel kan følges av 403 eller 429 fra destinasjonen. curl kan også avslutte vellykket etter et HTTP-feilsvar. Registrer derfor både svarstatus og curls feilresultat. En TCP-tilkobling eller vellykket CONNECT er ikke tilstrekkelig alene.

Et kompakt resultat for gjentatte sammenligninger

I et Unix-lignende skall kan du forkaste svarinnholdet og skrive ut tunnelstatus, destinasjonsstatus, motparten og medgått tid:

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 beskriver tunnelsvaret; http_code beskriver det endelige HTTP-svaret. remote_ip er motparten i curl-tilkoblingen, ikke en uavhengig måling av proxyens utgående adresse. Bytt ut /dev/null på andre systemer, eller behold svarinnholdet.

Mislykkes testen, finn oppsett- eller overføringstrinnet som feilet, og sammenlign med direkte tilgang til samme destinasjon der den ruten er tillatt:

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

--noproxy '*' omgår proxyer. Feil ved sertifikatverifisering på begge ruter peker mot et felles tillitsproblem; direkte tilkobling som lykkes samtidig som CONNECT avvises, peker mot proxyautentisering eller policy. Se gjennom detaljert utdata før du deler dem, fordi de kan inneholde identifiserende opplysninger.

Lagre endepunkt, mål og tidsstempel sammen med utfallet. Dette dokumenterer hva som fungerte for den forespørselen; fremtidig tilgjengelighet, personvern og ytelse under belastning krever egne bevis.

Relaterte artikler