Je log roteert proxies. Je verzoek gebruikt nog steeds de oude.
Volg het geselecteerde eindpunt tot in de daadwerkelijke HTTP-verzendaanroep, in plaats van aan te nemen dat het printen van een nieuwe waarde de configuratie van het verzoek verandert.
De selector print proxy A, dan proxy B. Het verzoeklogboek blijft proxy A tonen. Voor die tegenstrijdigheid is geen netwerkdienst nodig: de aanroeper heeft mogelijk de retourwaarde van de selector weggegooid.
Volg de waarde tot in de aanroep die het verzoek verstuurt:
endpoint = choose_proxy()
routes = {'http': endpoint, 'https': endpoint}
response = session.get(target_url, proxies=routes, timeout=15)Dit fragment veronderstelt een bestaande Requests-sessie en een gevalideerde proxy-URL. Voor openbare verzoeken die via openbare tussenpersonen zijn toegestaan, biedt de gratis proxylijst kandidaat-URL's die hetzelfde selecteer-en-verzendpad doorlopen. Het ondersteunde trefwoord is proxies. Een helper die een mapping print, of er een teruggeeft die niemand toewijst, kan de hier geleverde mapping niet vervangen.
Houd de geselecteerde route lokaal voor de bewerking. In gelijktijdige code kan een gedeeld current_proxy-veld veranderen tussen loggen en verzenden. Dan kan de selectie van een andere worker naast het verkeerde resultaat verschijnen.
Gebruik een poging-identificatie om de selectie, de verzendconfiguratie en het resultaat te verbinden. Log een veilige eindpuntidentificatie in plaats van de volledige URL wanneer die inloggegevens bevat.
Als die waarden overeenkomen maar het waargenomen openbare IP niet verandert, ben je bij een andere vraag aangekomen: of de geselecteerde eindpunten verschillende uitgangen bieden of een roterende gateway een verbinding vasthoudt. Bepaal eerst of de applicatie de route heeft verzonden die hij beweerde te hebben geselecteerd. Anders kan speculatie aan de providerkant een simpele verouderde variabele urenlang verbergen.