VPN चल रहा है, पर एक ऐप में इंटरनेट नहीं? उसका प्रॉक्सी जाँचें

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

प्रॉक्सी सेटिंग किस परत के पास है

चार जगहें किसी ऐप के अनुरोधों पर अधिकार का दावा कर सकती हैं, और आम तौर पर सबसे सँकरी परत जीतती है। ऑपरेटिंग सिस्टम के पास एक वैश्विक प्रॉक्सी और एक वैकल्पिक स्वचालित कॉन्फ़िगरेशन URL होता है; ब्राउज़र उसका पालन कर सकता है, उसे ओवरराइड कर सकता है या नियंत्रण किसी एक्सटेंशन को सौंप सकता है; कमांड-लाइन टूल अपना एनवायरनमेंट पढ़ता है; और प्रबंधित नीति बदलाव के बाद ऊपर के किसी भी हिस्से को फिर से पिन कर सकती है। कुछ भी संपादित करने से पहले तय करें कि कौन सी परत ज़िम्मेदार है, क्योंकि गलत परत मिटाना एक सफल सुधार जैसा दिखता है जो अगली लॉगिन पर लौट आता है।

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

वह मान पढ़ें जो हर टूल वास्तव में इस्तेमाल करता है

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

env | grep -i -E 'http_proxy|https_proxy|all_proxy|no_proxy'
scutil --proxy
gsettings get org.gnome.system.proxy mode
netsh winhttp show proxy

सिर्फ़ वही पंक्ति चलाएँ जो आपके सामने के प्लेटफ़ॉर्म से मेल खाती है, फिर होस्ट, पोर्ट और क्रेडेंशियल के लिए आउटपुट पढ़ें। ऐसा मान http://proxy.corp.example:8080 का अर्थ है कि टूल हर अनुरोध के लिए उस होस्ट से पूछता है, जबकि खाली परिणाम का अर्थ है कि वह सीधे जाता है और असली गड़बड़ी कहीं और है। टिकट में आउटपुट चिपकाने से पहले उपयोगकर्ता और पासवर्ड वाला हिस्सा छिपाएँ, क्योंकि वे स्ट्रिंग लोगों की अपेक्षा बहुत अधिक बार जीवित क्रेडेंशियल होती हैं।

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

ओवरराइड मिटाएँ और वही अनुरोध फिर से जाँचें

एक परत बदलें, फिर ठीक उसी अनुरोध को दोहराएँ जो विफल हुआ, क्योंकि कोई दूसरा URL कुछ साबित नहीं करता। मौजूदा शेल में पहले एनवायरनमेंट वेरिएबल मिटाएँ, क्योंकि वह संपादन उलटा जा सकता है और टनल को तोड़ नहीं सकता:

unset http_proxy https_proxy all_proxy
curl -v --max-time 10 https://example.com 2>&1 | grep -i -E 'uses proxy|connected to|http/'

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

macOS पर जाँचें कि कोई स्वचालित कॉन्फ़िगरेशन फ़ाइल मान नहीं दे रही है, फिर सेवा प्रॉक्सी बंद करें और बदलाव की पुष्टि करें। Windows पर याद रखें कि WinHTTP सेटिंग और प्रति-उपयोगकर्ता ब्राउज़र सेटिंग अलग ऑब्जेक्ट हैं, इसलिए एक साफ़ कमांड-लाइन टूल ऐसे ब्राउज़र के साथ रह सकता है जो अब भी पुराने सर्वर की ओर इशारा करता है। एक्सटेंशन भी उसी संदेह के योग्य हैं: प्रॉक्सी एक्सटेंशन सिर्फ़ एक प्रोफ़ाइल के लिए अनुरोध फिर से लिख सकता है, और यह ठीक उसी तरह की विफलता है जो एक ब्राउज़र को प्रभावित करती है और कुछ नहीं।

जाँचें कि सुधार रीस्टार्ट के बाद भी टिकता है

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

दो जाँचें असली सुधार को अस्थायी से अलग करती हैं, और दोनों को सीधा कनेक्शन या इच्छित मान बताना चाहिए। साफ़ एनवायरनमेंट में चलाना दिखाता है कि क्या साफ़ की गई प्रक्रिया अब भी सिस्टम सेटिंग उठाती है।

env -i /usr/bin/curl -sS -o /dev/null -w '%{http_code} %{remote_ip}
' https://example.com
networksetup -getwebproxy "Wi-Fi"

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