Ваш журнал ротує проксі. Ваш запит досі використовує старий.

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