Agar libproxy proksi URI qaytarsa-yu, keyingi soket to'g'ridan-to'g'ri ulansa, topshirishni tekshiring. libproxy siyosatni aniqlaydi; u ilova ochadigan har bir soketni ushlamaydi.

  1. Resurs haqida so'rang. Hujjatlashtirilgan libproxy 0.5 C API'da proksi fabrikasini yarating va haqiqiy manzil URL'ini so'rang.
  2. Tartiblangan nomzodlarni izohlang. HTTP, SOCKS va to'g'ridan-to'g'ri natijalar turlicha ishlov talab qiladi. Ularning ustuvorlik tartibini va ko'zda tutilgan muvaffaqiyatsizlik siyosatini saqlang.
  3. Iste'molchini sozlang. Tanlangan proksi turini, so'nggi nuqtani va autentifikatsiya tartibini ularni qo'llab-quvvatlaydigan transportga bering. Xom TCP soketi qaytarilgan URI'dan CONNECT yoki SOCKS muzokaralarini olmaydi.

Bitta javobni barcha manzillar uchun marshrut sifatida saqlamang va birinchi proksi bir marta muvaffaqiyatsiz bo'lgani uchun to'g'ridan-to'g'ri marshrutlashni doimiy qilmang.

Agar HTTP mijozi allaqachon tizim proksisi yoki PAC aniqlashini birlashtirgan bo'lsa, tanlovning bitta egasini tanlang. Ikki mustaqil tanlagich va yana bitta o'ram ikkala siyosat ham ko'zlamagan marshrutni keltirib chiqarishi mumkin.

Mahalliy kodda o'rnatilgan API'ning fabrika va natija xotirasi hayot davriga rioya qiling. Fabrikani qayta ishlatish foydali aniqlash holatini saqlab qolishi mumkin, lekin har bir manzil uchun baribir so'rov talab qiladi. Tanlovni ulanish natijasidan alohida jurnalga yozing: qaytarilgan URI muvaffaqiyatli autentifikatsiya, yechim yoki keyingi kirishni isbotlamaydi.

O'xshash maqolalar