გარსი ვერ გადააქცევს ჩამომტვირთველის ნულოვან გასვლის კოდს დაკვირვებულ „HTTP 200 OK“-ად. ჩაწერეთ, რა შეატყობინა თითოეულმა დონემ სინამდვილეში:

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

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

შეინახეთ ცალკე პროქსის საბოლოო წერტილი და საიტის სახელი. HTTP პროქსის შემოწმების TCP წყვილი თავად პროქსია; CONNECT ასახელებს დანიშნულებას, რომლის TLS სესიაც შემდეგ გვირაბის შიგნით მიდის. HTTPS პროქსის შემთხვევაში გარე პროქსისადმი ნდობა კიდევ ერთი სერტიფიკატის შემოწმებაა.

შეამოწმეთ დანამატის გარანტია, სანამ SSL დროშას ვერიფიკაციად ჩათვლით. Monitoring Plugins check_http-ს check_curl-ის სასარგებლოდ ხსნის მოხმარებიდან. check_http-ის დოკუმენტაცია აფრთხილებს, რომ მხოლოდ SSL-ის არჩევა არ ამოწმებს ჰოსტის სახელს ან გამომცემლის ნდობას; check_curl-ის დოკუმენტირებული verify-peer ოპცია მოიცავს ამ შემოწმებას.

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

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