په ټرمینل کې ډاونلوډونه کار کوي، خو د VPN په واسطه د VS Code غزونې ناکامېږي

هغه ډاونلوډونه چې د کانټینر په ټرمینل کې بریالي کېږي، د هغه ټرمینل چاپېریال په اړه ریښتیني شواهد دي۔ دوی د مدیر بهیر، د غزونې نصب کوونکي یا هغه باینري فایل په اړه هېڅ نه وایي چې غزونه وروسته یې راوړي۔ د پراکسي متغیرونو کاپي کول د دغو درېیو ترمنځ یوه ناکامه غوښتنه په بشپړه ماسپښین کې د بې اړیکې سمونو بدلوي۔

دوه چاپېریالونه معمولاً په یو ځانګړي توپیر کې توپیر لري۔ د هغه توپیر موندل د پراکسي اسنادو دوه ځله لوستلو څخه ګړندي دي۔

کوم بهیر ناکامه غوښتنه وکړه

د یوې نصبونې په جریان کې درې غوښتنې ناکامېدای شي، او هر یو خپل شبکه یی هویت لري۔ مدیر له Marketplace څخه میټاډاټا او د بنډل URL غواړي، بیا بنډل ډاونلوډ کوي۔ یوازې له هغې وروسته د غزونې کوربه هغه کوډ چلوي چې کېدای شي د ژبې سرور یا خپل باینري فایل راوړي۔ کوم پړاو مات شو هغه ټاکي چې کوم بهیر پراکسي ته اړتیا لري، او د تېروتنې سطحه نادراً د هغه پړاو نوم اخلي۔

کاري ټرمینل ثابتوي چې کانټینر انټرنیټ ته رسېدای شي، نه دا چې مدیر رسېدای شي۔ د غزونې لاګ کې وروستی URL ولولئ چې هڅه یې کړې۔ هلته نومول شوی کوربه بهیر او پر هغه پلي کېدونکې تګلاره پیژني۔

ځایي مدیر او لرې کانټینر دوه چاپېریالونه دي

په لرې کاري ځای کې غزونه په هغه اړخ کې چلېږي چې ډول یې اعلانوي۔ د مخ غزونې د ځایي مدیر سره پاتې کېږي، او د کاري ځای غزونې په کانټینر کې چلېږي۔ په یوه کې ټاکل شوی پراکسي بل ته نه ښکاري، او بیا جوړونه د کانټینر چاپېریال د هغه له ترتیبي فایل څخه جوړوي، نه له هغه څخه چې تاسو په شیل کې صادر کړی۔ دا وېش تشریح کوي چې ولې هماغه غزونه په لیپ ټاپ کې نصبېږي او په هماغه پروژه کې د SSH له لارې ناکامېږي۔

له هر څه بدلولو مخکې د نصب ځای ولولئ۔ کله چې لاګ د لرې نصب راپور ورکړي، د کانټینر چاپېریال هغه دی چې اهمیت لري۔

پراکسي هلته کېږدئ چېرې چې غوښتنه پیلېږي

د هغه Dev Container لپاره چې واقعاً HTTP پراکسي ته اړتیا لري، متغیر باید د کانټینر په ترتیب کې وي ترڅو بیا جوړونه یې بیا تولید کړي۔ لاندې ټوټه یې د هغه چاپېریال لپاره ټاکي۔ ځای نیونکی پته ستاسو خپله دروازه استازیتوب کوي، او استثناوې اختیاري ډکول نه دي۔

"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 تولید کړ۔ د پړاو، کوربه او اړخ نومونکې لنډه یادښت له هغې لړلیک څخه چې چا تنظیمات بدل کړي ډېره ارزښتناکه ده، ځکه راتلونکی کس کولای شي هماغه یادښت بیا تولید کړي۔