Загрузки в терминале работают, но расширения 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. Короткая заметка с этапом, хостом и стороной ценнее списка изменённых кем-то настроек, потому что именно эту заметку сможет воспроизвести следующий человек.

Похожие статьи