libproxy راستہ چنتا ہے؛ کنکشن آپ کا کلائنٹ بناتا ہے
libproxy کے نتائج کو ہر URL کے لیے روٹنگ امیدواروں کے طور پر استعمال کریں، بجائے اس کے کہ دریافت ایپلیکیشن کے ساکٹ ری ڈائریکٹ کرے گی۔
اگر libproxy پراکسی URI واپس کرتا ہے جبکہ اگلا ساکٹ براہِ راست جڑتا ہے، تو حوالگی جانچیں۔ libproxy پالیسی دریافت کرتا ہے؛ یہ ایپلیکیشن کے کھولے ہر ساکٹ کو روکتا نہیں۔
- وسیلے کے بارے میں پوچھیں۔ دستاویزی libproxy 0.5 C API میں پراکسی فیکٹری بنائیں اور اصل منزل URL طلب کریں۔
- ترتیب شدہ امیدواروں کی تشریح کریں۔ HTTP، SOCKS اور براہِ راست نتائج کو مختلف طریقۂ کار درکار ہے۔ ان کی ترجیحی ترتیب اور مطلوبہ ناکامی پالیسی برقرار رکھیں۔
- صارف کو ترتیب دیں۔ منتخب پراکسی قسم، اینڈ پوائنٹ اور تصدیق کا انتظام ایسی ترسیل کو دیں جو ان کی معاونت کرے۔ خام TCP ساکٹ واپس شدہ URI سے CONNECT یا SOCKS مذاکرات حاصل نہیں کرتا۔
ایک جواب کو تمام منزلوں کے لیے راستہ بنا کر محفوظ نہ کریں اور پہلی پراکسی کے ایک بار ناکام ہونے پر براہِ راست روٹنگ کو مستقل نہ بنائیں۔
اگر HTTP کلائنٹ پہلے ہی سسٹم پراکسی یا PAC دریافت کو شامل کرتا ہے، تو انتخاب کا ایک ہی مالک چنیں۔ دو خودمختار منتخب کنندگان اور ایک اور ریپر ایسا راستہ بنا سکتے ہیں جو کسی پالیسی کا مقصود نہ تھا۔
مقامی کوڈ میں نصب شدہ API کی فیکٹری اور نتائج کی یادداشت کے حیاتی چکر کی پیروی کریں۔ فیکٹری کا دوبارہ استعمال مفید دریافت حالت برقرار رکھ سکتا ہے، لیکن ہر منزل کے لیے پھر بھی استفسار درکار ہے۔ انتخاب کو کنکشن کے نتیجے سے الگ لاگ کریں: واپس شدہ URI کامیاب تصدیق، حل یا مزید رسائی کا ثبوت نہیں۔