Usar WSL para tareas no evidentes: guía completa para desarrolladores en Windows

Si trabajas en desarrollo sobre Windows y cada dos por tres te topas con documentación pensada para Linux, probablemente hayas oído hablar de WSL pero aún no tengas claro para qué te sirve en el día a día más allá de “tener bash”. Encima entran en juego Docker, máquinas virtuales, VPN corporativas, firewalls, Node, NVM… y es normal que todo parezca un pequeño caos difícil de domar.

El objetivo de este artículo es que termines con una idea cristalina de qué es WSL, en qué se diferencia WSL 1 de WSL 2, qué problemas reales te ayuda a resolver y cómo usarlo sin “ensuciar” tu Windows. También veremos escenarios menos obvios (red, DNS, VPN, Docker, copias de seguridad, migraciones…) y cuándo quizá te compense más girar la tortilla y usar Linux como sistema principal, dejando Windows dentro de una máquina virtual.

Qué es WSL y por qué importa tanto a los desarrolladores en Windows

WSL son las siglas de Windows Subsystem for Linux, el mecanismo que ofrece Microsoft para ejecutar distribuciones GNU/Linux de forma integrada dentro de Windows 10 y Windows 11, sin necesidad de montar arranques duales ni configurar una máquina virtual clásica con VirtualBox o VMware.

En la práctica, esto significa que puedes tener Ubuntu, Debian, Kali, openSUSE y otras distros ejecutándose en paralelo con tu Windows, compartiendo archivos y permitiéndote lanzar herramientas típicas de Linux (bash, ssh, apt, Python, Node, Docker, etc.) desde tu escritorio habitual, con un grado de integración muy alto.

Desde que apareció, WSL ha generado opiniones de todos los colores: hay quien lo ve como la razón definitiva para seguir usando Windows sin renunciar al ecosistema Linux, y también quien lo percibe como una jugada estratégica de Microsoft para mantener su dominio en el escritorio. Más allá del debate, lo cierto es que ha cambiado mucho la forma de trabajar de los devs que viven en Windows pero despliegan en Linux.

Actualmente, la recomendación general es usar WSL 2, que ya no es solo una capa de traducción sino que ejecuta un kernel Linux real en una VM ligera. Microsoft insiste en que “no es una máquina virtual tradicional” porque automatiza su creación y gestión, pero a nivel técnico se apoya en tecnologías de virtualización como Hyper‑V.

WSL 1 vs WSL 2: diferencias clave, requisitos y limitaciones

Conviene entender bien la diferencia entre ambas versiones, porque afecta directamente al rendimiento, la compatibilidad y los requisitos de hardware que necesitas para que todo vaya fino.

WSL 1 funcionaba traduciendo las llamadas de sistema de Linux a Windows, sin un kernel Linux completo por debajo. Esto daba muy buen rendimiento con operaciones de disco sobre el sistema de archivos de Windows, pero fallaba en compatibilidad con software más complejo, especialmente herramientas que trabajaban a bajo nivel con el sistema.

Con WSL 2, el enfoque cambia radicalmente: se ejecuta un kernel Linux completo dentro de una máquina virtual superoptimizada. El resultado es que casi todo lo que funciona en un Linux “nativo” también funciona en WSL 2: Docker, sistemas de archivos típicos de Linux, herramientas de red avanzadas, etc.

La contrapartida es que WSL 2 tiene más requisitos. Necesitas CPU con soporte de virtualización y SLAT (Second Level Address Translation), presente en procesadores modernos (a grandes rasgos, Intel a partir de Nehalem y AMD de generaciones equivalentes). Equipos muy antiguos, como algunos Core 2 Duo, se quedan fuera para WSL 2 aunque actives todas las opciones en la BIOS.

También es imprescindible contar con una versión de Windows relativamente reciente: Windows 10 1903 (build 18362) o superior, o directamente Windows 11. En equipos con builds anteriores solo puedes quedarte en WSL 1, con sus limitaciones. Esto implica que, en cierto modo, sigues atado al ciclo de vida de Windows: si el sistema deja de estar soportado, tu WSL también se resiente.

