ब्राउझर 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 बोगदा हवा असेल, तर तो पुरवणारे मंजूर प्रॉक्सी प्रोटोकॉल आणि पोर्ट धोरण निवडा.

यशस्वी ब्राउझर विनंती प्रॉक्सीच्या पोहोच आणि एका समर्थित विनंती पद्धतीबद्दल उपयुक्त पुरावा आहे. परंतु प्रत्येक बोगदा पद्धत, लक्ष्य पोर्ट किंवा अनुप्रयोग प्रोटोकॉल त्या प्रॉक्सीमधून परवानगीचा आहे हे ते सिद्ध करत नाही.

संबंधित लेख