एक प्रॉक्सी सर्वर कैसे काम करता है?

Scrapeless Proxies प्रबंधित प्रॉक्सी निकास के माध्यम से एप्लिकेशन ट्रैफ़िक को रूट करने के लिए प्रमाणित गेटवे कनेक्शन प्रदान करते हैं।

एक प्रॉक्सी सर्वर एक क्लाइंट से ट्रैफ़िक स्वीकार करके और क्लाइंट की ओर से दूसरे सर्वर के साथ संवाद करके काम करता है। एक फॉरवर्ड प्रॉक्सी के लिए, क्लाइंट गंतव्य का चयन करता है और प्रॉक्सी के माध्यम से अनुरोध भेजता है। गंतव्य का प्रतिक्रिया फिर प्रॉक्सी के माध्यम से क्लाइंट को वापस आती है।

विवरण प्रोटोकॉल पर निर्भर करते हैं। एक HTTP प्रॉक्सी पठनीय HTTP संदेशों को अग्रेषित कर सकता है, HTTPS गंतव्य के लिए एक टनल बना सकता है, या यातायात पर समर्थित नीति लागू कर सकता है। एक SOCKS प्रॉक्सी अलग लेयर पर कनेक्शन का बातचीत करता है। प्रत्येक कूद को यह समझने के लिए कनेक्शन जीवनचक्र का पालन करें कि प्रत्येक कूद क्या देख सकता है और कौन से सेटिंग्स इसे नियंत्रित करती हैं।

चरण 1: ग्राहक एक मार्ग का चयन करता है

ग्राहक यह तय करता है कि अनुरोध सीधे गंतव्य पर जाता है या एक प्रॉक्सी के माध्यम से। वह निर्णय एप्लिकेशन विकल्पों, वातावरण सेटिंग्स, एक ऑपरेटिंग-सिस्टम कॉन्फ़िगरेशन, या एक ब्राउज़र के कॉन्फ़िगर किए गए रूटिंग नियमों से आ सकता है।

एक प्रॉक्सी सेटिंग आमतौर पर एक प्रोटोकॉल, गेटवे होस्ट, पोर्ट, और किसी भी प्रमाणपत्र की पहचान करती है। गंतव्य URL वह संसाधन होता है जिसे आप अनुरोध करना चाहते हैं। गंतव्य होस्ट को प्रॉक्सी होस्ट के साथ बदलने से संसाधन की पहचान के साथ मार्ग को भ्रमित कर देता है।

अलगाव सेटिंग्स कुछ गंतव्यों को सीधे भेज सकती हैं। एक आंतरिक सेवा जानबूझकर एक बाहरी प्रॉक्सी से बच सकती है, जबकि एक अनुमोदित क्षेत्रीय परीक्षण को इसका उपयोग करना चाहिए। जब एक अनुरोध अपेक्षित निकास दिखाता है और दूसरा नहीं, तो उन अलगावों का निरीक्षण करें।

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

चरण 2: गेटवे कनेक्शन स्वीकार करता है

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

ग्राहक को इच्छित प्रोटोकॉल और पोर्ट पर गेटवे तक पहुंचना चाहिए। एक TCP कनेक्शन पहुंच योग्यता की पुष्टि करता है, लेकिन गेटवे फिर भी क्रेडेंशियल को अस्वीकार कर सकता है या गंतव्य की अनुमति नहीं दे सकता है। पहुंच योग्यता और प्राधिकरण को अलग-अलग जांच के रूप में रखें।

HTTP प्रॉक्सी प्रमाणीकरण एक प्रॉक्सी-विशिष्ट चुनौती उत्पन्न कर सकता है। HTTP प्रॉक्सी-प्रमाणीकरण अर्थशास्त्र एक प्रॉक्सी प्रमाणीकरण आवश्यकता को ओरिजिन सर्वर की प्रमाणीकरण आवश्यकता से अलग करें। प्रॉक्सी के लिए क्रेडेंशियल्स उस सीमा के प्रॉक्सी पक्ष पर बने रहने चाहिए।

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

चरण 3: सामान्य HTTP आगे बढ़ाया जाता है

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

