टर्मिनलमा डाउनलोड काम गर्छ, तर VPN मा VS Code एक्स्टेन्सन असफल हुन्छन्

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

दुई वातावरण सामान्यतया ठ्याक्कै एउटै कुरामा भिन्न हुन्छन्। त्यो कुरा पत्ता लगाउनु प्रोक्सी कागजात दुई पटक पढ्नुभन्दा छिटो हुन्छ।

कुन प्रक्रियाले असफल अनुरोध गर्‍यो

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

काम गर्ने टर्मिनलले कन्टेनर इन्टरनेटमा पुग्न सक्छ भनी प्रमाणित गर्छ, एडिटर पुग्न सक्छ भनेर होइन। एक्स्टेन्सन लगमा यसले अन्तिम पटक प्रयास गरेको URL पढ्नुहोस्। त्यहाँ नाम दिइएको होस्टले प्रक्रिया र त्यसमा लागू हुने नीति पहिचान गर्छ।

स्थानीय एडिटर र टाढाको कन्टेनर दुई वातावरण हुन्

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

केही सम्पादन गर्नु अघि स्थापना स्थान पढ्नुहोस्। लगले टाढाको स्थापनाको रिपोर्ट गर्दा कन्टेनरको वातावरण नै महत्त्वपूर्ण हुन्छ।

प्रोक्सी अनुरोध सुरु हुने ठाउँमा राख्नुहोस्

साँच्चै HTTP प्रोक्सी चाहिने Dev Container का लागि, चर कन्टेनर कन्फिगरेसनमा हुनुपर्छ ताकि पुनर्निर्माणले त्यसलाई पुन: उत्पादन गरोस्। तलको खण्डले त्यसलाई त्यो वातावरणका लागि सेट गर्छ। प्लेसहोल्डर ठेगानाले तपाईंको आफ्नै गेटवेलाई प्रतिनिधित्व गर्छ, र अपवादहरू वैकल्पिक भरण होइनन्।

"containerEnv": {
  "HTTP_PROXY": "http://proxy.corp.example:8080",
  "HTTPS_PROXY": "http://proxy.corp.example:8080",
  "NO_PROXY": "localhost,127.0.0.1,.internal.example"
}

चरको नामले गन्तव्य प्रोटोकल वर्णन गर्छ, त्यसैले HTTPS_PROXY मान कानुनी रूपमा http बाट सुरु हुन सक्छ। समर्थित पुनर्निर्माण मार्गबाट परिवर्तन लागू गर्नुहोस् र अपवाद राख्नुहोस्, किनकि आन्तरिक होस्ट रोक्ने प्रोक्सीले कन्टेनरलाई चाहिने सेवाहरू तोड्छ।

विश्वासका असफलतालाई पहुँचबाट अलग गर्नुहोस्

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

प्रमाणीकरण बन्द गर्नु, वा एडिटर उच्च अधिकारसहित चलाउनु, हराएको प्रोक्सी वा हराएको विश्वास-शृंखलाको मर्मत होइन। दुवैले देखिने त्रुटिलाई शान्त त्रुटिसँग साट्छन्। त्यसपछि त्यही एक्स्टेन्सन फेरि प्रयास गर्नुहोस् र असफल हुने अर्को URL नोट गर्नुहोस्।

env | grep -iE '^(http|https|no)_proxy='
code --install-extension ms-python.python --force

कार्यक्षेत्रको कुन पक्षले त्यो URL उत्पादन गर्‍यो नोट गर्नुहोस्। चरण, होस्ट र पक्षको नाम दिने छोटो नोट कसैले बदलेका सेटिङको सूचीभन्दा बढी मूल्यवान् हुन्छ, किनकि अर्को व्यक्तिले पुन: उत्पादन गर्न सक्ने कुरा त्यही नोट हो।