URL बॉक्स असलेले पान हे वेब अ‍ॅप्लिकेशन आहे. तिथे गंतव्य टाकल्यास त्या अ‍ॅप्लिकेशनला सामग्री आणून दाखवायला सांगितले जाते. ब्राउझरला HTTP किंवा SOCKS प्रॉक्सी वापरण्यास सांगण्यापेक्षा ही वेगळी रचना आहे.

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

वर्तनफरक का महत्त्वाचा
समान-मूळ तपासण्याब्राउझर प्रत्यक्षात लोड केलेल्या मूळाचे मूल्यांकन करतो
कुकीज आणि रीडायरेक्टडोमेन, मार्ग आणि सुरक्षित संदर्भाचे वर्तन दाखवलेल्या URL शी जुळले पाहिजे
नवीन URL तयार करणाऱ्या स्क्रिप्टविनंत्या साध्या दुवे-पुनर्लेखन योजनेतून सुटू शकतात
कायमस्वरूपी कनेक्शन किंवा WebSocketsप्रॉक्सी अ‍ॅप्लिकेशनला स्पष्ट सुसंगत हाताळणी हवी

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

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

लक्ष्य दुसर्‍या एक्झिटमधून साधे ब्राउझिंग असेल, तर तुमच्या सेवेकडून किंवा प्रॉक्सी यादीतून HTTP किंवा SOCKS एंडपॉइंट निवडा आणि समर्थित नेटिव्ह प्रॉक्सी कॉन्फिगरेशन वापरा, जसे की Firefox ची कनेक्शन सेटिंग्ज. हे सहसा ब्राउझरच्या सामान्य गंतव्य-अर्थाचा अधिक भाग टिकवते. URL-फील्ड असलेली साइट जाणीवपूर्वक निवडलेले अ‍ॅप्लिकेशन असू शकते, पण कमी सेटअपसह तेच इंटरफेस म्हणून सादर करू नये.

संबंधित लेख