Instalación rápida de WSL: primeros pasos y decisiones iniciales

En las versiones modernas de Windows, Microsoft ha simplificado muchísimo el proceso. Hoy basta abrir PowerShell o el Símbolo del sistema como administrador y ejecutar:

wsl –install

Con ese único comando, Windows instala el componente WSL, descarga el kernel y añade por defecto una distribución Ubuntu desde la Microsoft Store, gestionando por su cuenta las características opcionales necesarias y las descargas asociadas.

En el primer arranque de la distro se te pedirá que crees un usuario y contraseña propios del sistema Linux. Esa cuenta es independiente de tu usuario de Windows y actúa como usuario principal dentro de la distribución, lo que aporta una capa de aislamiento cómoda para separar “lo Linux” de “lo Windows”.

Si quieres ir más allá, puedes listar las distribuciones disponibles con:

wsl –list –online

y luego instalar, por ejemplo, Debian, Kali u otras variantes de Ubuntu con:

wsl –install -d NOMBRE_DISTRIBUCION

Cada distro viva en su propio contenedor aislado, de forma que puedes tener varios entornos Linux en paralelo sin que se pisen entre sí, útil si colaboras en proyectos con requisitos dispares.

Dónde guarda WSL tus datos y cuánto “ensucia” Windows

Una preocupación bastante habitual es hasta qué punto WSL llena tu sistema de cosas, dónde se almacenan los archivos y cómo dejar todo limpio si un día decides prescindir del subsistema.

Cada distribución WSL se almacena en una carpeta de datos de usuario dentro de %LocalAppData%\Packages. En su interior hay un directorio LocalState que contiene un disco virtual en formato VHDX con todo el sistema de archivos Linux: la raíz, /home, /var, bases de datos, servidores, código, etc. Vamos, el equivalente a un “disco duro” de una máquina virtual, pero gestionado por Windows.

Mientras no toques nada fuera de ahí, el impacto en las rutas habituales de Windows es muy reducido: no vas a acabar con medio disco lleno de carpetas de Linux desperdigadas. Si quieres revisar o hacer una copia del VHDX, puedes hacerlo desde el Explorador o con herramientas de terceros, pero lo normal es manipularlo siempre desde la propia distro.

Para que WSL funcione es necesario activar ciertas características de Windows, como “Subsistema de Windows para Linux” y, para WSL 2, “Plataforma de máquina virtual”. Esto se hace automáticamente con wsl –install, pero también se puede gestionar desde la GUI (“Activar o desactivar las características de Windows”) o con PowerShell (Enable-WindowsOptionalFeature).

Además, se instala el kernel Linux de WSL en rutas del sistema como %SystemRoot%\System32\lxss\tools. Una vez activas estas características, forman parte del sistema operativo y persisten hasta que las deshabilitas manualmente.

Si algún día quieres dejar Windows como si nunca hubieras tenido WSL, tendrás que desinstalar las distribuciones (wsl –unregister), desactivar las características opcionales y, si procede, eliminar el paquete del kernel. No es tan simple como borrar una carpeta, pero tampoco es un proceso especialmente enrevesado.

Usos típicos y no tan evidentes de WSL para desarrollo

El caso de uso más conocido es “quiero tener bash en Windows”, pero donde WSL realmente brilla es cuando necesitas un entorno de desarrollo muy parecido al de producción en Linux mientras sigues usando tu escritorio Windows.

Piensa en proyectos que combinan Docker, frameworks como Flask o Django, bases de datos como Postgres o ArangoDB y otros servicios típicos de backend. En vez de pelearte con versiones específicas para Windows o con un Docker Desktop caprichoso, puedes instalar todo el stack directamente dentro de tu distro WSL 2, aprovechando que el kernel Linux es “real”.

En este escenario, Docker corre de forma natural sobre WSL 2, los servicios Linux se comportan igual que lo harían en un servidor remoto y tú puedes seguir usando VS Code, navegadores y demás herramientas gráficas desde Windows, apuntando al código alojado en el sistema de archivos Linux o en una carpeta compartida.

