მოთხოვნა პირდაპირ კერძო IP-ზე იყენებს პროქსის ქვექსელის გამონაკლისით, მაგრამ --noproxy '*'-ით პირდაპირ მიდის. ეს არ ამტკიცებს, რომ ოპერაციული სისტემა უგულებელყოფს პროქსის ყველა გამონაკლისს.

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

curl-მა ამ გამონაკლისებისთვის CIDR-ის შედარება 7.86.0-ში დაამატა. ახლით რომ გამოიყურებოდეს ოპერაციული სისტემის გამოშვება, მანქანას მაინც შეიძლება ჰქონდეს სხვა ვერსიის ხაზის კლიენტი ან დაკავშირებული ბიბლიოთეკა. შეამოწმეთ რეალურად გამოძახებული შესრულებადი ფაილი და მასთან დაკავშირებული libcurl, და არა მხოლოდ პრობლემის სათაურში მოცემული OS-ის სახელი.

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

მოთხოვნის შემავალი მონაცემები ზუსტად შეინახეთ. ჰოსტის სახელი, რომელიც ქვექსელში იხსნება, სხვა შემთხვევაა, ვიდრე პირდაპირი მისამართის შემცველი URL. მხარდაჭერილი CIDR პარსერი ავტომატურად არ ასრულებს DNS მოთხოვნას, რომ ყოველი სახელი მისამართზე დაფუძნებულ გვერდის ავლის გადაწყვეტილებად აქციოს.

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

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