När ett curl-test skriver 000 som HTTP-status har curl inte fått någon slutlig HTTP-svarskod att rapportera. Webbplatsen skickade inte en verklig HTTP-status med namnet 000.

Fånga även felet

Det här exemplet för ett POSIX-skal skriver ut det slutliga HTTP-fältet, CONNECT-fältet och curl-processens slutkod:

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"

Byt ut exempeladressen mot din HTTP-proxy eller en kandidat från listan över HTTP-proxyer. Låt show-error vara aktiverat: felmeddelandet är ofta den mest användbara delen. CONNECT-fältet är relevant när en tunnel används; det är inte en andra slutlig status från webbplatsen.

Läs värdena tillsammans

  • En misslyckad anslutning till proxyn kan lämna HTTP-fältet på 000.
  • En timeout innan något svar har kommit kan ge samma resultat.
  • Ett lyckat CONNECT-svar följt av ett TLS-fel kan ge connect=200 och http=000.
  • Ett fullständigt svar från webbplatsen, till exempel 403, är något annat: då finns ett verkligt HTTP-svar att undersöka.

Den exakta slutkoden och meddelandet ringar in orsaken. Kontrollera om felet uppstod när proxyn skulle hittas, när anslutningen till porten öppnades, under tunnelförhandlingen eller vid verifieringen av målet.

Gör inte varje resultat till enbart en statuskontroll

Ett skript som bara sparar http_code kastar bort transportfelet. Spara även processresultatet och ett felmeddelande där känsliga uppgifter har tagits bort. Omvänt kan curl slutföra en överföring utan fel trots att webbplatsen returnerar en felstatus, om du inte använder ett lämpligt fail-alternativ. HTTP-svaret och klientens körresultat besvarar olika frågor.

Försök inte rätta till 000 genom att stänga av TLS-verifiering eller lägga till ett slumpmässigt HTTP-huvud. Ta först reda på vilken operation som aldrig nådde fram till ett slutligt svar.

Relaterade artiklar