También hay ventajas menos obvias: puedes tirar de scripts de administración, utilidades solo disponibles en Linux, buenos gestores de versiones de Node como NVM y todo el ecosistema de herramientas de consola que suele faltar o ir un paso por detrás en Windows.

Gracias a la integración de sistemas de archivos, WSL monta tus discos de Windows en /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 el proyecto ni cambiar radicalmente tu flujo de trabajo.

En sentido contrario, desde la shell de Linux puedes llamar ejecutables de Windows como notepad.exe, powershell.exe o cualquier .exe del sistema. Basta con que estén en el PATH (rutas Win32 montadas en /mnt/c/Windows/System32, etc.) y que no hayas sobreescrito esa variable en los scripts de inicio de tu distro.

Windows Terminal: el compañero perfecto de WSL

Para que la experiencia sea agradable y no acabes con diez ventanas de consola distintas, Microsoft recomienda usar Windows Terminal (Terminal Windows en castellano), una aplicación moderna que permite abrir pestañas de diferentes shells: PowerShell, CMD y cada una de tus distribuciones WSL.

Con Windows Terminal puedes tener pestañas de Ubuntu, Debian o Kali en un mismo programa, combinar paneles, personalizar colores, fuentes y atajos de teclado, y olvidarte del viejo cmd.exe o de consolas anticuadas poco configurables.

Además, al poder abrir directamente una sesión WSL, deja de tener sentido depender de herramientas como PuTTY para la mayoría de conexiones SSH: puedes conectar a servidores remotos desde la propia distro Linux, usando la misma configuración de claves y herramientas que usarías en producción.

Un flujo de trabajo muy extendido hoy en día entre desarrolladores en Windows es algo así: código en VS Code, terminal principal en Windows Terminal y backends, contenedores y herramientas de consola dentro de WSL. Esta combinación da una sensación muy parecida a trabajar en macOS o en un escritorio Linux nativo, pero sin dejar Windows.

Red, DNS, VPN y otros quebraderos de cabeza con WSL 2

Donde más problemas suelen aparecer es en la parte de red, especialmente con WSL 2. Al usar una VM ligera, depende de un adaptador de red virtual, reglas de firewall y un pequeño NAT interno que, en entornos corporativos, se puede llevar mal con políticas de seguridad, VPN agresivas o antivirus con cortafuegos integrados.

Un caso típico: el Linux de WSL arranca, pero no tiene salida a Internet ni puede resolver nombres de dominio. En muchas empresas, las reglas de firewall definidas vía directivas de grupo bloquean o ignoran las reglas locales. Como la excepción que crea HNS para permitir tráfico DNS desde la interfaz virtual de WSL es una regla local, queda anulada si el perfil tiene AllowLocalFirewallRules o AllowInboundRules en False.

En ese contexto, la solución pasa por que el administrador cree una regla corporativa adecuada que permita el tráfico necesario o, si se puede, por habilitar la funcionalidad de tunelización DNS de WSL mediante la opción experimental dnsTunneling en el archivo .wslconfig. Con esta opción, las consultas DNS del Linux interno viajan directamente al resolver de Windows a través de la capa de virtualización, reduciendo la dependencia de reglas de firewall clásicas.

También hay conflictos conocidos con algunas VPN: Cisco AnyConnect, clientes de OpenVPN concretos, soluciones tipo Zscaler, McAfee Safe Connect o Bitdefender que manipulan rutas, NRPT o proxies de formas que rompen el NAT de WSL o interfieren con el tráfico.

En esos casos, a veces funciona cambiar el modo de red de WSL a networkingMode=mirrored (modo reflejado) en .wslconfig, otras desactivar dnsTunneling, y en otros tocar la opción de autoProxy para que la propagación de HTTP_PROXY/HTTPS_PROXY dentro de Linux encaje con la configuración corporativa. El comportamiento de sufijos DNS, número de resolvers disponibles y manejo de proxies varía según estés en NAT clásico, NAT con tunelización DNS o modo espejo.

