Ваш журнал ротирует прокси. Ваш запрос всё ещё использует старый.

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