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"

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