سجلّك يدوّر الوكلاء. طلبك ما زال يستخدم القديم.
تتبَّع نقطة النهاية المختارة إلى استدعاء HTTP الفعلي بدل افتراض أن طباعة قيمة جديدة تغيّر إعداد الطلب.
يطبع المحدِّد الوكيل A ثم الوكيل B. لكن سجل الطلبات يظل يُظهر الوكيل A. لا حاجة إلى خدمة شبكة لتفسير هذا التناقض: ربما تخلّى المستدعي عن قيمة الإرجاع التي ينتجها المحدِّد.
تتبَّع القيمة إلى الاستدعاء الذي يرسل الطلب:
endpoint = choose_proxy()
routes = {'http': endpoint, 'https': endpoint}
response = session.get(target_url, proxies=routes, timeout=15)
تفترض هذه القطعة وجود جلسة Requests قائمة وعنوان URL موثَّق للوكيل. للطلبات العامة المسموح بها عبر وسطاء عامين، توفّر قائمة الوكلاء المجانية عناوين مرشحة تمرّ في المسار نفسه من الاختيار إلى الإرسال. الكلمة المفتاحية المدعومة هي proxies. ولا يمكن لمساعد يطبع خريطة، أو يعيد خريطة لا يُسنِدها أحد، أن يحلّ محل الخريطة المزوَّدة هنا.
أبقِ المسار المختار محليًا داخل العملية. في الشيفرة المتزامنة، قد يتغيّر الحقل current_proxy المشترك بين التسجيل والإرسال. وعندها قد يظهر اختيار عامل آخر بجانب نتيجة خاطئة.
استخدم معرّف محاولة لربط الاختيار وإعداد الإرسال والنتيجة. وسجّل معرّفًا آمنًا لنقطة النهاية بدل العنوان الكامل عندما يحتوي على بيانات اعتماد.
إذا تطابقت هذه القيم لكن عنوان IP العام المرصود لم يتغيّر، فقد وصلت إلى سؤال آخر: هل توفّر نقاط النهاية المختارة مخارج مختلفة أم أن بوابة دوّارة تحتفظ باتصال؟ احسم أولًا ما إذا كان التطبيق قد أرسل المسار الذي زعم اختياره. وإلا فقد يخفي تخمين من جهة المزوّد متغيّرًا قديمًا بسيطًا لساعات.