WSL, Docker, Linux y máquinas virtuales… Parece un mundo complejo para quienes trabajan en proyectos de desarrollo en Windows. A muchos devs les pasa que oyen maravillas del Subsistema Windows para Linux, pero cuando se ponen delante del PC no tienen claro qué problema real les va a solucionar, qué riesgos tiene ni cómo dejarlo todo limpio después.
En este artículo vamos a ver con calma qué es WSL, para qué sirve más allá de lo obvio y, sobre todo, cómo usarlo de forma que “ensucie” lo menos posible tu instalación de Windows. También veremos cuándo quizá te interese dar la vuelta a la tortilla y usar Linux como sistema principal, dejando Windows en una máquina virtual.
Qué es exactamente WSL y por qué tanta gente habla de él
WSL son las siglas de Windows Subsystem for Linux, el subsistema de Windows para ejecutar distribuciones Linux de forma integrada dentro de Windows 10 y 11. La idea de Microsoft es sencilla: darte un entorno Linux “de verdad” sin obligarte a usar arranque dual ni a montar una máquina virtual clásica con VirtualBox o VMware.
En la práctica, con WSL puedes tener una distro como Ubuntu, Debian o Kali ejecutándose en paralelo a Windows, compartir archivos entre ambos mundos y lanzar herramientas típicas de Linux (bash, ssh, apt, Python, Node, Docker…) sin salir de tu escritorio habitual. Todo con un grado de integración bastante alto con el sistema anfitrión.
Desde su lanzamiento, WSL ha generado opiniones muy polarizadas. Hay desarrolladores que lo consideran un éxito absoluto y una razón de peso para seguir en Windows. Otros, sobre todo del entorno más purista de Linux, lo ven como una maniobra de “adoptar‑extender‑extinguir” para mantener la hegemonía del escritorio de Microsoft. Más allá de la polémica, la realidad es que WSL ha cambiado la forma de trabajar de muchos devs.
La versión actual recomendada es WSL 2, que ya no es solo una capa de compatibilidad sino que usa una máquina virtual ligera con un kernel Linux real. Microsoft insiste en que “no es una VM tradicional”, porque la crea, configura y optimiza por ti, pero por debajo hay virtualización con tecnologías como Hyper‑V.
WSL 1 vs WSL 2 y requisitos que debes tener en cuenta
Hoy en día conviene entender la diferencia entre WSL 1 y WSL 2. Sobre todo por temas de rendimiento, compatibilidad y requisitos de hardware. WSL 1 hacía una traducción de llamadas de sistema Linux a Windows; funcionaba bien para muchas cosas, pero fallaba en compatibilidad con herramientas más avanzadas.
Con WSL 2, Microsoft cambia el enfoque: ejecuta un kernel Linux completo dentro de una máquina virtual muy optimizada. Esto mejora muchísimo la compatibilidad (Docker, sistemas de archivos típicos de Linux, etc.) y la mayoría del software que funciona en un Linux “real” también lo hace dentro de WSL 2.
La contrapartida es que WSL 2 tiene más dependencias. Requiere soporte de virtualización en la CPU y SLAT (Second Level Address Translation), presente en procesadores relativamente modernos (Intel Nehalem en adelante, AMD Opteron y sucesores). CPUs más antiguas, como algunos Core 2 Duo, simplemente no podrán usar WSL 2 aunque actives todas las características.
Además, para usar WSL 2 necesitas una versión de Windows suficientemente reciente: Windows 10 1903 (build 18362) o superior, o Windows 11. En sistemas previos hay que quedarse en WSL 1, con sus limitaciones. Esto significa que, en cierto modo, sigues arrastrando los requisitos y ciclos de vida de Windows: si tu máquina se queda fuera de soporte, WSL también.
Instalación rápida de WSL y primeras decisiones
En versiones actuales de Windows, Microsoft ha simplificado muchísimo el proceso. Desde una consola de PowerShell con privilegios de administrador basta con ejecutar el comando wsl –install para que se instale WSL y una Ubuntu por defecto. El propio sistema descarga los componentes necesarios y la distro desde la Microsoft Store.
Durante el primer arranque de la distro se te pedirá que crees un usuario y contraseña para el sistema Linux. Ese usuario es tu cuenta principal dentro de la distro, totalmente independiente de la de Windows, lo que ayuda a mantener cierto aislamiento.
Si quieres ir un poco más allá, puedes listar todas las distribuciones disponibles con wsl –list –online y escoger, por ejemplo, Debian, Kali, openSUSE u otras variantes de Ubuntu. La instalación se hace con wsl –install -d NOMBRE_DISTRIBUCION y cada distro vive en su propia “caja” aislada.
Por defecto, en sistemas nuevos el propio comando wsl –install configura WSL 2 como versión de base, pero puedes asegurarlo con wsl –set-default-version 2. Si ya tienes distros creadas con WSL 1, las puedes migrar de forma individual con wsl –set-version NOMBRE_DISTRIBUCION 2, a costa de un pequeño tiempo de conversión.
Cómo afecta WSL a tu sistema Windows y dónde guarda las cosas
Una de tus dudas principales seguramente sea cuánto “ensucia” WSL tu Windows y dónde termina todo lo que instales en Linux. Lo esencial es que cada distribución WSL se almacena en una carpeta de datos de usuario dentro de %LocalAppData%\Packages, y, si prefieres gestionar ficheros fuera del Explorador clásico, puedes usar gestores de archivos alternativos, no suelta archivos por todo el disco como haría una instalación clásica de Linux.
Dentro de esa carpeta hay un directorio LocalState con un disco virtual (VHDX) que contiene todo el sistema de archivos Linux: /, /home, /var, etc.. Es decir, el servidor web, Docker, las bases de datos, el código del proyecto… Todo vive dentro de ese contenedor. Mientras no toques nada fuera de ahí, el impacto en las rutas típicas de Windows es mínimo.
Ahora bien, WSL requiere activar ciertas características del sistema: “Subsistema de Windows para Linux” y, para WSL 2, “Plataforma de máquina virtual”. Esto se puede hacer vía PowerShell (Enable-WindowsOptionalFeature) o desde la GUI de “Activar o desactivar las características de Windows”. También se instala el kernel de Linux para WSL en %SystemRoot%\System32\lxss\tools.
Estos componentes forman parte de Windows una vez activos, de modo que, si en algún momento quieres dejar el sistema como si nunca hubieras tocado WSL, tendrás que desinstalar las distribuciones, desactivar las características opcionales y, si hace falta, quitar el paquete del kernel. No es un “solo borro una carpeta y ya”, pero tampoco es especialmente complicado.
Ten en cuenta además que WSL crea una interfaz de red virtual, ajusta reglas de firewall y, en el caso de WSL 2, depende de servicios como ICS (Internet Connection Sharing) y HNS para gestionar NAT, DNS y DHCP internos. Todo esto es transparente en el día a día, pero explica por qué a veces ciertas VPNs o firewalls corporativos chocan con WSL.
Uso de WSL para desarrollo web y tareas no tan evidentes
Más allá del típico “quiero tener bash en Windows”, WSL brilla cuando necesitas reproducir entornos Linux de producción sin abandonar tu escritorio Windows. Por ejemplo, el caso que comentabas: un proyecto FOSS que usa Docker, Flask, ArangoDB y otros servicios de backend.
En lugar de pelearte con versiones raras para Windows o con Docker Desktop sobre Windows nativo (que históricamente ha sido bastante doloroso), puedes instalar todo el stack directamente dentro de tu distro WSL. Docker corre de forma natural sobre el kernel de WSL 2, los servicios Linux funcionan como en un servidor real y tú sigues usando VS Code u otras herramientas gráficas desde Windows.
También hay ventajas menos obvias. Puedes ejecutar scripts de administración, herramientas de línea de comandos exclusivas de Linux, buenas versiones de Node y NVM, gestores de paquetes como apt, y en general todo el ecosistema de utilidades al que están acostumbrados los devs de servidores.
Gracias a la integración de sistemas de archivos, WSL monta tus discos de Windows bajo /mnt (por ejemplo, /mnt/c para la unidad C:). Esto te permite editar el código con tu editor de Windows y ejecutarlo dentro de Linux sin duplicar proyectos.
Otra cosa interesante es la interoperabilidad hacia el otro lado: desde la shell de Linux puedes llamar ejecutables de Windows como notepad.exe, powershell.exe o cualquier .exe del sistema. Si tu variable PATH incluye rutas Win32 como /mnt/c/Windows/System32, basta con escribir el nombre del ejecutable para lanzarlo, salvo que tu shell haya machacado el PATH por error.
Windows Terminal: la pareja ideal de WSL
Para que la experiencia con WSL sea más cómoda, Microsoft recomienda usar Windows Terminal (Terminal Windows en castellano). Es una aplicación moderna que permite abrir pestañas de diferentes shells: PowerShell, CMD, y, muy importante, cada una de tus distribuciones WSL.
Con Windows Terminal puedes crear sesiones de Ubuntu, Debian o Kali desde un mismo programa, con pestañas y paneles, configurar atajos de teclado y personalizar fuentes, colores y perfiles sin tener que mantener mil ventanas sueltas de cmd.exe. Además, te evita depender de herramientas antiguas como PuTTY para conexiones SSH, ya que puedes conectar a servidores remotos directamente desde una distro WSL.
El flujo habitual para muchísimos desarrolladores en Windows hoy en día es: código en VS Code, terminal principal en Windows Terminal y backend y herramientas dentro de WSL. Esta combinación ofrece una experiencia muy cercana a trabajar en macOS o directamente en una distro Linux de escritorio.
Red, DNS, VPN y otros quebraderos de cabeza en WSL
Donde más guerra suele dar WSL 2 es en la red: al usar una VM ligera, depende de un adaptador virtual, reglas de firewall y un pequeño NAT interno que a veces chocan con configuraciones corporativas, VPN, antivirus con cortafuegos o políticas de seguridad estrictas.
Un problema frecuente es que WSL no tenga salida a Internet en equipos de empresa. En muchos dominios de Active Directory, las reglas de firewall definidas por la organización bloquean reglas locales. Como la excepción que crea HNS para permitir tráfico DNS desde la vNIC de WSL es local, queda anulada. Si AllowLocalFirewallRules o AllowInboundRules están en False en el perfil correspondiente (con Get-NetFirewallProfile), WSL se queda sin resolver nombres.
La solución pasa porque el administrador defina una regla corporativa adecuada. O, alternativamente, habilitar la tunelización DNS de WSL mediante la opción experimental dnsTunneling en el archivo .wslconfig. Esta característica hace que las consultas DNS del Linux interno vayan directamente al resolver de Windows a través de la capa de virtualización, sin necesidad de paquetes de red clásicos que choque con el firewall.
También dan guerra algunas VPN. Hay casos conocidos con Cisco AnyConnect, clientes de OpenVPN, soluciones como ZScaler, McAfee Safe Connect o Bitdefender que manipulan rutas, NRPT o proxies de un modo que rompe el NAT o interfiere con el tráfico de WSL. A veces la solución es activar el networkingMode=mirrored (modo reflejado), otras deshabilitar dnsTunneling, o incluso tocar la configuración de autoProxy para que el reflejo de HTTP_PROXY/HTTPS_PROXY dentro de Linux se ajuste a tu escenario.
En modo NAT clásico hay limitaciones como solo poder definir tres DNS en /etc/resolv.conf, cosa que dnsTunneling también ayuda a resolver: Linux pasa a usar todos los DNS que tenga configurados Windows. Además, los sufijos DNS se gestionan de forma distinta según si estás en NAT puro, NAT con tunelización DNS o modo reflejado. En el último, se reflejan todos los sufijos DNS de Windows en el search de resolv.conf y se actualizan automáticamente cuando cambian en el host.
Compatibilidad con Docker y contenedores dentro de WSL
Uno de los grandes motivos de adopción de WSL 2 ha sido mejorar drásticamente la experiencia con Docker. La idea oficial de Microsoft y Docker es que Docker Desktop use WSL 2 como backend, en lugar de Hyper‑V directo o su motor antiguo.
Aun así, no todo es perfecto. Se han detectado problemas, por ejemplo, cuando usas el modo de red reflejado (networkingMode=mirrored) y ejecutas contenedores con puertos publicados. En esos casos, Docker Desktop puede fallar al crear esos contenedores si usas el espacio de nombres de red por defecto. La solución temporal es lanzar los contenedores con –network host o añadir los puertos problemáticos a ignoredPorts en .wslconfig.
También hay incidencias con contenedores que llevan Network Manager u otros servicios de red complejos activos dentro. Pueden impedir que la configuración de red de WSL funcione correctamente, sobre todo para conexiones de retorno al host. Microsoft recomienda desactivar ese tipo de demonios cuando no son estrictamente necesarios.
Si, además, tu entorno corporativo añade proxy HTTP/S y tú habilitas autoProxy en WSL, se rellenarán variables como HTTP_PROXY, HTTPS_PROXY, NO_PROXY y WSL_PAC_URL. Ojo porque las variables definidas por el usuario tienen prioridad sobre las generadas automáticamente. Linux no soporta nativamente PAC, así que puede que tengas que adaptar scripts o desactivar la característica.
Errores habituales dentro de la distro Linux y cómo resolverlos
Una vez dentro de la distro, también pueden aparecer problemas típicos de Linux, algunos agravados por las peculiaridades de WSL. Un clásico es que comandos de Windows como powershell.exe o notepad.exe no se encuentren al invocarlos desde bash con un mensaje “command not found”.
En la mayoría de casos se debe a que algún script de inicio (como /etc/profile en Debian) redefine PATH sin tener en cuenta el valor que le pasa WSL, perdiendo las rutas de /mnt/c/Windows y similares. La forma correcta es no machacar PATH, sino ampliarlo, o directamente eliminar esas líneas problemáticas. Conviene también revisar que en /etc/wsl.conf no tengas appendWindowsPath=false.
Otro problema recurrente son errores de apt-get upgrade relacionados con udev y servicios del sistema que no están soportados dentro de WSL, al no ser un sistema completo con init tradicional. La solución habitual es instalar un script policy-rc.d en /usr/sbin que devuelva exit 101 para evitar que se intenten arrancar servicios, añadir permisos de ejecución y usar dpkg-divert para redirigir /sbin/initctl a /bin/true.
Con SSH también hay particularidade. Si al intentar conectarte a un servidor remoto te encuentras con advertencias tipo “UNPROTECTED PRIVATE KEY FILE!” y permisos 0777, lo más probable es que estés guardando claves en un directorio montado desde Windows con permisos demasiado laxos. Para que WSL gestione bien permisos POSIX sobre archivos de Windows, es recomendable añadir en /etc/wsl.conf una sección con opciones como metadata,uid=1000,gid=1000,umask=0022.
En sentido inverso, si montas un servidor OpenSSH dentro de tu distro WSL y al conectarte desde Windows ves “Connection closed by 127.0.0.1 port 22”, revisa los logs arrancando sshd en modo debug y comprueba que hay claves de host en /etc/ssh y que no han sido eliminadas. Si faltan, se pueden regenerar o, más sencillo, purgar e instalar de nuevo el paquete openssh-server.
Uso de WSL en versiones antiguas de Windows y la variante heredada
En equipos con Windows 10 muy antiguos (Creators Update, Anniversary Update) el soporte de WSL es bastante más limitado. Allí se usaba bash.exe, lxrun y una implementación menos madura. Los comandos y rutas cambian. Se pasaban órdenes de Linux con bash -c, las distros se guardaban en %LocalAppData%\lxss y la interoperabilidad con Windows era más tosca.
Si vienes de esa etapa y todavía tienes la “versión heredada” de WSL, Microsoft recomienda migrar tus datos a una distro moderna desde la Store y desinstalar la antigua. Puedes hacerlo con wsl –unregister Legacy o borrando manualmente la carpeta %LocalAppData%\lxss (cuidado, elimina todo el contenido Linux viejo).
En esos sistemas, características como WSL 2, soporte oficial para apps gráficas de Linux, integración con Docker Desktop o la propia simplificación de wsl –install no están disponibles. Si tu hardware lo permite, lo mejor es actualizar a una build reciente. O directamente a Windows 11 para aprovechar la versión actual del subsistema.
En cualquier caso, si por encima de todo quieres minimizar el impacto en Windows o tu equipo se está quedando atrás en requisitos, hay una alternativa cada vez más sólida: usar Linux como sistema principal y relegar Windows a una máquina virtual (por ejemplo con VirtualBox, VMware o GNOME Boxes). Así evitas depender de los requisitos crecientes de Windows 11. Y mantienes tu hardware vivo más tiempo.
