Votre journal fait tourner les proxys. Votre requête utilise encore l'ancien.

Le sélecteur imprime le proxy A, puis le proxy B. Le journal des requêtes continue d'afficher le proxy A. Aucun service réseau n'est nécessaire pour expliquer cette contradiction : l'appelant a peut-être jeté la valeur de retour du sélecteur.

Suivez la valeur jusque dans l'appel qui envoie la requête :

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

Cet extrait suppose une session Requests existante et une URL de proxy validée. Pour les requêtes publiques autorisées via des intermédiaires publics, la liste de proxys gratuits fournit des URL candidates qui passent par le même chemin de sélection et d'envoi. Le mot-clé pris en charge est proxies. Un assistant qui imprime un mapping, ou qui en renvoie un que personne n'affecte, ne peut pas remplacer le mapping fourni ici.

Gardez la route sélectionnée locale à l'opération. Dans du code concurrent, un champ partagé current_proxy peut changer entre la journalisation et l'envoi. La sélection d'un autre worker peut alors apparaître à côté du mauvais résultat.

Utilisez un identifiant de tentative pour relier la sélection, la configuration d'envoi et le résultat. Journalisez un identifiant de point de terminaison sûr plutôt que l'URL complète lorsqu'elle contient des identifiants.

Si ces valeurs concordent mais que l'IP publique observée ne change pas, vous êtes arrivé à une autre question : est-ce que les points de terminaison sélectionnés offrent des sorties distinctes ou est-ce qu'une passerelle rotative conserve une connexion. Établissez d'abord si l'application a envoyé la route qu'elle prétend avoir sélectionnée. Sinon, les spéculations côté fournisseur peuvent masquer une simple variable périmée pendant des heures.