WSL y Docker: integración, ventajas y problemas típicos

Uno de los motivos más claros para adoptar WSL 2 es que mejora de forma radical la experiencia con Docker en Windows. La estrategia oficial de Microsoft y Docker pasa que Docker Desktop utilice WSL 2 como backend en lugar de hablar directamente con Hyper‑V como hacía antes.

La gran ventaja es que los contenedores se ejecutan sobre un kernel Linux real, dentro de tu distro WSL, con lo que desaparecen muchos problemas de compatibilidad y rendimiento que existían con soluciones anteriores. Además, puedes usar docker desde la propia shell de Linux como lo harías en un servidor, y seguir manejando imágenes, redes y volúmenes con los mismos comandos.

No obstante, no todo es perfecto. Se han detectado problemas cuando usas el modo de red reflejado (networkingMode=mirrored) de WSL y levantas contenedores con puertos publicados. En esos casos, Docker Desktop puede fallar al crear los contenedores si utiliza el espacio de nombres de red por defecto.

Una solución temporal es lanzar los contenedores con –network host (aprovechando que estás en un entorno de desarrollo) o añadir los puertos conflictivos al parámetro ignoredPorts en .wslconfig para que el sistema no intente redirigirlos de forma problemática.

También hay fricciones con contenedores que incluyen Network Manager u otros servicios de red complejos activos en su interior. Pueden impedir que la configuración de red de WSL funcione correctamente, sobre todo si quieres conexiones de retorno desde los contenedores al host. La recomendación habitual es desactivar esos demonios cuando no son estrictamente necesarios.

Si, además, tu empresa usa un proxy HTTP/S, puedes habilitar autoProxy en WSL para que se rellenen automáticamente variables como HTTP_PROXY, HTTPS_PROXY, NO_PROXY y WSL_PAC_URL. Ten en cuenta que cualquier variable definida por el propio usuario en la shell tendrá prioridad sobre las generadas, y que Linux no soporta de forma nativa archivos PAC, así que puede que tengas que adaptar scripts o desactivar la característica en determinados entornos.

Errores habituales dentro de la distro Linux y cómo solucionarlos

Una vez estás dentro de tu distribución, empezarán a aparecer los “clásicos” problemas de Linux, a veces amplificados por las peculiaridades de WSL. Conocerlos de antemano te ahorra bastante tiempo.

Un fallo muy común es el mensaje de “command not found” al intentar ejecutar notepad.exe, powershell.exe u otros comandos de Windows desde la shell de Linux. Suele deberse a que algún script de inicio (por ejemplo, /etc/profile en Debian o ficheros de la shell) redefine PATH machacando el valor que le pasa WSL, perdiendo así las rutas a /mnt/c/Windows y similares.

La forma correcta de actuar es no sobreescribir PATH, sino ampliarlo respetando el valor original (usando PATH=»$PATH:/ruta/nueva» en lugar de asignarlo desde cero) o eliminar las líneas conflictivas. También es buena idea revisar /etc/wsl.conf y comprobar que no tengas configurado appendWindowsPath=false, que impediría añadir el PATH de Windows automáticamente.

Otro problema recurrente aparece al ejecutar apt-get upgrade o apt full-upgrade, donde ciertos paquetes intentan lanzar servicios del sistema que en WSL no tienen sentido (no hay init clásico). Para evitar errores con udev y compañía, es habitual instalar un script policy-rc.d en /usr/sbin que devuelva exit 101, marcarlo como ejecutable y utilizar dpkg-divert para redirigir /sbin/initctl a /bin/true, evitando que se intenten arrancar demonios incompatibles.

Con SSH también hay detalles importantes. Si al conectarte a un servidor remoto ves avisos tipo “UNPROTECTED PRIVATE KEY FILE!” y permisos 0777, probablemente tengas las claves en un directorio montado desde Windows con permisos demasiado laxos. Para que WSL gestione bien los permisos tipo POSIX en archivos de Windows, conviene añadir en /etc/wsl.conf opciones de montaje como metadata, uid, gid y umask, de forma que se simulen permisos más estrictos.

