Las descargas en la terminal funcionan, pero las extensiones de VS Code fallan con la VPN

Las descargas que tienen éxito en la terminal del contenedor son una prueba real del entorno de esa terminal. No dicen nada sobre el proceso del editor, el instalador de extensiones ni el binario que una extensión descarga después. Copiar las variables de proxy entre esos tres convierte una solicitud fallida en una tarde entera de cambios no relacionados.

Dos entornos suelen diferenciarse en exactamente un aspecto. Encontrar ese aspecto es más rápido que leer dos veces la documentación del proxy.

Qué proceso hizo la solicitud fallida

Tres solicitudes pueden fallar durante una sola instalación, y cada una tiene su propia identidad de red. El editor pide al Marketplace los metadatos y una URL del paquete, y luego descarga el paquete. Solo después de eso el host de extensiones ejecuta código que puede descargar un servidor de lenguaje o un binario propio. La etapa que se rompió decide qué proceso necesita un proxy, y la superficie de error casi nunca nombra esa etapa.

Una terminal que funciona demuestra que el contenedor puede llegar a internet, no que el editor pueda. Lea el registro de la extensión para ver la última URL que intentó. El host que aparece allí identifica el proceso y la política que se le aplica.

El editor local y el contenedor remoto son dos entornos

En un espacio de trabajo remoto, una extensión se ejecuta en el lado que declara su tipo. Las extensiones de interfaz se quedan con el editor local, y las extensiones de espacio de trabajo se ejecutan en el contenedor. Un proxy configurado en uno es invisible para el otro, y una reconstrucción recrea el entorno del contenedor a partir de su archivo de configuración en lugar de lo que haya exportado en un shell. Esa división explica por qué la misma extensión se instala en un portátil y falla en el mismo proyecto por SSH.

Lea la ubicación de instalación antes de editar cualquier cosa. Cuando el registro informa de una instalación remota, el entorno del contenedor es el que importa.

Ponga el proxy donde empieza la solicitud

Para un Dev Container que realmente necesita un proxy HTTP, la variable pertenece a la configuración del contenedor para que una reconstrucción la reproduzca. El fragmento siguiente la establece para ese entorno. La dirección de marcador de posición sustituye a su propia puerta de enlace, y las exclusiones no son relleno 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 nombre de la variable describe el protocolo de destino, así que un valor HTTPS_PROXY puede empezar legítimamente por http. Aplique el cambio mediante la ruta de reconstrucción admitida y conserve las exclusiones, porque un proxy que intercepta hosts internos rompe servicios que el contenedor necesita.

Separe los fallos de confianza de la accesibilidad

Un proxy que conecta y luego devuelve un error de verificación de certificado ha llegado a una etapa posterior que uno que rechaza la conexión. El primer fallo quiere el material de confianza aprobado por la organización instalado en el entorno que realiza la solicitud. El segundo quiere una dirección y un puerto accesibles. Tratarlos como un solo problema produce una solución que no funciona para ninguno de los dos.

Desactivar la verificación, o ejecutar el editor con derechos elevados, no es una reparación para un proxy ausente o una cadena de confianza ausente. Ambas cambian un error visible por uno silencioso. Vuelva a probar la misma extensión después y anote la siguiente URL que falle.

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

Anote qué lado del espacio de trabajo produjo esa URL. Una nota breve que nombre la etapa, el host y el lado vale más que una lista de ajustes que alguien cambió, porque esa nota es lo que la siguiente persona puede reproducir.