Вашиот дневник ротира прокси. Вашето барање сè уште го користи стариот.
Следете ја избраната крајна точка до вистинскиот HTTP повик за испраќање, наместо да претпоставувате дека печатењето нова вредност ја менува конфигурацијата на барањето.
Селекторот печати прокси A, потоа прокси B. Но дневникот на барања продолжува да го прикажува прокси A. Не е потребна мрежна услуга за да се објасни оваа противречност: повикувачот можеби ја отфрлил повратната вредност на селекторот.
Следете ја вредноста до повикот што го испраќа барањето:
endpoint = choose_proxy()
routes = {'http': endpoint, 'https': endpoint}
response = session.get(target_url, proxies=routes, timeout=15)
Овој фрагмент претпоставува постоечка сесија на Requests и валидиран URL на прокси. За јавни барања дозволени преку јавни посредници, списокот на бесплатни проксија нуди кандидат URL-а што минуваат по истиот пат на избор и испраќање. Поддржаниот клучен збор е proxies. Помошна функција што печати мапирање, или враќа мапирање што никој не го доделува, не може да го замени мапирањето дадено овде.
Држете ја избраната рута локална за операцијата. Во паралелен код, споделено поле current_proxy може да се промени помеѓу евидентирањето и испраќањето. Тогаш изборот на друг работник може да се појави покрај погрешен резултат.
Користете идентификатор на обид за да ги поврзете изборот, конфигурацијата за испраќање и резултатот. Кога содржи акредитиви, евидентирајте безбеден идентификатор на крајната точка наместо целосниот URL.
Ако тие вредности се совпаѓаат, но забележаната јавна IP не се менува, стигнавте до друго прашање: дали избраните крајни точки обезбедуваат различни излези или ротирачката порта држи врска. Прво утврдете дали апликацијата ја испратила рутата што тврди дека ја избрала. Инаку, шпекулациите од страната на провајдерот можат со часови да кријат едноставна застарена променлива.