3proxy प्रयोग गरी SOCKS ग्राहकहरूलाई HTTP CONNECT अभिभावकमा जोड्नुहोस्

अनुप्रयोगलाई SOCKS चाहिन्छ। तपाईंको स्वीकृत अपस्ट्रिम सेवाले HTTP CONNECT स्वीकार्छ। अनुप्रयोगको SOCKS फिल्डमा HTTP एन्डपोइन्ट राख्नाले प्रोटोकलबीच अनुवाद हुँदैन।

गेटवेले अनुप्रयोगबाट SOCKS लिन सक्छ, अनुरोध गरिएको गन्तव्य पढ्न सक्छ र त्यो गन्तव्यसम्म CONNECT सुरुङका लागि HTTP अभिभावकसँग माग्न सक्छ। त्यसपछि यसले अनुप्रयोगको स्ट्रिम सुरुङमार्फत पठाउँछ।

SOCKS application → SOCKS-facing gateway → HTTP CONNECT parent → destination

प्रत्येक इन्टरफेस स्पष्ट बनाउनुहोस्

यो व्यवस्था समर्थन गर्ने गेटवेका लागि यसको अभिभावक प्रकार महत्त्वपूर्ण हुन्छ। 3proxy को कागजातले connect अभिभावकलाई साधारण HTTP फर्वार्डिङ प्रोक्सीका रूपमा प्रयोग हुने अभिभावकबाट छुट्याउँछ।

विद्यमान 3proxy प्रयोगकर्ता र प्रमाणीकरण सेटअप भएमा, स्थानीय-मात्र राउटिङ खण्ड यस्तो हुन सक्छ:

auth strong
allow alex
parent 1000 connect parent.example.net 8080
socks -i127.0.0.1 -p1080

यो खण्डले खाता पहिले नै परिभाषित भएको मान्छ। यसले HTTP अभिभावक आफैंले माग्ने कुनै पनि प्रमाणपत्र थप्दैन र विद्यमान पहुँच नीति प्रतिस्थापन गर्दैन। प्रमाणीकरण नभएको सार्वजनिक HTTP अभिभावकलाई अनुमति दिने मार्गमा सार्वजनिक गन्तव्यहरूका लागि, HTTP प्रोक्सी सूची ले होस्ट र पोर्टका उम्मेदवार दिन्छ। त्यो शाखाका लागि अभिभावक प्रमाणपत्र अनुपस्थित राख्नुहोस् र वास्तविक लक्ष्यका लागि अनुमति पुष्टि गर्नुहोस्; गेटवेको आफ्नै खाता स्थानीय रहन्छ। parent नियम 3proxy को कागजातमा उल्लेखित कन्फिगरेसन मोडेलअनुसार अघिल्लो allow नियमसँग सम्बन्धित छ।

अनुप्रयोगले स्थानीय SOCKS एन्डपोइन्ट प्रयोग गर्छ। गेटवेले अभिभावकतर्फ HTTP CONNECT प्रयोग गर्छ। अनुरोध गरिएको गन्तव्य होस्ट र पोर्ट अनुमत छन् कि छैनन् अझै अभिभावकले नै निर्णय गर्छ।

यहाँ उपयोगी दायरा साधारण TCP स्ट्रिम सुरुङ हो। अगाडिको श्रोताले SOCKS5 स्वीकार गर्छ भन्ने मात्रले SOCKS5 UDP सहयोग समर्थित हुँदैन। HTTP CONNECT अभिभावकले आवश्यक UDP रिले स्वतः दिँदैन।

HTTPS यस मार्गभित्र अन्त्यदेखि अन्त्यसम्म रहन सक्छ; प्रोक्सी इन्टरफेसबीचको अनुवादका लागि गन्तव्य वेबसाइटको नक्कल गर्नु आवश्यक छैन। गेटवे, अभिभावक र वेबसाइटका प्रमाणीकरण भने फरक प्रमाणपत्र र आदानप्रदान रहन्छन्।