თქვენი ჟურნალი პროქსებს ატრიალებს. თქვენი მოთხოვნა კვლავ ძველს იყენებს.

სელექტორი ბეჭდავს პროქსს A, შემდეგ პროქსს B. მოთხოვნების ჟურნალი კვლავ აჩვენებს პროქსს A. ამ წინააღმდეგობის ასახსნელად ქსელური სერვისი არ არის საჭირო: გამომძახებელმა შეიძლება გადააგდოს სელექტორის დაბრუნებული მნიშვნელობა.

თვალყური ადევნეთ მნიშვნელობას იმ გამოძახებამდე, რომელიც აგზავნის მოთხოვნას:

endpoint = choose_proxy()
routes = {'http': endpoint, 'https': endpoint}
response = session.get(target_url, proxies=routes, timeout=15)

ეს ფრაგმენტი ვარაუდობს არსებულ Requests სესიას და დადასტურებულ პროქსი URL-ს. საჯარო შუამავლებით დაშვებული საჯარო მოთხოვნებისთვის უფასო პროქსების სია გთავაზობთ კანდიდატ URL-ებს, რომლებიც გადიან იმავე არჩევისა და გაგზავნის გზას. მხარდაჭერილი საკვანძო სიტყვაა proxies. დამხმარე ფუნქცია, რომელიც ბეჭდავს დაკავშირებას ან აბრუნებს ისეთ დაკავშირებას, რომელსაც არავინ ანიჭებს, ვერ შეცვლის აქ მოცემულ დაკავშირებას.

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

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

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