Stahování v terminálu funguje, ale rozšíření VS Code přes VPN selhávají

curl v kontejneru funguje a rozšíření se přesto nenainstaluje. Porovnejte místní editor a vzdálené prostředí, než zkopírujete nastavení proxy.

Stahování, která v terminálu kontejneru uspějí, jsou skutečným důkazem o prostředí tohoto terminálu. Nic neříkají o procesu editoru, instalátoru rozšíření ani o binárce, kterou si rozšíření následně stáhne. Kopírování proxy proměnných mezi těmito třemi promění jeden neúspěšný požadavek v celé odpoledne nesouvisejících úprav.

Dvě prostředí se obvykle liší přesně v jednom ohledu. Najít tento ohled je rychlejší než dvakrát číst dokumentaci k proxy.

Který proces odeslal neúspěšný požadavek

Během jedné instalace mohou selhat tři požadavky a každý má vlastní síťovou identitu. Editor žádá Marketplace o metadata a URL balíčku, poté balíček stáhne. Teprve potom hostitel rozšíření spustí kód, který může stáhnout jazykový server nebo vlastní binárku. Kterákoli fáze se zlomila, určuje, který proces potřebuje proxy, a chybové hlášení fázi málokdy pojmenuje.

Funkční terminál dokazuje, že kontejner dosáhne na internet, ne že na něj dosáhne editor. Přečtěte si protokol rozšíření a najděte poslední URL, kterou se pokusilo použít. Hostitel zde uvedený určuje proces a zásadu, která se na něj vztahuje.

Místní editor a vzdálený kontejner jsou dvě prostředí

Ve vzdáleném pracovním prostoru běží rozšíření na straně, kterou deklaruje jeho typ. Rozšíření rozhraní zůstávají u místního editoru a rozšíření pracovního prostoru běží v kontejneru. Proxy nastavená v jednom je pro druhé neviditelná a přestavba vytvoří prostředí kontejneru z jeho konfiguračního souboru, nikoli z toho, co jste exportovali v shellu. Toto rozdělení vysvětluje, proč se stejné rozšíření nainstaluje na notebooku a selže ve stejném projektu přes SSH.

Přečtěte si umístění instalace, než cokoli upravíte. Když protokol hlásí vzdálenou instalaci, důležité je prostředí kontejneru.

Umístěte proxy tam, kde požadavek začíná

U Dev Containeru, který skutečně potřebuje HTTP proxy, patří proměnná do konfigurace kontejneru, aby ji přestavba reprodukovala. Následující fragment ji pro toto prostředí nastavuje. Zástupná adresa nahrazuje vaši vlastní bránu a vyloučení nejsou volitelná výplň.

"containerEnv": {
  "HTTP_PROXY": "http://proxy.corp.example:8080",
  "HTTPS_PROXY": "http://proxy.corp.example:8080",
  "NO_PROXY": "localhost,127.0.0.1,.internal.example"
}

Název proměnné popisuje cílový protokol, takže hodnota HTTPS_PROXY může legitimně začínat na http. Změnu použijte podporovanou cestou přestavby a vyloučení zachovejte, protože proxy, která zachytává interní hostitele, rozbíjí služby, které kontejner potřebuje.

Oddělte selhání důvěry od dosažitelnosti

Proxy, která se připojí a poté vrátí chybu ověření certifikátu, dosáhla pozdější fáze než ta, která spojení odmítne. První selhání chce organizací schválený materiál důvěry nainstalovaný v prostředí, které požadavek provádí. Druhé chce dosažitelnou adresu a port. Když je bereme jako jeden problém, vznikne oprava, která nefunguje ani pro jedno.

Vypnutí ověřování nebo spuštění editoru se zvýšenými právy není oprava chybějící proxy ani chybějícího řetězce důvěry. Obojí vymění viditelnou chybu za tichou. Poté zkuste stejné rozšíření znovu a poznamenejte si další URL, která selže.

env | grep -iE '^(http|https|no)_proxy='
code --install-extension ms-python.python --force

Poznamenejte si, která strana pracovního prostoru danou URL vytvořila. Krátká poznámka s fází, hostitelem a stranou má větší cenu než seznam nastavení, která někdo změnil, protože právě tuto poznámku dokáže další člověk reprodukovat.

Související články