प्रॉक्सी कनेक्शन विफल: प्रॉक्सी से लेकर लक्ष्य साइट तक जाँच करें

प्रॉक्सी भरने के बाद टेस्ट बटन विफलता दिखाता है। इस स्थिति में सबसे खराब तरीका है कॉन्फ़िगरेशन को बिना क्रम के बदलते रहना—पोर्ट, प्रोटोकॉल या नोड बदलना—और अंत में यह न जानना कि किस बदलाव से फर्क पड़ा।

कारण आम तौर पर चार परतों में होते हैं: प्रॉक्सी सेवा स्वयं, प्रमाणीकरण और प्रोटोकॉल, क्लाइंट कॉन्फ़िगरेशन, और लक्ष्य साइट। इसी क्रम में प्रॉक्सी से बाहर की ओर जाँच करें।

पहले प्रॉक्सी को अलग करके जाँचें

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

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

अगर वहाँ कनेक्शन बन जाता है, तो प्रॉक्सी सक्रिय है। समस्या कॉन्फ़िगरेशन या कनेक्शन पथ में है, इसलिए आगे बढ़ें।

सरल नियम यह है: वही क्रेडेंशियल किसी दूसरी जगह काम करते हैं, तो क्रेडेंशियल स्वयं शायद सही हैं।

प्रमाणीकरण और प्रोटोकॉल को मिलाएँ

क्रेडेंशियल सही होने के बावजूद कनेक्शन न बने, तो अगला संदेह प्रोटोकॉल पर होना चाहिए। तीन सामान्य असंगतियाँ हैं: प्रदाता ने SOCKS5 दिया है लेकिन वातावरण में HTTP चुना गया है; स्वयं बनाया SSH टनल है लेकिन उसे SOCKS5 की तरह सेट किया गया है; या एक प्रॉक्सी कई प्रोटोकॉल देता है पर हर प्रोटोकॉल का पोर्ट अलग है और किसी दूसरे प्रोटोकॉल का पोर्ट भर दिया गया है।

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

उपयोगकर्ता नाम और पासवर्ड जैसे फ़ील्ड एक बार हाथ से टाइप करके तुलना करें। अदृश्य अक्षर ऐसी विफलता पैदा कर सकते हैं जो देखने से पकड़ में नहीं आती।

जाँचें कि क्लाइंट कॉन्फ़िगरेशन वास्तव में लागू हुआ है

यह चरण एक कम दिखाई देने वाला सवाल पूछता है: सेटिंग सही हैं, लेकिन क्या वे सचमुच सक्रिय हैं?

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

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

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

लक्ष्य साइट की अस्वीकृति पहचानें

यदि सभी परतें काम कर रही हैं और प्रॉक्सी भी वास्तव में सक्रिय है, फिर भी बिज़नेस पेज नहीं खुलता, तो प्रॉक्सी को बार-बार बदलने के बजाय लक्ष्य साइट की प्रतिक्रिया देखें।

ऐसी स्थितियों के संकेत अक्सर स्पष्ट होते हैं: कनेक्शन और हैंडशेक हो जाता है, लेकिन अनुरोध 403 लौटाता है या रीसेट हो जाता है; पेज खुलता है, लेकिन लॉगिन या प्रकाशन जैसी क्रियाएँ अस्वीकार होती हैं; वही एग्ज़िट दूसरे साइटों पर काम करता है और केवल एक साइट पर विफल होता है; या विफलता कभी-कभी होती है, जो एग्ज़िट या कनेक्शन पथ पर रेट लिमिट या समवर्ती कनेक्शनों की सीमा का संकेत हो सकती है।

मुख्य बात है कनेक्शन परत और बिज़नेस परत को अलग रखना। बिल्कुल कनेक्ट न हो पाना प्रॉक्सी की समस्या हो सकती है। कनेक्शन बनने के बाद अस्वीकृति मिले, तो अक्सर एग्ज़िट गुणवत्ता या अनुरोध की आवृत्ति कारण होती है। डेटा-सेंटर IP और बहुत अधिक उपयोग किए गए साझा IP बिज़नेस परत पर अधिक आसानी से ब्लॉक हो सकते हैं। रेज़िडेंशियल IP बेहतर हो सकते हैं, लेकिन वे गारंटी नहीं हैं; अनुरोध दर, समवर्ती अनुरोध और पहुँच का समय भी परिणाम को प्रभावित करते हैं।

समस्या जाँचते समय तीन आदतें रखें

एक बार में केवल एक चीज बदलें। यदि प्रोटोकॉल और नोड दोनों एक साथ बदलते हैं, तो सफल होने पर भी पता नहीं चलेगा कि समस्या किस बदलाव से हल हुई, और वही गलती फिर हो सकती है।

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

बार-बार रीट्राई करने से बेहतर तुलना परीक्षण है। यदि कॉन्फ़िगरेशन सही दिखता है लेकिन कनेक्शन फिर भी नहीं बनता, तो टेस्ट बटन को बार-बार दबाने से नई जानकारी नहीं मिलेगी। इसके बजाय किसी दूसरे नेटवर्क वातावरण या दूसरी प्रॉक्सी के साथ नियंत्रित तुलना करें।