अनुरोध प्रॉक्सी को बताता है कि कौन सा मूल संसाधन आवश्यक है। प्रॉक्सी एक अपस्ट्रीम कनेक्शन स्थापित करता है या पुनः उपयोग करता है और उपयुक्त अनुरोध को आगे भेजता है। प्रतिक्रिया उसी तार्किक श्रृंखला के माध्यम से लौटती है, हालांकि इनबाउंड और आउटबाउंड कनेक्शन अलग होते हैं।

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

The फॉरवर्ड-प्रॉक्सी और टनलिंग मॉडल यह भी क्लाइंट के लिए कार्यरत एक फॉरवर्ड प्रॉक्सी और एक मूल सेवा के लिए कार्यरत एक रिवर्स प्रॉक्सी के बीच भेद करता है। ट्रैफिक की दिशा Alone पर्याप्त नहीं है; कुंजी यह है कि मध्यवर्ती किस पक्ष का प्रतिनिधित्व करता है।

चरण 4: HTTPS एक टनल स्थापित करता है

HTTPS गंतव्य के लिए जो HTTP प्रॉक्सी के माध्यम से पहुँचा जाता है, क्लाइंट आम तौर पर प्रॉक्सी से गंतव्य होस्ट और पोर्ट के लिए एक CONNECT टनल बनाने का अनुरोध करता है। सफल टनल सेटअप के बाद, क्लाइंट टनल के माध्यम से गंतव्य TLS विनिमय करता है।

प्रॉक्सी योजना क्लाइंट-से-प्रॉक्सी परिवहन को वर्णित करती है। गंतव्य योजना लक्षित अनुप्रयोग कनेक्शन को वर्णित करती है। एक HTTP प्रॉक्सी एक HTTPS गंतव्य को ले जा सकता है, और एक प्रॉक्सी जो TLS का समर्थन करता है, वह अपनी खुद की प्रवेश कूद को भी सुरक्षित कर सकता है। ये विभिन्न सुरक्षा सीमाएँ हैं।

साधारण सुरंग में बिना हस्तक्षेप के, प्रॉक्सी एन्क्रिप्टेड गंतव्य ट्रैफिक को अग्रेषित करता है न कि डिक्रिप्टेड पृष्ठ को पढ़ता है। यह अभी भी कनेक्शन मेटाडेटा को जानता है, जिसमें अनुरोधित सुरंग गंतव्य और समय शामिल है। एन्क्रिप्शन प्रॉक्सी ऑपरेटर को इस बात से अनजान नहीं करता कि एक कनेक्शन मौजूद है।

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

चरण 5: गंतव्य नाम हल किया गया है

गंतव्य DNS समाधान क्लाइंट या प्रॉक्सी पर हो सकता है, जो प्रोटोकॉल और क्लाइंट कॉन्फ़िगरेशन पर निर्भर करता है। गेटवे होस्टनेम को भी हल किया जाना चाहिए ताकि क्लाइंट प्रॉक्सी तक पहुंच सके।

SOCKS5 के लिए, अनुरोध एक डोमेन नाम या एक IP पते को ले जा सकता है। यदि क्लाइंट पहले लक्ष्य को हल करता है और इसका IP भेजता है, तो स्थानीय DNS पहले से ही भाग ले चुका होता है। यदि क्लाइंट प्रॉक्सी-साइड समाधान के लिए लक्ष्य होस्टनेम भेजता है, तो मार्ग उस लुकअप को सौंपता है।

ग cURL प्रॉक्सी कॉन्फ़िगरेशन अलग करता है socks5:// के लिए socks5h:// लक्ष्य-नाम समाधान। ये स्कीम लेबल क्लाइंट व्यवहार को व्यक्त करते हैं; इन्हें किसी भी प्रोग्राम के लिए सामान्यीकृत नहीं किया जाना चाहिए जब तक कि इसके कार्यान्वयन की जांच न की जाए।

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

चरण 6: प्रतिक्रिया क्लाइंट को वापस आती है

क्लाइंट या तो गंतव्य से प्रतिक्रिया प्राप्त करता है या एक मध्यस्थ द्वारा उत्पन्न प्रतिक्रिया प्राप्त करता है। कार्यप्रवाह को यह पहचानना चाहिए कि किस चरण ने परिणाम उत्पन्न किया है इससे पहले कि यह तय करे कि इसका क्या अर्थ है।

