Ajuste de WSL2 — memoria, systemd, DNS y E/S en un solo paso

Si has instalado WSL2 mediante la configuración inicial de Windows, el siguiente paso es el ajuste. Ejecutar con los valores predeterminados lleva a un consumo de memoria descontrolado, DNS roto tras el reinicio, disco en expansión constante y systemd ausente. Esta guía cubre siete pasos de ajuste en un solo paso — aplícalos una vez, benefíciate a diario.

Objetivo: Windows 11 (22H2+) + WSL2 + Ubuntu (o cualquier distribución basada en systemd).

Resumen

Requisitos previos

• Windows 11 22H2 o más reciente (algunas funciones prefieren 23H2+)
• WSL2 instalado + al menos una distribución con capacidad systemd (Ubuntu, etc.)
  • Si no está instalado: en PowerShell como administrador, wsl --install
• Se recomiendan derechos de administrador para wsl --shutdown (.wslconfig en sí está en el perfil de usuario)

1. .wslconfig — límites de RAM/CPU/swap

Por defecto WSL2 puede usar hasta el ~50% de la RAM de Windows — una compilación grande de Node puede empujar al propio Windows a usar swap. Establece límites explícitos.

1.1 Plantilla

# PowerShell
Invoke-WebRequest -Uri https://devalice.jaceclub.com/assets/windows/wsl-tuning/wslconfig-template.txt -OutFile $env:USERPROFILE\.wslconfig
Get-FileHash $env:USERPROFILE\.wslconfig -Algorithm SHA256
# esperado: BFBDAF7AE486916D8AA4E792F9845416E1B6B6EA535F84E1BBCCA2BE9ACCB3C4
# (minúsculas: bfbdaf7ae486916d8aa4e792f9845416e1b6b6ea535f84e1bbcca2be9accb3c4)

1.2 Ajustes clave

# %USERPROFILE%\.wslconfig
[wsl2]
memory=8GB             # 50–75% de la RAM del host
swap=4GB               # swap en disco (0 = deshabilitado)
localhostForwarding=true
guiApplications=true   # Apps GUI de Linux (predeterminado en Win11)
# processors=8         # límite explícito de núcleos (opcional)

1.3 Aplicar

wsl --shutdown   # detener todas las instancias WSL
wsl              # el siguiente inicio recoge .wslconfig

1.4 Verificar

Dentro de WSL:

free -h          # el límite de memoria coincide (p. ej. 8 GB)
nproc            # número de CPU
swapon --show    # swap activo

Una máquina host de 16 GB funciona bien con memory=10GB. Una de 32 GB: memory=16GB.

2. Habilitar systemd — /etc/wsl.conf

El init predeterminado de WSL2 no es systemd. Los paquetes modernos (docker, snap, servicio postgresql, etc.) lo esperan.

2.1 Habilitar

# dentro de WSL (requiere sudo)
sudo nano /etc/wsl.conf

Contenido:

[boot]
systemd=true
 
[user]
default=me          # usuario predeterminado (opcional)

Guarda y luego:

# Windows PowerShell
wsl --shutdown
wsl

2.2 Verificar

ps -p 1            # PID 1 == systemd → éxito
systemctl status   # información de systemd mostrada → OK

Ahora sudo systemctl start docker y similares funcionan correctamente.

El tiempo de arranque aumenta 1–3 segundos; a cambio obtienes un gestor de servicios real, registro en journal y completado por tabulación.

3. Estabilidad DNS

El DNS predeterminado de WSL2 pasa por un puente NAT de Windows que a menudo se rompe tras conectar/desconectar VPN o reiniciar. Síntoma: curl github.com funciona pero apt update no, o viceversa.

3.1 Opción A — deshabilitar DNS automático + resolvedores estáticos

sudo nano /etc/wsl.conf

Añade:

[network]
generateResolvConf=false

Guarda → wsl --shutdown → reinicia.

Ahora WSL deja de reescribir /etc/resolv.conf. Configúralo manualmente:

sudo nano /etc/resolv.conf

nameserver 1.1.1.1
nameserver 8.8.8.8

En redes corporativas/VPN, añade el DNS interno que te proporcione tu equipo de TI.

3.2 Opción B — red en modo espejo (Win11 22H2+, recomendado)

La sección 7 hace que WSL comparta el DNS de Windows automáticamente. Más estable en VPN corporativo.

4. Rendimiento de E/S — dónde poner tu trabajo

El ajuste más frecuentemente omitido. El rendimiento difiere significativamente:

Regla: el trabajo en WSL vive dentro del disco WSL. Si Windows necesita los mismos archivos, usa VS Code Remote-WSL (§6) o Syncthing (consulta sincronización de archivos) para mantener copias en ambos lados.

4.1 Patrón correcto

# dentro de WSL
mkdir -p ~/work
cd ~/work
git clone git@github.com:org/repo.git
cd repo
npm install              # rápido

4.2 Antipatrón

# clonar en Windows, compilar vía WSL
cd /mnt/c/Users/me/Documents/project   # montaje cruzado
npm install                             # lento (decenas de minutos)

4.3 Cuándo el montaje cruzado es necesario

• Una herramienta solo para Windows debe abrir la misma carpeta (Photoshop, etc. — raro)
• Editar desde un IDE de Windows — solucionable con VS Code Remote-WSL

5. Tamaño del disco — compactación del vhdx

El disco virtual .vhdx de WSL nunca se reduce automáticamente. Crea una caché de 30 GB, bórrala — el archivo sigue en 30 GB.

5.1 Comprobar el tamaño actual

# PowerShell
Get-ChildItem -Path "$env:LOCALAPPDATA\Packages" -Recurse -Filter "ext4.vhdx" | ForEach-Object {
  "{0,-60} {1:N2} GB" -f $_.Directory.Name, ($_.Length / 1GB)
}

