Dein Log rotiert Proxys. Deine Anfrage nutzt noch den alten.
Verfolge den ausgewählten Endpunkt bis in den tatsächlichen HTTP-Sendeaufruf, statt anzunehmen, dass das Ausgeben eines neuen Werts die Konfiguration der Anfrage ändert.
Der Selektor gibt Proxy A aus, dann Proxy B. Das Anfrage-Log zeigt weiterhin Proxy A. Für diesen Widerspruch braucht es keinen Netzwerkdienst: Der Aufrufer hat möglicherweise den Rückgabewert des Selektors verworfen.
Verfolge den Wert bis in den Aufruf, der die Anfrage sendet:
endpoint = choose_proxy()
routes = {'http': endpoint, 'https': endpoint}
response = session.get(target_url, proxies=routes, timeout=15)
Dieses Fragment setzt eine bestehende Requests-Session und eine validierte Proxy-URL voraus. Für öffentliche Anfragen, die über öffentliche Vermittler erlaubt sind, liefert die kostenlose Proxy-Liste Kandidaten-URLs, die denselben Auswahl-und-Sende-Pfad durchlaufen. Das unterstützte Schlüsselwort ist proxies. Ein Helfer, der ein Mapping ausgibt oder eines zurückgibt, das niemand zuweist, kann das hier übergebene Mapping nicht ersetzen.
Halte die ausgewählte Route lokal für die Operation. In nebenläufigem Code kann sich ein gemeinsam genutztes Feld current_proxy zwischen Protokollierung und Senden ändern. Dann kann die Auswahl eines anderen Workers neben dem falschen Ergebnis erscheinen.
Verbinde Auswahl, Sendekonfiguration und Ergebnis über eine Versuchskennung. Protokolliere eine sichere Endpunktkennung statt der vollständigen URL, wenn sie Zugangsdaten enthält.
Stimmen diese Werte überein, ändert sich die beobachtete öffentliche IP aber nicht, bist du bei einer anderen Frage angekommen: ob die ausgewählten Endpunkte unterschiedliche Ausgänge bieten oder ein rotierendes Gateway eine Verbindung hält. Kläre zuerst, ob die Anwendung die Route gesendet hat, die sie angeblich ausgewählt hat. Sonst kann eine Spekulation auf Anbieterseite eine einfache veraltete Variable stundenlang verbergen.