OkHttp अनुरोधमा सामान्य परिवर्तनयोग्य प्रोक्सी फिल्ड हुँदैन। यसको कल सिर्जना गर्नु अघि इच्छित मार्ग भएको क्लाइन्ट छनोट गर्नुहोस्।

जब बाँकी कन्फिगरेसन साझा रहनुपर्छ, तब विद्यमान क्लाइन्टबाट मार्गित क्लाइन्ट प्राप्त गर्नुहोस्:

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

अन्तिम बिन्दु केवल उदाहरण हो। HTTP प्रोक्सी सूची का सार्वजनिक HTTP अन्तिम बिन्दुहरूले अनुमत सार्वजनिक-सेवा मार्गका लागि यो सकेट ठेगाना भर्न सक्छन्, यदि आधार क्लाइन्टको नीतिले नयाँ अन्तिम बिन्दुलाई कुनै प्रोक्सी प्रमाणहरू दिँदैन भने। OkHttp ले newBuilder ले जडान-पूल र थ्रेड स्रोतहरू मूल क्लाइन्टसँग साझा गर्छ भनी दस्तावेज गर्छ। यसको अर्थ एक प्रोक्सीमार्फत स्थापित सकेटलाई अर्को मार्गका रूपमा पुनः लेबल गर्न सकिन्छ भन्ने होइन। जडानको योग्यता अझै मार्ग र ठेगाना कन्फिगरेसनमा निर्भर छ।

दोहोरिने कामका लागि, तपाईंलाई वास्तवमै आवश्यक पर्ने राउटिङ नीतिले कुञ्जी गरिएको सीमित क्लाइन्ट सेट राख्नुहोस्। अहिलेसम्म देखिएका सबै अस्थायी खाता वा प्रोक्सी भिन्नताहरू कुञ्जीमा समेट्ने असीमित नक्साबाट बच्नुहोस्।

स्रोत साझेदारीले बन्द गर्न पनि असर गर्छ। साझा क्यास बन्द गर्नु वा साझा डिस्प्याचर बन्द गर्नुले ती स्रोतहरू प्रयोग गर्ने अन्य व्युत्पन्न क्लाइन्टहरूलाई असर गर्न सक्छ। प्रत्येक व्युत्पन्न क्लाइन्टलाई अलग नेटवर्क स्ट्याक मान्नुको सट्टा स्रोत स्वामित्वलाई स्पष्ट अनुप्रयोग-स्तरीय आयु दिनुहोस्।

अन्तमा, छनोट गरिएको प्रोक्सीको पहिचान कलको आफ्नै मेटाडेटामा समावेश गर्नुहोस्। विश्वव्यापी “अन्तिम छनोट गरिएको प्रोक्सी” चरले धेरै समवर्ती अनुरोधहरूको मार्ग पहिचान गर्न सक्दैन।

सम्बन्धित लेखहरू