ब्राउजरले Squid मार्फत HTTP पृष्ठ लोड गर्छ। त्यही लक्ष्य proxychains अन्तर्गत असफल हुन्छ। यसको अर्थ दुईमध्ये कुनै एक कार्यक्रमले गलत प्रोक्सी IP रोज्यो भन्ने मात्र होइन।

सामान्य HTTP बुझ्ने क्लाइन्टले वेब अनुरोधलाई HTTP प्रोक्सी ढाँचामा अगाडिको प्रोक्सीमा पठाउन सक्छ। तर सामान्य सकेट आवरणलाई एप्लिकेसनले खोल्न चाहेको जडानका लागि बाइट सुरुङ चाहिन्छ। आफ्नो शृंखलामा रहेको HTTP प्रोक्सीका लागि proxychains ले CONNECT प्रयोग गर्छ।

यसको अर्थ पोर्ट 80 मा रहेको सादा पाठ वेबसाइटले पोर्ट 80 का लागि CONNECT अनुरोध उत्पन्न गर्न सक्छ। केवल स्वीकृत TLS पोर्ट सूचीतर्फ CONNECT अनुमति दिने Squid नीतिले त्यो सुरुङ अस्वीकार गर्न सक्छ, यद्यपि पोर्ट 80 मा सामान्य HTTP अनुरोधहरू अनुमति छन्।

केवल होस्टनाम होइन, अनुरोधहरू तुलना गर्नुहोस्

proxychains-ng को कागजातले यसको HTTP CONNECT समर्थन वर्णन गर्छ। Squid का पहुँच नियमहरूले विधि र लक्ष्य पोर्ट छुट्याउन सक्छन्। यी एउटै वेबसाइटतर्फका फरक अनुरोध मार्गहरू हुन्।

परिवर्तन गर्नुअघि अस्वीकृति र अभिप्रेत नीति पढ्नुहोस्। CONNECT पहुँचलाई हरेक पोर्टसम्म विस्तार गर्नु ठूलो परिवर्तन हो; आवरणको असामञ्जस्यका लागि यो पूर्वनिर्धारित प्रतिक्रिया हुनु हुँदैन।

यदि एप्लिकेसनसँग मूल HTTP प्रोक्सी समर्थन छ भने, यसको प्रयोगले सादा पाठ HTTP का लागि अनावश्यक सामान्य सुरुङबाट बच्न सक्छ। यदि यसलाई साँच्चै कच्चा TCP सुरुङ चाहिन्छ भने, त्यो उपलब्ध गराउने स्वीकृत प्रोक्सी प्रोटोकल र पोर्ट नीति छान्नुहोस्।

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

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