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"

रीस्टार्टनंतर जुने मूल्य परत आले, तर स्रोत व्यवस्थापित धोरण किंवा प्रोफाइल आहे जे ते पुन्हा लागू करते, आणि त्या धोरणाच्या मालकाने अपवाद काढून टाकला पाहिजे। प्रमाणपत्र पडताळणी सर्व वेळ चालू ठेवा, कारण रहदारी अडवणारा प्रॉक्सी तुम्ही तपासण्या बंद केल्या क्षणी सुटलेला दिसेल। शेवटी काढून टाकलेले मूल्य आणि तारीख तुमच्या नोट्समध्ये लिहा, जेणेकरून पुढच्या व्यक्तीला जाणीवपूर्वक ठेवलेला प्रॉक्सी विसरलेल्या प्रॉक्सीपासून वेगळा ओळखता येईल।