Twój log rotuje proxy. Twoje żądanie nadal używa starego.

Selektor wypisuje proxy A, potem proxy B. Dziennik żądań nadal pokazuje proxy A. Do wyjaśnienia tej sprzeczności nie jest potrzebna usługa sieciowa: wywołujący mógł wyrzucić wartość zwróconą przez selektor.

Śledź wartość aż do wywołania, które wysyła żądanie:

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

Ten fragment zakłada istniejącą sesję Requests i zweryfikowany URL proxy. Dla publicznych żądań dozwolonych przez publicznych pośredników darmowa lista proxy udostępnia kandydujące URL-e, które przechodzą tą samą ścieżką wyboru i wysyłki. Wspieranym słowem kluczowym jest proxies. Funkcja pomocnicza, która tylko wypisuje mapowanie albo zwraca mapowanie, którego nikt nie przypisuje, nie może zastąpić mapowania podanego tutaj.

Trzymaj wybraną trasę lokalnie dla operacji. W kodzie współbieżnym współdzielone pole current_proxy może się zmienić między logowaniem a wysyłką. Wtedy wybór innego pracownika może pojawić się obok błędnego wyniku.

Użyj identyfikatora próby, aby połączyć wybór, konfigurację wysyłki i wynik. Gdy pełny URL zawiera dane uwierzytelniające, zapisz bezpieczny identyfikator punktu końcowego zamiast pełnego URL-a.

Jeśli te wartości się zgadzają, ale obserwowane publiczne IP się nie zmienia, dotarłeś do innego pytania: czy wybrane punkty końcowe zapewniają różne wyjścia, czy obrotowa brama utrzymuje połączenie. Najpierw ustal, czy aplikacja wysłała trasę, którą rzekomo wybrała. W przeciwnym razie spekulacje po stronie dostawcy mogą przez godziny ukrywać prostą nieaktualną zmienną.