libproxy בוחר מסלול; הלקוח שלך יוצר את החיבור
השתמש בתוצאות libproxy כמועמדות ניתוב לכל URL במקום לצפות שהגילוי יפנה מחדש את הסוקטים של היישום.
אם libproxy מחזיר URI של פרוקסי בעוד הסוקט הבא מתחבר ישירות, בדוק את המסירה. libproxy מגלה מדיניות; הוא אינו מיירט כל סוקט שהיישום פותח.
- שאל על המשאב. ב-C API המתועד של libproxy 0.5, צור מפעל פרוקסי ובקש את כתובת ה-URL האמיתית של היעד.
- פרש את המועמדים הממוינים. תוצאות HTTP, SOCKS וישירות דורשות טיפול שונה. שמור על סדר העדפה ועל מדיניות הכשל המיועדת.
- הגדר את הצרכן. מסור את סוג הפרוקסי הנבחר, נקודת הקצה וסדר האימות לתעבורה שתומכת בהם. סוקט TCP גולמי אינו מקבל משא ומתן CONNECT או SOCKS מ-URI שהוחזר.
אל תשמור תשובה אחת כמסלול לכל היעדים ואל תהפוך ניתוב ישיר לקבוע רק משום שהפרוקסי הראשון נכשל פעם אחת.
אם לקוח ה-HTTP כבר משלב פרוקסי מערכת או גילוי PAC, בחר בעלים אחד לבחירה. שני בוררים עצמאיים ועוד עטיפה אחת עלולים ליצור מסלול שאף אחת משתי המדיניות לא התכוונה לו.
בקוד מקורי, פעל לפי מחזור החיים של המפעל וזיכרון התוצאות של ה-API המותקן. שימוש חוזר במפעל יכול לשמור מצב גילוי שימושי, אך הוא עדיין דורש שאילתה לכל יעד. רשום את הבחירה בנפרד מתוצאת החיבור: URI שהוחזר אינו מוכיח אימות, פענוח או גישה נוספת מוצלחים.