আপনার লগ প্রক্সি ঘোরায়। আপনার অনুরোধ এখনও পুরোটাই ব্যবহার করে।
নির্বাচিত প্রান্তবিন্দুকে প্রকৃত 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 না বদলায়, তাহলে আপনি অন্য প্রশ্নে পৌঁছেছেন: নির্বাচিত প্রান্তবিন্দুগুলো আলাদা প্রস্থান দেয় কি না, নাকি ঘূর্ণায়মান গেটওয়ে একটি সংযোগ ধরে রাখে। প্রথমে নিশ্চিত করুন অ্যাপ্লিকেশনটি সত্যিই দাবি করা রুটটি পাঠিয়েছে কি না। নাহলে প্রদানকারীর অনুমান একটি সাধারণ পুরনো ভেরিয়েবল ঘণ্টার পর ঘণ্টা লুকাতে পারে।