टर्मिनलमधील डाउनलोड काम करतात, पण 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 तयार केला ते नोंदवा। टप्पा, होस्ट आणि बाजू नावाची छोटी नोंद कोणीतरी बदललेल्या सेटिंग्जच्या यादीपेक्षा जास्त मोलाची आहे, कारण पुढचा माणूस पुन्हा तयार करू शकतो तीच ती नोंद।