libproxy مسیر را انتخاب می‌کند؛ کلاینت شما اتصال را برقرار می‌کند
نتایج libproxy را به‌جای انتظار برای تغییرمسیر سوکت‌های برنامه توسط کشف، به‌عنوان نامزدهای مسیریابی هر URL به کار ببرید.
اگر libproxy یک URI پراکسی برمی‌گرداند در حالی که سوکت بعدی مستقیم وصل می‌شود، تحویل را بررسی کنید. libproxy خط‌مشی را کشف می‌کند؛ هر سوکتی را که برنامه باز می‌کند رهگیری نمی‌کند.
- درباره منبع بپرسید. در API مستند C نسخه 0.5 libproxy یک کارخانه پراکسی بسازید و URL مقصد واقعی را بخواهید.
- نامزدهای مرتب‌شده را تفسیر کنید. نتایج HTTP، SOCKS و مستقیم به برخورد متفاوتی نیاز دارند. ترتیب ترجیح و خط‌مشی شکست موردنظر را حفظ کنید.
- مصرف‌کننده را پیکربندی کنید. نوع پراکسی انتخاب‌شده، نقطه پایانی و ترتیب احراز هویت را به یک لایه انتقال که آن‌ها را پشتیبانی می‌کند بدهید. یک سوکت خام TCP از URI برگشتی مذاکره CONNECT یا SOCKS به دست نمی‌آورد.
یک پاسخ را به‌عنوان مسیر همه مقصدها ذخیره نکنید و مسیریابی مستقیم را فقط به این دلیل که پراکسی نخست یک بار شکست خورد دائمی نکنید.
اگر کلاینت HTTP از قبل پراکسی سیستم یا کشف PAC را یکپارچه کرده است، یک مالک انتخاب برگزینید. دو انتخاب‌گر مستقل به‌همراه یک پوشش دیگر می‌توانند مسیری بسازند که هیچ‌یک از دو خط‌مشی آن را نمی‌خواست.
در کد بومی، چرخه عمر کارخانه و حافظه نتایج API نصب‌شده را رعایت کنید. استفاده مجدد از یک کارخانه می‌تواند وضعیت کشف مفیدی را نگه دارد، اما همچنان برای هر مقصد به یک پرس‌وجو نیاز دارد. انتخاب را جدا از نتیجه اتصال ثبت کنید: URI برگشتی احراز هویت، تفکیک یا دسترسی بعدی موفق را اثبات نمی‌کند.