Når en curl-test skriver 000 som HTTP-status, har curl ikke fått noen endelig HTTP-svarkode å rapportere. Nettstedet sendte ikke en faktisk HTTP-status kalt 000.

Ta også vare på feilen

Dette eksemplet for et POSIX-skall skriver ut det endelige HTTP-feltet, CONNECT-feltet og avslutningskoden til curl-prosessen:

curl --proxy http://203.0.113.10:8080 --noproxy '' --connect-timeout 5 --max-time 15 --silent --show-error --output /dev/null --write-out 'http=%{http_code} connect=%{http_connect}\n' https://example.com/
result=$?
printf 'curl_exit=%s\n' "$result"

Bytt ut eksemplets endepunkt med HTTP-proxyen din eller en kandidat fra listen over HTTP-proxyer. La show-error være aktivert: feilmeldingen er ofte den nyttigste delen. CONNECT-feltet er relevant når en tunnel brukes; det er ikke en andre endelig status fra nettstedet.

Les verdiene samlet

  • En mislykket tilkobling til proxyen kan la HTTP-feltet bli stående på 000.
  • Et tidsavbrudd før et svar er mottatt kan gi samme resultat.
  • Et vellykket CONNECT-svar etterfulgt av en TLS-feil kan vise connect=200 og http=000.
  • Et fullstendig svar fra nettstedet, som 403, er noe annet: da finnes det et faktisk HTTP-svar å undersøke.

Den nøyaktige avslutningskoden og meldingen snevrer inn årsaken. Undersøk om feilen oppstod da proxyen skulle finnes, ved tilkobling til porten, under tunnelforhandlingen eller ved verifisering av målet.

Ikke reduser alle resultater til bare en statussjekk

Et skript som bare lagrer http_code, kaster bort transportfeilen. Lagre også prosessresultatet og en feilmelding der sensitive opplysninger er fjernet. Omvendt kan curl fullføre en overføring uten feil selv om nettstedet returnerer en feilstatus, med mindre du bruker et passende fail-alternativ. HTTP-svaret og klientens kjøreresultat besvarer ulike spørsmål.

Ikke prøv å rette 000 ved å slå av TLS-verifisering eller legge til en tilfeldig header. Finn først ut hvilken operasjon som aldri nådde fram til et endelig svar.

Relaterte artikler