En la dirección inversa, si montas un servidor OpenSSH dentro de tu distro y al conectarte desde Windows obtienes “Connection closed by 127.0.0.1 port 22”, revisa los logs arrancando sshd en modo debug y asegúrate de que existen claves de host en /etc/ssh. Si han sido eliminadas, puedes regenerarlas o, más sencillo todavía, purgar e instalar de nuevo el paquete openssh-server para que las recree automáticamente.

WSL en versiones antiguas de Windows y subsistema heredado

En equipos con Windows 10 muy antiguos (Creators Update, Anniversary Update y similares), el soporte de WSL era bastante más rudimentario. Allí entraba en juego bash.exe, lxrun y una implementación de primera generación, con comandos y rutas que no coinciden exactamente con la experiencia actual basada en la Microsoft Store.

En aquel modelo, las distribuciones se almacenaban bajo %LocalAppData%\lxss y la interoperabilidad con Windows era más basta. Se solían lanzar comandos Linux con bash -c «comando» y las posibilidades de personalización y compatibilidad eran mucho menores que con las builds modernas.

Si vienes de esa etapa y todavía conservas el WSL “heredado” activado, lo recomendable es migrar tus datos a una distro moderna de la Store, verificar que todo funciona y desinstalar la antigua. Puedes usar wsl –unregister Legacy o, con extremo cuidado, borrar manualmente la carpeta %LocalAppData%\lxss (lo que elimina todo el contenido Linux viejo de golpe).

En esos sistemas veteranos no hay WSL 2, ni soporte oficial para aplicaciones gráficas de Linux integrado, ni wsl –install simplificado, ni la integración moderna con Docker Desktop. Si tu hardware lo permite, lo ideal es actualizar a una build reciente de Windows 10 o dar el salto a Windows 11 para aprovechar todas las mejoras del subsistema.

Escenarios de uso avanzados: copias, migraciones y producción

Además del uso diario para desarrollo, WSL permite gestionar tus entornos de forma bastante limpia. Con los comandos modernos puedes exportar y respaldar distribuciones completas utilizando:

wsl –export NOMBRE_DISTRIBUCION archivo.tar

y restaurarlas en la misma máquina o en otra con:

wsl –import NOMBRE_NUEVO carpeta_destino archivo.tar

De esta forma puedes transferir tu entorno de trabajo, con todo su sistema de archivos y configuración, entre equipos sin necesidad de reproducir paso a paso la instalación y configuración de paquetes. También es una buena estrategia para mover una distro a otra unidad de disco con más espacio.

Respecto al uso en producción, Microsoft posiciona WSL principalmente como herramienta de desarrollo y pruebas. Se puede utilizar en escenarios muy concretos de producción de escritorio, pero si hablamos de servicios críticos y servidores, lo sensato sigue siendo usar Linux nativo en máquinas físicas o virtuales tradicionalmente administradas.

Por último, si tu equipo empieza a quedarse corto para los requisitos actuales de Windows 11 y no te apetece seguir el juego de las actualizaciones de hardware, una opción cada vez más razonable es instalar Linux como sistema principal y relegar Windows a una máquina virtual (con VirtualBox, VMware, GNOME Boxes, etc.). De esta manera conservas las aplicaciones que solo corren en Windows, pero te beneficias de la estabilidad y ligereza de Linux como sistema base.

Al final, WSL encaja de maravilla cuando lo entiendes como una herramienta flexible para acercar el mundo Linux a los desarrolladores que siguen cómodos en Windows, permitiéndote replicar entornos de producción, trabajar con Docker y aprovechar utilidades de consola sin abandonar tu escritorio habitual. Si sabes cómo se integra con el sistema, dónde guarda las cosas, qué problemas de red pueden surgir y cómo atajarlos, se convierte en un aliado muy potente para tu flujo de trabajo diario.