Дневникът ви сменя проксита. Заявката ви все още използва старото.

Селекторът отпечатва прокси 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 не се променя, стигнали сте до друг въпрос: дали избраните крайни точки дават различни изходи, или ротационен шлюз задържа връзка. Първо установете дали приложението е изпратило маршрута, който твърди, че е избрало. Иначе предположенията от страна на доставчика могат да скрият проста остаряла променлива с часове.