curl-ით წარუმატებელი proxy CONNECT პასუხის სხეულის შესწავლა

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

curl --proxy '' --http1.1 --max-time 10 \
  --request CONNECT \
  --request-target service.example:443 \
  --header 'Host: service.example:443' \
  --dump-header tunnel.headers \
  --output tunnel.body \
  http://proxy.example:8080/

საბოლოო URL მიმართავს პროქსის მსმენელს. საჯარო პროქსების დაშვებული შედარებისთვის HTTP პროქსების სია გვთავაზობს კანდიდატებს ამ მსმენელის URL-ისთვის. --request აძლევს მეთოდის ტოკენს; --request-target აძლევს CONNECT-ის უფლებამოსილებას. მათი ცალკე შენახვა წარმოქმნის CONNECT service.example:443 HTTP/1.1-ს.

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

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

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

რეალური HTTPS ჩამოტვირთვისთვის გამოიყენეთ ჩვეულებრივი --proxy მოთხოვნის ნაკადი. შეინახეთ დიაგნოსტიკის სტატუსი და სხეული მათ კონკრეტულ პროქსისა და სამიზნესთან ერთად.