ब्राउज़र 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 सुरंग चाहिए, तो ऐसा स्वीकृत प्रॉक्सी प्रोटोकॉल और पोर्ट नीति चुनें जो उसे प्रदान करे।

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

संबंधित लेख