VPN बनाम प्रॉक्सी: कौन क्या कवर करता है और क्या नहीं
VPN रूट किए गए ऐप ट्रैफ़िक को कवर करता है; प्रॉक्सी केवल उस ऐप को कवर करता है जिसे आप कॉन्फ़िगर करते हैं। चुनने से पहले कवरेज, एन्क्रिप्शन, DNS और विफलता-व्यवहार जाँचें।
VPN और फ़ॉरवर्ड प्रॉक्सी दोनों वह पता बदलते हैं जो कोई वेबसाइट देखती है, और अधिकांश तुलनाएँ यहीं रुक जाती हैं। आपका सेटअप तय करने वाला अंतर कवरेज है: फ़ॉरवर्ड प्रॉक्सी एक बिचौलिया है जिसे आपका ऐप स्वयं चुनता है, वेबसाइट के सामने बैठे रिवर्स प्रॉक्सी के विपरीत, जबकि VPN वह सब कुछ ले जाता है जिसे ऑपरेटिंग सिस्टम किसी टनल में रूट करता है। एन्क्रिप्शन, DNS का रखरखाव और विफलता-व्यवहार—सब इसी विभाजन से निकलते हैं। ये पाँच जाँचें क्रम से करें, और पहली जो विफल हो वही बताएगी कि आपको वास्तव में कौन-सा उपकरण चाहिए।
बिचौलिया किन ऐप्स को कवर करता है?
ब्राउज़र में प्रॉक्सी एक्सटेंशन केवल उसी ब्राउज़र प्रोफ़ाइल पर लागू होता है। मेल क्लाइंट, पैकेज मैनेजर और दूसरा ब्राउज़र अपनी-अपनी सेटिंग्स ही इस्तेमाल करते रहते हैं, और कुछ ऐप्स सिस्टम प्रॉक्सी वेरिएबल को पूरी तरह अनदेखा कर देते हैं। VPN वह कवर करता है जो रूटिंग टेबल टनल में भेजती है, और यह रूट तथा क्लाइंट नीति के अनुसार सभी ऐप्स या स्प्लिट टनल का कोई उपसमूह हो सकता है।
एक पेज लोड से अनुमान लगाने के बजाय उन ऐप्स को जाँचें जो मायने रखते हैं। curl https://ifconfig.me एनवायरनमेंट प्रॉक्सी वेरिएबल का पालन करता है; डेस्कटॉप ऐप शायद न करे। Windows पर netsh winhttp show proxy वह WinHTTP प्रॉक्सी छापता है जिसे सेवाएँ इस्तेमाल करती हैं, और यह ब्राउज़र की सेटिंग से अलग सेटिंग है।
क्या हॉप एन्क्रिप्टेड है, और TLS कहाँ समाप्त होता है?
प्रॉक्सी प्रोटोकॉल एक मिलन-स्थल है, गारंटी नहीं। SOCKS5 TCP को बिना एन्क्रिप्ट किए आगे भेजता है, और सादा HTTP प्रॉक्सी अनुरोध पंक्ति तथा हेडर स्पष्ट टेक्स्ट में ले जाता है। प्रॉक्सी के ज़रिए HTTPS CONNECT का उपयोग करता है, इसलिए आपका TLS सत्र अब भी गंतव्य पर ही समाप्त होता है, प्रॉक्सी पर नहीं। प्रॉक्सी सर्वर और टनलिंग पर MDN की मार्गदर्शिका प्रोटोकॉल की ओर से यही अंतर समझाती है।
VPN आपके डिवाइस और उसके एंडपॉइंट के बीच के हिस्से को एन्क्रिप्ट करता है। एंडपॉइंट के आगे किसी भी अन्य नेटवर्क जैसे ही नियम लागू होते हैं, इसीलिए अकेली टनल उस ऐप की रक्षा नहीं करती जो सादे HTTP पर क्रेडेंशियल भेजता है। दोनों में से कोई डिज़ाइन लॉग-इन खाता, कुकी या ब्राउज़र फ़िंगरप्रिंट नहीं छिपाता।
curl -v -x http://127.0.0.1:3128 https://example.com/ -o /dev/null
curl -v -x socks5h://127.0.0.1:1080 https://example.com/ -o /dev/nullविस्तृत आउटपुट दिखाता है कि curl ने पोर्ट 443 पर CONNECT भेजा या पूरे URL के साथ सादा GET। socks5h:// के साथ होस्टनाम SOCKS5 अनुरोध के भीतर प्रॉक्सी को दिया जाता है और फिर वह ऐसा TLS आगे भेजता है जिसे वह पढ़ नहीं सकता, इसलिए वह नाम और बाइट-गणना देखता है। http:// प्रॉक्सी के ज़रिए https:// URL एक CONNECT है, इसलिए वह प्रॉक्सी भी गंतव्य का नाम और आयतन देखता है, अनुरोध या प्रतिक्रिया का मुख्य भाग नहीं।
कौन-सा रिज़ॉल्वर नाम देखता है?
नाम-विश्लेषण अनुरोध निकलने से पहले स्थानीय रूप से हो सकता है, या प्रॉक्सी पर दूर से। curl के साथ socks5h:// होस्टनाम प्रॉक्सी को भेजता है जबकि socks5:// पहले उसे स्थानीय रूप से हल करता है। ब्राउज़र प्रॉक्सी सेटिंग्स तुलनीय DNS विकल्प देती हैं, और PAC फ़ाइलें अलग-अलग होस्ट को अलग-अलग तरह से रूट कर सकती हैं।
दो प्रोटोकॉल बिना किसी गलत कॉन्फ़िगरेशन के प्रॉक्सी को दरकिनार कर सकते हैं। WebRTC STUN के ज़रिए उम्मीदवार जुटाता है, और QUIC UDP पर HTTP/3 चलाता है, जिसे TCP प्रॉक्सी ले नहीं सकता। UDP 443 अवरुद्ध होने पर ब्राउज़र TCP पर लौट आएगा, इसलिए होस्ट फ़ायरवॉल पर (या पूरे नेटवर्क के लिए राउटर पर) UDP 443 अवरुद्ध करना, ब्राउज़र फ़्लैग नहीं, HTTP/3 को प्रॉक्सी पथ के भीतर रखने का भरोसेमंद तरीका है।
रिज़ॉल्वर को अपने लैपटॉप की दृष्टि से नहीं, गंतव्य की दृष्टि से जाँचें। जो अनुरोध प्रॉक्सी के निकास पते के साथ पर स्थानीय रूप से हल किए गए नाम के साथ आता है, वह स्थानीय रिज़ॉल्वर को फिर भी बताता है कि आप कौन-सी साइटें देखते हैं।
बिचौलिया विफल होने पर क्या होता है?
स्पष्ट प्रॉक्सी बंद रूप में विफल होता है: प्रॉक्सी प्रक्रिया रोकें और ब्राउज़र या ऐप सीधे जाने के बजाय कनेक्शन त्रुटि लौटाता है। PAC और WPAD सेटअप वही हैं जो खुले रूप में विफल होते हैं - अगर स्क्रिप्ट नहीं मिल पाए, तो क्लाइंट DIRECT पर लौट जाता है और साइट फिर आपका असली पता देखती है। VPN क्लाइंट और इस बात पर निर्भर करते हुए खुला या बंद रूप में विफल हो सकता है कि किल स्विच या फ़ायरवॉल नियम सक्रिय है या नहीं।
विफलता की स्थिति जानबूझकर जाँचें: प्रॉक्सी सेवा रोककर फिर लोड करें; सीधे लोड के बजाय त्रुटि पेज मिले तो PAC URL को अप्राप्य होस्ट पर इंगित करें ताकि फ़ॉलबैक दिखे। अगर पेज अब भी आपके सामान्य मार्ग से लोड होता है, तो प्रॉक्सी अपनी ही गड़बड़ी के विरुद्ध कोई सुरक्षा नहीं देता, और यह ऐसा गुण है जिसे उस पर भरोसा करने से पहले जानना चाहिए।
क्रम तय करता है कि साइट क्या देखती है। जिस प्रॉक्सी का बहिर्गामी ट्रैफ़िक VPN से जाता है, साइट को VPN एंडपॉइंट का पता दिखता है; प्रॉक्सी को टनल के बाहर रखें (दूरस्थ होस्ट पर प्रॉक्सी तक VPN) और साइट उसके बजाय उस प्रॉक्सी का निकास पता देखती है। दोनों ही स्थितियों में दो हॉप अलग-अलग चीज़ें लॉग कर सकते हैं।
पाँच जाँचें, क्रम से
नीचे दी गई चेकलिस्ट पूरा निर्णय एक ही जगह है। कवरेज पहले आता है क्योंकि यह अधिकांश बेमेल हटा देता है: अगर जिस ऐप को कवर करना है वह सेटिंग का सम्मान नहीं करता, तो सूची में आगे कुछ भी उसे नहीं बचाता।
| Check | Forward proxy | VPN |
|---|---|---|
| What is covered | The app or browser you configure | Traffic the OS routes into the tunnel, all or split |
| Encryption scope | Protocol-dependent; SOCKS5 alone encrypts nothing | Device to VPN endpoint |
| DNS path | Local or remote, depending on the setting | Normally inside the tunnel |
| Failure mode | Explicit config: connection error; PAC/WPAD: DIRECT fallback | Client policy: fail-open or kill switch |
| What the site sees | The proxy's exit address | The VPN endpoint's exit address |
फिर परिणाम की पुष्टि उसी ऐप से करें जिसने बदलाव करवाया। कॉन्फ़िगर किए गए ब्राउज़र में पेज लोड करें, वही पेज curl से लाएँ, और दोनों के बताए पते की तुलना करें। अगर वे अलग हैं, तो कोई एक्सटेंशन, PAC नियम या ऐप-स्तरीय ओवरराइड अब भी काम कर रहा है, और टनल की कोई भी ट्यूनिंग उसे ठीक नहीं करेगी।
जो आपने कॉन्फ़िगर किया उसे लिख लें: कौन-से ऐप्स प्रॉक्सी इस्तेमाल करते हैं, DNS स्थानीय है या दूरस्थ, UDP अवरुद्ध है या नहीं, और विफलता-व्यवहार क्या है। यही छोटी सूची अगली तुलना संभव बनाती है, क्योंकि “IP बदल गया” ने कभी नहीं बताया कि इन पाँच जाँचों में से कौन-सी पास हुई।