एक गेटवे किसी भी लक्ष्य कनेक्शन के मौजूद होने से पहले एक अप्रमाणीकृत अनुरोध को अस्वीकार कर सकता है। गंतव्य एक एक्सेस पृष्ठ वापस कर सकता है जब प्रॉक्सी कनेक्शन सफल हो जाता है। एक अपस्ट्रीम कनेक्शन भी विफल हो सकता है जब गेटवे क्लाइंट को स्वीकार कर लेता है। ये परिणाम जीवनचक्र के विभिन्न हिस्सों से संबंधित हैं।

सामग्री निकालते समय, स्थिति, अंतिम URL, प्रतिक्रिया प्रकार और आवश्यक क्षेत्रों की जांच करें। एक पृष्ठ जो साइन-इन स्क्रीन पर पुनर्निर्देशित करता है, एक सार्वजनिक-उत्पाद अवलोकन को संतुष्ट नहीं कर पाता है भले ही स्क्रीन सही तरीके से लोड होती हो। एक चुनौती शरीर के साथ एक सफल स्थिति भी एक सामग्री असंगति है।

ग HTTP और SOCKS कनेक्शन के उदाहरण यह दिखाते हैं कि क्लाइंट सेटिंग्स इन परतों के साथ कैसे मैप होती हैं। निदान आउटपुट का सावधानीपूर्वक उपयोग करें: हेडर, प्रमाणीकरण डेटा और URLs संवेदनशील संदर्भ प्रकट कर सकते हैं, इसलिए नियमित लॉग को साफ-सुथरे सबूतों तक सीमित रखें।

एक प्रॉक्सी सामग्री को कब कैश कर सकती है?

एक प्रॉक्सी केवल तब HTTP प्रतिक्रिया को कैश कर सकती है जब इसका तैनाती कैशिंग का समर्थन करती है और प्रतिक्रिया के कैश नियम इसे अनुमति देते हैं। HTTP कैशिंग नियम पुन: उपयोग, ताजगी और अनुरोध और प्रतिक्रिया निर्देशों के प्रबंधन को नियंत्रित करते हैं।

एक कैश की गई प्रतिक्रिया तब अपस्ट्रीम कार्य को कम कर सकती है जब वही कैश करने योग्य संसाधन फिर से अनुरोध किया जाता है। एक व्यक्तिगत या स्पष्ट रूप से गैर-कैश करने योग्य प्रतिक्रिया को अलग उपचार की आवश्यकता होती है। यह मान लेना कि एक प्रॉक्सी किसी भी पृष्ठ का सुरक्षित उपयोग कर सकती है केवल इसलिए कि URL समान है, गलत है।

एक सामान्य अपार HTTPS सुरंग अवरोहित प्रॉक्सी को डिक्रिप्टेड HTTP प्रतिक्रिया हेडर और सामग्री को उजागर नहीं करती है। यह सुरंग के भीतर ट्रैफ़िक पर प्रॉक्सी द्वारा सामग्री-सचेत कैशिंग के प्रकारों को सीमित करता है। एक रिवर्स प्रॉक्सी जो मूलद्वार पर TLS को समाप्त करता है, की एक अलग स्थिति होती है।

एक ताजगी-संवेदनशील कार्य के लिए, टाइमस्टैम्प और अपेक्षित अवलोकन संदर्भ को मान्य करें। एक तेज़ प्रतिक्रिया गलत प्रतिक्रिया हो सकती है यदि इसकी आयु मापन आवश्यकताओं में फिट नहीं बैठती है।

कौन सा घटक प्रत्येक सेटिंग को नियंत्रित करता है?

एक कामकाजी प्रॉक्सी मार्ग को क्लाइंट की सेटिंग्स, गेटवे की नीति और गंतव्य की प्रतिक्रिया अनुबंध की संधि की आवश्यकता होती है। प्रत्येक सेटिंग को स्वामित्व सौंपें बजाय इस प्रकार प्रॉक्सी URL को पूरी कॉन्फ़िगरेशन के रूप में मान्यता देने के।

स्क्रैपलेस प्रॉक्सी समाधान प्रबंधित कॉन्फ़िगरेशन के पीछे कई निकासी प्रकार प्रदान करता है। बजट बनाते समय स्क्रैपलेस मूल्य निर्धारण और चयनित चैनल की शर्तों पर परामर्श करें; प्रोटोकॉल समर्थन और व्यावसायिक आवंटन को भी अपने खाते के लिए चेक किया जाना चाहिए।

निष्कर्ष

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