Преузимања у терминалу раде, али VS Code екстензије не успевају преко VPN-а

curl ради у контејнеру, а екстензија се и даље не инсталира. Упоредите локални уређивач и удаљено окружење пре копирања подешавања проксија.

Преузимања која успеју у терминалу контејнера прави су доказ о окружењу тог терминала. Она не говоре ништа о процесу уређивача, инсталатеру екстензија ни о бинарној датотеци коју екстензија касније преузме. Копирање прокси променљивих између тих троје претвара један неуспешан захтев у цело поподне неповезаних измена.

Два окружења се обично разликују тачно у једном аспекту. Пронаћи тај аспект брже је него двапут прочитати документацију о проксију.

Који процес је послао неуспешан захтев

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

Повезани чланци