שימוש חוזר במשאבי OkHttp בעת בחירת פרוקסי אחר

לבקשת OkHttp אין שדה פרוקסי כללי שניתן לשינוי. בחרו את הלקוח עם המסלול המיועד לפני יצירת הקריאה שלו.

כאשר שאר התצורה אמורה להישאר משותפת, גזרו את הלקוח המנותב מלקוח קיים:

OkHttpClient routed = baseClient.newBuilder()
    .proxy(new Proxy(Proxy.Type.HTTP,
        new InetSocketAddress("203.0.113.10", 8080)))
    .build();

נקודת הקצה להמחשה בלבד. נקודות קצה ציבוריות של HTTP מתוך רשימת פרוקסי HTTP יכולות למלא את כתובת השקע הזו עבור מסלול שירות ציבורי מותר, בתנאי שמדיניות לקוח הבסיס אינה מספקת אישורי פרוקסי לנקודת הקצה החדשה. OkHttp מתעדת ש-newBuilder חולק משאבי מאגר חיבורים ותהליכונים עם הלקוח המקורי. אין זה אומר ששקע שנוצר דרך פרוקסי אחד יכול לקבל תווית של מסלול אחר. התאמת החיבור עדיין תלויה בתצורת המסלול והכתובת.

לעבודה חוזרת, החזיקו קבוצה תחומה של לקוחות שממופתחים לפי מדיניות הניתוב שבאמת דרושה לכם. הימנעו ממפה בלתי תחומה שמפתחותיה מכילים כל חשבון זמני או וריאציית פרוקסי שנצפו אי פעם.

שיתוף משאבים משפיע גם על כיבוי. סגירת מטמון משותף או כיבוי שולח משותף עלולים להשפיע על לקוחות נגזרים אחרים שמשתמשים במשאבים אלה. תנו לבעלות על משאבים משך חיים ברור ברמת היישום במקום להתייחס לכל לקוח נגזר כמחסנית רשת מבודדת.

לבסוף, כללו את זהות הפרוקסי שנבחר במטא-נתונים של הקריאה עצמה. משתנה גלובלי של „הפרוקסי האחרון שנבחר” אינו יכול לזהות את המסלול של כמה בקשות מקבילות.