Via registro rotacias proksiojn. Via peto ankoraŭ uzas la malnovan.

La elektilo presas proksion A, poste proksion B. La petprotokolo daŭre montras proksion A. Ne necesas reta servo por klarigi tiun kontraŭdiron: la alvokanto eble forĵetis la redonvaloron de la elektilo.

Spuru la valoron en la vokon, kiu sendas la peton:

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

Ĉi tiu fragmento supozas ekzistantan seancon de Requests kaj validigitan proksian URL-on. Por publikaj petoj permesitaj tra publikaj perantoj, la senpaga proksia listo provizas kandidatajn URL-ojn, kiuj pasas la saman elekto-kaj-senda vojon. La subtenata ŝlosilvorto estas proxies. Helpilo, kiu presas mapigon, aŭ redonas mapigon, kiun neniu asignas, ne povas anstataŭigi la mapigon provizitan ĉi tie.

Tenu la elektitan itineron lokan al la operacio. En samtempa kodo, komuna kampo current_proxy povas ŝanĝiĝi inter protokolado kaj sendado. Tiam la elekto de alia laboranto povas aperi apud la malĝusta rezulto.

Uzu providentigilon por ligi la elekton, la sendan agordon kaj la rezulton. Protokolu sekuran finpunktan identigilon anstataŭ la plenan URL-on, kiam ĝi enhavas akreditaĵojn.

Se tiuj valoroj kongruas sed la observata publika IP ne ŝanĝiĝas, vi atingis alian demandon: ĉu la elektitaj finpunktoj provizas malsamajn elirojn aŭ rotacia enirejo tenas konekton. Unue klarigu, ĉu la aplikaĵo sendis la itineron, kiun ĝi asertis elekti. Alie, konjektoj ĉe la provizanto povas kaŝi simplan malaktualan varianton dum horoj.