Преземањата што успеваат во терминалот на контејнерот се вистински доказ за околината на тој терминал. Тие не кажуваат ништо за процесот на уредувачот, инсталаторот на наставки или бинарната датотека што наставката ја презема потоа. Копирањето прокси променливи меѓу тие три претвора едно неуспешно барање во цело попладне несврзани измени.

Две околини обично се разликуваат точно во еден аспект. Наоѓањето на тој аспект е побрзо од две читања на документацијата за прокси.

Кој процес го упати неуспешното барање

За време на една инсталација може да не успеат три барања, и секое има свој мрежен идентитет. Уредувачот бара од 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. Кратка белешка со степенот, домаќинот и страната вреди повеќе од список поставки што некој ги сменил, бидејќи токму таа белешка следниот човек може да ја репродуцира.

Поврзани статии