Regjistri yt rrotullon proxy-t. Kërkesa jote përdor ende atë të vjetrin.

Përzgjedhësi printon proxy A, pastaj proxy B. Regjistri i kërkesave vazhdon të tregojë proxy A. Nuk nevojitet një shërbim rrjeti për të shpjeguar këtë kundërshti: thirrësi mund ta ketë hedhur poshtë vlerën e kthyer nga përzgjedhësi.

Ndjek vlerën deri në thirrjen që dërgon kërkesën:

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

Ky fragment supozon një sesion ekzistues Requests dhe një URL proxy të validuar. Për kërkesat publike të lejuara përmes ndërmjetësve publikë, lista e proxy-ve falas ofron URL kandidate që kalojnë nëpër të njëjtën rrugë zgjedhjeje dhe dërgimi. Fjala kyçe e mbështetur është proxies. Një ndihmës që printon një hartëzim, ose kthen një të tillë që askush nuk e cakton, nuk mund të zëvendësojë hartëzimin e dhënë këtu.

Mbaje rrugën e zgjedhur lokale për operacionin. Në kod konkurrent, një fushë e përbashkët current_proxy mund të ndryshojë midis regjistrimit dhe dërgimit. Atëherë zgjedhja e një punëtori tjetër mund të shfaqet pranë rezultatit të gabuar.

Përdor një identifikues përpjekjeje për të lidhur zgjedhjen, konfigurimin e dërgimit dhe rezultatin. Kur URL-ja e plotë përmban kredenciale, regjistro një identifikues të sigurt të pikës fundore në vend të saj.

Nëse ato vlera përputhen por IP-ja publike e vëzhguar nuk ndryshon, ke arritur në një pyetje tjetër: nëse pikat fundore të zgjedhura ofrojnë dalje të ndryshme apo një portë rrotulluese mban një lidhje. Së pari përcakto nëse aplikacioni dërgoi rrugën që pretendon se zgjodhi. Përndryshe, spekulimet nga ana e ofruesit mund të fshehin me orë të tëra një variabël të thjeshtë të vjetëruar.