Les descàrregues al terminal funcionen, però les extensions de VS Code fallen amb la VPN

Les descàrregues que tenen èxit al terminal del contenidor són una prova real sobre l'entorn d'aquell terminal. No diuen res sobre el procés de l'editor, l'instal·lador d'extensions ni el binari que l'extensió baixa després. Copiar les variables de proxy entre aquests tres converteix una sol·licitud fallida en una tarda d'edicions no relacionades.

Dos entorns normalment difereixen exactament en un aspecte. Trobar aquest aspecte és més ràpid que llegir la documentació del proxy dues vegades.

Quin procés va fer la sol·licitud fallida

Tres sol·licituds poden fallar durant una sola instal·lació, i cadascuna té la seva pròpia identitat de xarxa. L'editor demana al Marketplace les metadades i una URL del paquet, i després baixa el paquet. Només després d'això l'amfitrió d'extensions executa codi que pot baixar un servidor d'idioma o un binari propi. L'etapa que s'ha trencat decideix quin procés necessita un proxy, i la superfície d'error poques vegades nomena l'etapa.

Un terminal que funciona demostra que el contenidor pot arribar a internet, no que l'editor hi pugui arribar. Llegiu el registre de l'extensió per trobar l'última URL que ha intentat. L'amfitrió que hi apareix identifica el procés i la política que se li aplica.

L'editor local i el contenidor remot són dos entorns

En un espai de treball remot, una extensió s'executa al costat que declara el seu tipus. Les extensions d'interfície es queden amb l'editor local, i les extensions d'espai de treball s'executen al contenidor. Un proxy definit en un és invisible per a l'altre, i una reconstrucció recrea l'entorn del contenidor a partir del seu fitxer de configuració, no del que hàgiu exportat en un intèrpret d'ordres. Aquesta divisió explica per què la mateixa extensió s'instal·la en un portàtil i falla en el mateix projecte per SSH.

Llegiu la ubicació d'instal·lació abans d'editar res. Quan el registre informi d'una instal·lació remota, l'entorn del contenidor és el que importa.

Poseu el proxy on comença la sol·licitud

Per a un Dev Container que realment necessiti un proxy HTTP, la variable pertany a la configuració del contenidor perquè una reconstrucció la reprodueixi. El fragment següent la defineix per a aquell entorn. L'adreça de marcador de posició substitueix la vostra pròpia passarel·la, i les exclusions no són farciment opcional.

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

El nom de la variable descriu el protocol de destinació, així que un valor HTTPS_PROXY pot començar legítimament amb http. Apliqueu el canvi pel camí de reconstrucció admès i conserveu les exclusions, perquè un proxy que intercepta amfitrions interns trenca serveis que el contenidor necessita.

Separeu les fallades de confiança de l'abastabilitat

Un proxy que es connecta i després retorna un error de verificació de certificat ha arribat a una etapa posterior que un que rebutja la connexió. La primera fallada vol el material de confiança aprovat per l'organització instal·lat a l'entorn que fa la sol·licitud. La segona vol una adreça i un port abastables. Tractar-les com un sol problema produeix una solució que no funciona per a cap de les dues.

Desactivar la verificació, o executar l'editor amb drets elevats, no és una reparació per a un proxy absent o una cadena de confiança absent. Totes dues canvien un error visible per un de silenciós. Torneu a provar la mateixa extensió després i anoteu la propera URL que falli.

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

Anoteu quin costat de l'espai de treball ha produït aquesta URL. Una nota breu que anomeni l'etapa, l'amfitrió i el costat val més que una llista de paràmetres que algú ha canviat, perquè aquesta nota és el que la persona següent pot reproduir.