გამოიყენეთ პროქსი IP urllib3-ით

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

uv add urllib3

დოკუმენტაციის ბოლო წერტილი შეცვალეთ თქვენი სერვისის HTTP პროქსით ან HTTP პროქსიების სიიდან აღებული ჩანაწერით და მოთხოვნა იმ მენეჯერით შეასრულეთ:

import urllib3

proxy = urllib3.ProxyManager(
    "http://203.0.113.10:8080",
    timeout=urllib3.Timeout(connect=5, read=10),
    retries=False,
)

try:
    response = proxy.request("GET", "https://example.com/")
    print(response.status)
    print(response.data.decode("utf-8", errors="replace")[:200])
finally:
    proxy.clear()

ჯერ წაიკითხეთ response.status, შემდეგ შეამოწმეთ response.data. ეს urllib3-ის ველებია; Requests-ის status_code და text მათი შემცვლელები არ არის. საიტის უარყოფა გამართული პროქსის გავლითაც შეიძლება მოვიდეს. პასუხამდე გამონაკლისი კი ნიშნავს, რომ მოთხოვნა ვერ დასრულდა.

retries=False დიაგნოსტიკური არჩევანია და არა სამუშაო გარემოს განმეორებების პოლიტიკა. დაკავშირების 5 წამი და წაკითხვის 10 წამი თავიანთ ფაზებს ზღუდავს; ისინი გარანტირებულ მთლიან 15-წამიან ზღვარს არ ქმნის. DNS-მა და პასუხის პროგრესმა შეიძლება საერთო ლოდინზე იმოქმედოს.

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

მენეჯერი მსმენელ სერვისს შეუსაბამეთ. ჩვეულებრივი PoolManager პროქსის არ იყენებს მხოლოდ იმიტომ, რომ URL სხვაგან ინახება; SOCKS იყენებს urllib3.contrib.socks.SOCKSProxyManager-სა და მის არჩევით დამოკიდებულებებს. ზემოთ მოცემული კოდი HTTP ProxyManager გზას მიჰყვება.