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