5.2 Opción A — VHD disperso (Win11 22H2+)

En .wslconfig (ya comentado en la plantilla de §1.1):

[experimental]
sparseVhd=true

wsl --shutdown lo habilita. El espacio no utilizado se recupera de forma incremental.

5.3 Opción B — compactación manual (diskpart)

Con WSL detenido:

wsl --shutdown
 
diskpart
# diskpart>
select vdisk file="C:\Users\me\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu_*\LocalState\ext4.vhdx"
attach vdisk readonly
compact vdisk
detach vdisk
exit

Decenas de GB recuperables. Lento — ejecútalo de noche.

5.4 Opción C — Export/Import (más limpio)

Copia de seguridad completa + recrear. El nuevo vhdx empieza con tamaño óptimo.

wsl --shutdown
wsl --export Ubuntu C:\backup\ubuntu.tar
wsl --unregister Ubuntu
wsl --import Ubuntu C:\WSL\Ubuntu C:\backup\ubuntu.tar

La opción C es la más efectiva pero el ID de instancia / metadatos de instalación se recrean. Vuelve a aplicar la configuración de systemd, usuario predeterminado, etc. Mejor hacerlo durante una migración planificada.

6. VS Code Remote-WSL

Edita archivos WSL desde Windows VS Code a velocidad nativa. La respuesta estándar al problema del montaje cruzado.

6.1 Instalación

En el marketplace de Windows VS Code:

• Remote - WSL (ms-vscode-remote.remote-wsl)

O desde la línea de comandos:

code --install-extension ms-vscode-remote.remote-wsl

6.2 Uso

Dentro de WSL:

cd ~/work/repo
code .

→ Windows VS Code se abre, la esquina inferior izquierda muestra WSL: Ubuntu. El sistema de archivos, el terminal y las extensiones se ejecutan todos dentro de WSL.

Alternativamente, en Windows VS Code: Paleta de comandos → WSL: Connect to WSL → elige una carpeta.

6.3 Extensiones que instalar en el lado WSL

En la primera conexión, algunas extensiones preguntan «¿Instalar en WSL?». Recomendado decir que sí:

• ESLint / Prettier
• Python / Pylance
• Go / Rust-Analyzer
• Docker

7. Red en modo espejo (Win11 22H2+)

Una solución más elegante que §3. WSL refleja directamente la interfaz de red de Windows — VPN, red corporativa, DNS y localhost se comportan de forma idéntica al host.

7.1 Habilitar

En .wslconfig:

[wsl2]
networkingMode=mirrored
 
[experimental]
dnsTunneling=true
autoProxy=true

wsl --shutdown y reinicia.

7.2 Efectos

• VPN — WSL pasa automáticamente por la VPN
• Proxy corporativo — el proxy IE/Edge de Windows se recoge automáticamente
• localhost — Windows ↔ WSL es bidireccional (no se necesita localhostForwarding)
• DNS — igual que Windows, el más estable

7.3 Advertencias

• Conflictos con algunas compilaciones de Docker Desktop — desactívalo temporalmente si tienes problemas
• Algunos escenarios avanzados de red de contenedores se comportan de forma diferente — verifica si haces trabajo profundo con contenedores

Verificación

Las cinco comprobaciones:

1. Dentro de WSL, free -h muestra el límite de .wslconfig (p. ej. 8,0 Gi)
2. ps -p 1 muestra systemd
3. curl -sS https://www.google.com -o /dev/null && echo OK → OK (DNS/red)
4. Tanto cd ~ && touch test.txt && ls como cd /mnt/c/Users/$USER && touch test.txt && ls funcionan (solo difiere la velocidad)
5. Desde VS Code, code . muestra WSL: Ubuntu en la esquina inferior izquierda

Resolución de problemas

Los cambios en .wslconfig no se aplican

• Olvidaste wsl --shutdown. Todas las instancias WSL deben parar completamente antes de que el siguiente inicio recoja el archivo.
• La ubicación debe ser %USERPROFILE%\.wslconfig (tu home de usuario), no %LOCALAPPDATA%.
• El nombre de archivo debe ser .wslconfig (punto inicial, sin extensión).

El arranque falla tras habilitar systemd

• Causa habitual: un error de sintaxis en /etc/wsl.conf (p. ej. falta la cabecera [boot]).
• Recuperación: desde PowerShell, wsl -u root -d Ubuntu para entrar como root y corregir /etc/wsl.conf.

apt update devuelve errores de DNS

• Aplica §3.1 (manual /etc/resolv.conf), o cambia a §7 red en modo espejo.
• En VPN, asegúrate de añadir el DNS corporativo.

npm install es insoportablemente lento

• §4 — estás trabajando desde /mnt/c/.... Muévete a ~/work.

VS Code Remote-WSL falla al conectar

• code no está en el PATH. Abre VS Code en Windows una vez → Paleta de comandos → Shell Command: Install 'code' command in PATH.
• Verifica con code -v dentro de WSL.

Docker Desktop falla tras la red en modo espejo

• Docker Desktop asumía el modo NAT. Reconfigura su integración WSL, o deshabilita el modo espejo mientras usas Docker.

El vhdx no se reduce (§5)

• compact vdisk de diskpart está limitado por la fragmentación. La opción C (export/import) es la más limpia.

Referencias

• Configuración inicial de Windows — instala WSL2 primero
• Microsoft WSL — Configuration
• Anuncio de red en modo espejo de WSL
• Anuncio de VHD disperso

Registro de cambios

• 2026-05-12 — Traducción inicial al español (devAlice M2 i18n seed)