स्पष्ट प्रोक्सीको पछाडिको शाखा ब्राउजरले दुई जडान खोल्छ, र ती फरक कारणले असफल हुन्छन्। पहिलो ब्राउजरबाट प्रोक्सी सुन्नेसम्म, जुन शाखा VPN मार्फत जान्छ। दोस्रो प्रोक्सीबाट वेबसाइटसम्म, प्रोक्सीको आफ्नै रिजोल्भर, मार्ग र बहिर्गमन नीति प्रयोग गरेर। यी दुवैलाई एउटै प्रवाह मान्ने समर्थन टिकटहरूले मानिसहरूलाई घण्टौंसम्म गलत यन्त्रकहाँ पठाउँछन्। हरेकलाई जानाजानी सेट गर्नुहोस् र त्यही क्रममा परीक्षण गर्नुहोस्।

चरण 1: दुवै प्रवाह लेख्नुहोस्

ब्राउजरको तत्काल गन्तव्य प्रोक्सी सुन्ने हो, प्रयोगकर्ताले अन्ततः भ्रमण गर्ने हरेक साइट होइन। त्यो एउटा वाक्यले यो डिजाइनको अधिकांश अन्योल हल गर्छ।

branch browser -> site VPN -> central proxy listener
central proxy -> approved egress policy -> website

फरक स्रोत, फरक मार्ग, फरक अनुमति। परिवर्तन अभिलेखमा स्केच राख्नुहोस्, किनकि प्रत्येक पछिल्लो जाँचले यसका दुई आधामध्ये एउटालाई सन्दर्भ गर्छ।

चरण 2: ब्राउजरलाई सुन्नेसम्म मार्ग दिनुहोस्

प्रोक्सी होस्टनाम, सुन्ने पोर्ट, प्रमाणीकरण आवश्यकता र अनुमति दिइएका शाखा स्रोतहरू रेकर्ड गर्नुहोस्। त्यो सूची पहिलो प्रवाहको स्वीकृति मापदण्ड हो, र यसमा निजी नाम रिजोल्युसन तथा सुरुङ मार्ग दुवै समावेश हुनुपर्छ।

इन्टरनेटमा अप्रतिबन्धित प्रोक्सी प्रकाशित गर्नुको सट्टा इच्छित सेवाका लागि साँघुरो सञ्जाल नियम लागू गर्नुहोस्। इच्छित ग्राहकहरूसँग त्यहाँसम्म समर्थित मार्ग भए प्रोक्सी आन्तरिक सञ्जालमै रहन सक्छ।

चरण 3: केवल मार्ग तालिका होइन, ब्राउजर कन्फिगर गर्नुहोस्

ब्राउजरको प्रोक्सी सेटिङ, PAC फाइल वा संस्थाको व्यवस्थापित पत्ता लगाउने संयन्त्र प्रयोग गर्नुहोस्। मार्गसहित सामान्य वेबसाइट प्याकेट प्रोक्सी ठेगानातर्फ पठाउँदा ब्राउजरले प्रोक्सी प्रोटोकल बोल्न थाल्दैन; त्यो पारदर्शी अवरोध हो र अर्को गेटवे डिजाइनमा पर्छ।

कुन अनुप्रयोगहरूले सेटिङको सम्मान गर्छन् लेख्नुहोस्। मेल क्लाइन्ट, अपडेटर र खेलहरूले प्रायः सम्मान गर्दैनन्, र ती सामान्य मार्ग प्रयोग गरिरहन्छन्।

चरण 4: प्रोक्सीको अगाडिको जडान प्रमाणित गर्नुहोस्

प्रोक्सीलाई आफ्नै रिजोल्भर र वेबसाइटसम्म अनुमति दिइएको मार्ग चाहिन्छ, साथै यसको इन्टरनेट सीमाले आवश्यक ठान्ने फायरवाल वा अनुवाद नीति पनि। सुन्नेसम्म पुग्ने ब्राउजरले यीमध्ये केही पनि प्रमाणित गर्दैन। दोस्रो प्रवाह प्रोक्सीबाटै, प्रयोगकर्ताले जनाएको त्यही गन्तव्य र पोर्ट प्रयोग गरी परीक्षण गर्नुहोस्।

HTTPS का लागि, CONNECT ले अनुरोध गरिएको गन्तव्यसम्म सुरुङ खोल्छ। सामान्य फर्वार्डिङले प्रोक्सीलाई डिक्रिप्ट गरिएको पृष्ठ दिँदैन, र निरीक्षण गर्न प्रमाणपत्र प्रमाणीकरण बन्द गर्नु समाधान होइन।

चरण 5: चार असफलता छुट्याउनुहोस्

प्रोक्सी प्रमाणीकरण चुनौती सुन्नेबाट आउने 407 हो। अस्वीकृत CONNECT प्रोक्सीमा नीति निर्णय हो, सामान्यतया आफ्नै स्थिति र लग लाइनसहित। असफल अगाडिको जडान प्रोक्सीले गन्तव्यविरुद्ध अभिलेख गर्ने समय समाप्ति वा रिसेटजस्तो देखिन्छ। वेबसाइटको प्रतिक्रिया भनेको दुवै जडानले काम गरे र समस्या स्रोतमा छ।

VPN असफल भयो भन्ने सारांश होइन, तपाईंले देख्नुभएको सीमा रिपोर्ट गर्नुहोस्।

चरण 6: दायरा निर्धारण गर्नुहोस् र विकल्प योजना बनाउनुहोस्

प्रोक्सी वा सुरुङ उपलब्ध नभएपछि के हुन्छ निर्धारण गर्नुहोस्, र यो डिजाइनले कुन ट्राफिक समेट्छ स्पष्ट भन्नुहोस्। यसले प्रोक्सी सेटिङको सम्मान गर्ने ग्राहकबाट वेब पहुँच बोक्छ; यसले मेल, जथाभावी यन्त्र प्रोटोकल वा कन्फिगरेसन बेवास्ता गर्ने सफ्टवेयर बोक्दैन।

डिजाइनलाई थप ग्राहकसम्म विस्तार गर्नुअघि स्वीकृत योजनाअन्तर्गत आवश्यक ब्राउजर सञ्चालन र एउटा आवश्यक अस्वीकृति प्रमाणित गर्नुहोस्।

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