టెర్మినల్‌లో డౌన్‌లోడ్‌లు పనిచేస్తాయి, కానీ 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ను ఉత్పత్తి చేసిందో గుర్తించండి. దశ, హోస్ట్ మరియు వైపును పేర్కొనే చిన్న గమనిక, ఎవరో మార్చిన సెట్టింగ్‌ల జాబితా కంటే ఎక్కువ విలువైనది, ఎందుకంటే తదుపరి వ్యక్తి పునరుత్పత్తి చేయగలిగేది ఆ గమనికే.