گزارش شما پروکسی‌ها را می‌چرخاند. درخواست شما هنوز از پروکسی قدیمی استفاده می‌کند.

انتخاب‌گر پروکسی 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 عمومی مشاهده‌شده تغییر نکند، به پرسش دیگری رسیده‌اید: اینکه آیا نقاط پایانی انتخاب‌شده خروجی‌های متفاوت ارائه می‌دهند یا یک دروازه چرخشی یک اتصال را نگه می‌دارد. نخست روشن کنید که آیا برنامه همان مسیری را فرستاده که ادعا می‌کند انتخاب کرده است. وگرنه گمانه‌زنی سمت ارائه‌دهنده می‌تواند یک متغیر کهنه ساده را ساعت‌ها پنهان کند.