როცა curl-ის ტესტი HTTP სტატუსად 000-ს ბეჭდავს, მას არ მიუღია საბოლოო HTTP პასუხის კოდი, რომლის ჩვენებაც შეეძლებოდა. საიტს 000 სახელწოდების რეალური HTTP სტატუსი არ გამოუგზავნია.

შეცდომაც ჩაიწერეთ

POSIX გარსისთვის ეს მაგალითი ბეჭდავს საბოლოო HTTP ველს, CONNECT ველს და curl პროცესის დასრულების კოდს:

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"

მაგალითის ბოლო წერტილი შეცვალეთ თქვენი HTTP პროქსით ან HTTP პროქსების სიიდან აღებული კანდიდატით. show-error ჩართული დატოვეთ: შეცდომის შეტყობინება ხშირად ყველაზე გამოსადეგი ნაწილია. CONNECT ველი მნიშვნელოვანია გვირაბის გამოყენებისას; ის საიტის მეორე საბოლოო სტატუსი არ არის.

მნიშვნელობები ერთად წაიკითხეთ

  • პროქსისთან წარუმატებელმა კავშირმა HTTP ველი შეიძლება 000-ზე დატოვოს.
  • პასუხის მიღებამდე მოლოდინის დროის ამოწურვამ შეიძლება იგივე შედეგი გამოიწვიოს.
  • წარმატებულ CONNECT პასუხს მოყოლილმა TLS შეცდომამ შეიძლება აჩვენოს connect=200 და http=000.
  • საიტის სრულად მიღებული პასუხი, მაგალითად 403, სხვა შემთხვევაა: შესამოწმებლად რეალური HTTP პასუხი არსებობს.

დასრულების ზუსტი კოდი და შეტყობინება მიზეზის დადგენას აადვილებს. გაარკვიეთ, შეცდომა პროქსის მოძებნისას მოხდა, მის პორტთან დაკავშირებისას, გვირაბის შეთანხმებისას თუ დანიშნულების შემოწმებისას.

ყველა შედეგი მხოლოდ სტატუსის შემოწმებამდე არ დაიყვანოთ

სკრიპტი, რომელიც მხოლოდ http_code-ს ინახავს, გადაცემის შეცდომას კარგავს. შეინახეთ პროცესის შედეგიც და მგრძნობიარე მონაცემებისგან გასუფთავებული შეცდომის შეტყობინებაც. პირიქითაც ხდება: curl-მა შეიძლება გადაცემა წარმატებით დაასრულოს, მიუხედავად იმისა, რომ საიტი შეცდომის სტატუსს აბრუნებს, თუ შესაბამის fail პარამეტრს არ გამოიყენებთ. HTTP პასუხი და კლიენტის შესრულების შედეგი სხვადასხვა კითხვას პასუხობს.

000-ის გამოსწორებას TLS შემოწმების გამორთვით ან შემთხვევითი სათაურის დამატებით ნუ ეცდებით. ჯერ დაადგინეთ, რომელი ოპერაცია ვერ მივიდა საბოლოო პასუხამდე.

დაკავშირებული სტატიები