A naplód forgatja a proxykat. A kérésed még mindig a régit használja.
Kövesd a kiválasztott végpontot egészen a tényleges HTTP-küldő hívásig, ahelyett hogy feltételeznéd, hogy egy új érték kiírása megváltoztatja a kérés konfigurációját.
A választó kiírja az A proxyt, majd a B proxyt. A kérésnapló azonban továbbra is az A proxyt mutatja. Ehhez az ellentmondáshoz nem kell hálózati szolgáltatás: lehetséges, hogy a hívó eldobta a választó visszatérési értékét.
Kövesd az értéket egészen addig a hívásig, amely elküldi a kérést:
endpoint = choose_proxy()
routes = {'http': endpoint, 'https': endpoint}
response = session.get(target_url, proxies=routes, timeout=15)
Ez a részlet egy meglévő Requests-munkamenetet és egy érvényesített proxy URL-t feltételez. A nyilvános közvetítőkön keresztül engedélyezett nyilvános kérésekhez az ingyenes proxylista olyan jelölt URL-eket kínál, amelyek ugyanazon a kiválasztás-és-küldés útvonalon haladnak át. A támogatott kulcsszó a proxies. Egy segédfüggvény, amely csak kiír egy leképezést, vagy olyat ad vissza, amelyet senki sem rendel hozzá, nem helyettesítheti az itt megadott leképezést.
Tartsd a kiválasztott útvonalat a művelet helyi hatókörében. Párhuzamos kódban egy megosztott current_proxy mező megváltozhat a naplózás és a küldés között. Ekkor egy másik munkatárs választása a rossz eredmény mellett jelenhet meg.
Használj kísérlet-azonosítót a választás, a küldési konfiguráció és az eredmény összekapcsolására. Ha a teljes URL hitelesítő adatokat tartalmaz, inkább egy biztonságos végpont-azonosítót naplózz.
Ha ezek az értékek megegyeznek, de a megfigyelt nyilvános IP nem változik, egy másik kérdéshez érkeztél: hogy a kiválasztott végpontok különböző kimeneteket kínálnak-e, vagy egy forgó átjáró fenntart egy kapcsolatot. Először tisztázd, hogy az alkalmazás elküldte-e azt az útvonalat, amelyet állítása szerint kiválasztott. Különben a szolgáltató oldali találgatás órákig elrejthet egy egyszerű elavult változót.