दोन प्रॉक्सी सेटिंग्ज अशी साखळी तयार करू शकतात ज्याचा तुम्ही विचार केला नव्हता

तुमचे अ‍ॅप्लिकेशन प्रॉक्सी B कडे निर्देश करते, पण ते प्रॉक्सी A साठी कॉन्फिगर केलेल्या रॅपरद्वारे सुरू केले गेले आहे. वेबसाइट कोणते एक्झिट पाहते? उत्तर रॅपर कोणते कनेक्शन अडवते यावर अवलंबून आहे.

साध्या नेस्टेड मांडणीत, अ‍ॅप्लिकेशन प्रथम B शी जोडण्याचा प्रयत्न करते. रॅपर ते कनेक्शन अडवते आणि A मधून नेते. नंतर अ‍ॅप्लिकेशन तयार झालेल्या स्ट्रीमवर B चा प्रॉक्सी प्रोटोकॉल बोलते, आणि B अंतिम वेबसाइट कनेक्शन करते.

application → wrapper proxy A → application proxy B → website

वेबसाइट B चे अंतिम बाह्य कनेक्शन पाहते. B A मधून येणारे कनेक्शन पाहते. हे रॅपरने अ‍ॅप्लिकेशनची स्वतःची प्रॉक्सी सेटिंग गुपचूप ओव्हरराइट करण्यापेक्षा वेगळे आहे.

साध्या आकृतीला अटी आहेत

बायपास नियम, असमर्थित सॉकेट कॉल, विद्यमान प्रोसेस आणि प्रत्येक उत्पादनाचे इंटरसेप्शन मॉडेल मार्ग बदलू शकतात. काही रॅपर त्यांचे स्वतःचे प्रॉक्सी किंवा निवडलेली गंतव्ये वगळू शकतात. प्रत्येक जोडी साधने एकाच पद्धतीने जोडली जाते असे गृहीत धरू नका.

proxychains-ng चे वर्णन त्याची इंटरसेप्शन पद्धत आणि मर्यादा स्पष्ट करते. मूळ प्रॉक्सी समर्थन वापरणारा प्रोग्राम त्या प्रॉक्सीशी नेटवर्क कनेक्शन करतोच, जे इंटरसेप्शनसाठी एक उमेदवार आहे.

अप्रमाणित सार्वजनिक एंडपॉइंट्सच्या हेतुपूर्वक साखळीसाठी, मोफत प्रॉक्सी सूची असे उमेदवार देते ज्यांचे प्रोटोकॉल प्रत्येक साधनाशी जुळले पाहिजेत. अनपेक्षित एक्झिटसाठी, तीन पत्ते स्वतंत्रपणे नोंदवा: अ‍ॅप्लिकेशनने निवडलेला एंडपॉइंट, रॅपरने निवडलेला एंडपॉइंट, आणि वेबसाइटला दिसणारा निकाल. फक्त ब्राउझरची सेटिंग्ज पाहिल्यास मधला थर चुकतो.

इच्छित वर्तन स्थापित करताना एक मार्ग वापरा, नंतर साखळी आवश्यक असेल तरच दुसरा जोडा. अतिरिक्त हॉप अयशस्वीतेचे मुद्दे आणि वेगळे विश्वासाचे संबंध जोडू शकतात. ते आपोआप ओळखणारी कुकीज पुसत नाहीत किंवा अ‍ॅप्लिकेशनमधील प्रत्येक कनेक्शन एकाच मार्गाने जात नाही.