Configuración de .wslconfig y wsl.conf en WSL: guía práctica total

Si trabajas con Linux dentro de Windows, la clave para exprimir el rendimiento y la estabilidad está en dos ficheros de configuración: .wslconfig y wsl.conf. Con ellos puedes ajustar desde cuánta memoria usa la VM de WSL 2 hasta cómo se montan las unidades, qué DNS se aplican o si se habilita systemd en tu distro. Aquí encontrarás una guía para crear entornos con WSL2 y Docker, práctica y detallada para dominar estas opciones sin complicarte la vida.

Antes de meter mano, conviene tener claras dos ideas: .wslconfig aplica ajustes globales de WSL (solo para WSL 2) y wsl.conf define el comportamiento por cada distribución. Además, hay una “regla no escrita” que manda: cuando cambias algo, debes reiniciar WSL correctamente para que surta efecto. A partir de aquí, nos ponemos manos a la obra con todo lo que necesitas saber y hacer, con ejemplos reales, comandos y buenas prácticas.

Diferencias clave entre .wslconfig y wsl.conf

Hay una frontera muy nítida entre ambos archivos: .wslconfig es global y vive fuera de Linux (en Windows), mientras que wsl.conf es local a cada distro y se guarda dentro del propio sistema Linux. Entender esto te evita quebraderos de cabeza al depurar problemas.

En resumen: .wslconfig se ubica en %UserProfile%\\.wslconfig (no existe por defecto, tienes que crearlo) y controla la VM de WSL 2 (memoria, CPU, kernel, redes, etc.). Por su parte, wsl.conf se ubica en /etc/wsl.conf dentro de la distribución y gobierna automontajes, opciones de red internas, interoperabilidad con Windows, usuario por defecto, arranque y más.

Importante: las opciones de .wslconfig solo afectan a WSL 2. Si tienes alguna distro en WSL 1, esas opciones globales no aplicarán.

La “regla de los 8 segundos” y cómo reiniciar bien WSL

Cuando cambies cualquier parámetro en .wslconfig o wsl.conf, no basta con cerrar la ventana de la terminal. Debes esperar a que la VM de WSL se detenga del todo, lo que suele tardar unos 8 segundos tras cerrar todas las sesiones.

Si quieres forzar un reinicio limpio, consulta los comandos para reiniciar WSL y utiliza PowerShell con estos comandos: wsl --list --running (para comprobar qué distros siguen activas) y wsl --shutdown (para apagarlas todas). También puedes finalizar una distribución concreta con wsl --terminate <NombreDistro>. Este paso es vital para que los cambios se apliquen correctamente.

wsl.conf: configuración por distribución (WSL 1 y WSL 2)

El archivo /etc/wsl.conf te permite ajustar el comportamiento a nivel de distro. Soporta secciones tipo INI: , , , , además de , y en sistemas recientes. Es perfecto para decidir cómo se montan las unidades, si se añade el PATH de Windows, o qué usuario se usa por defecto.

Puedes abrirlo con tu editor favorito como root: sudo nano /etc/wsl.conf. Si no existe, créalo. Tras editar, recuerda aplicar la regla de apagado de WSL para que los cambios surtan efecto.

Habilitar systemd en tu distro

WSL incorpora soporte de systemd en versiones recientes (WSL 0.67.6 o superior). Si tu flujo de trabajo lo necesita (por ejemplo, servicios que arrancan vía systemd), puedes habilitarlo con dos líneas en wsl.conf:

systemd=true

Comprueba tu versión con wsl --version y, tras editar, ejecuta wsl.exe --shutdown. Para verificar, usa systemctl list-unit-files --type=service y verás el estado de los servicios. Esta característica acerca WSL a una experiencia Linux mucho más fiel. Si necesitas profundizar en la gestión, consulta cómo gestionar servicios con systemd para ver ejemplos prácticos.

Automontaje de unidades de Windows (DrvFs)

La sección define cómo se montan las unidades como C: o D: dentro de Linux usando DrvFs. Puedes activarlo o desactivarlo, cambiar su raíz o añadir opciones de permisos.

• enabled (boolean): por defecto true, monta C:/ o D:/ bajo /mnt.
• mountFsTab (boolean): por defecto true, hace que WSL procese /etc/fstab al iniciar.
• root (string): por defecto /mnt/; puedes cambiarlo a /windir/ y verás /windir/c.
• options: lista separada por comas específica de DrvFs (permisos y metadatos).

Opciones útiles de DrvFs: uid, gid, umask, fmask, dmask, metadata y case. Si activas metadata, podrás usar máscaras como umask=022 o dmask=000 y afinar permisos como harías en Linux “puro”. Si en tu flujo necesitas acceder a particiones de Linux desde Windows, este apartado y DrvFs son claves para ajustar permisos y montaje.

¿Qué es exactamente DrvFs?

DrvFs es el puente del sistema de archivos entre Windows y Linux en WSL. Permite montar unidades de Windows en /mnt/c, /mnt/d, etc., y definir cómo se gestionan los permisos, la distinción entre mayúsculas/minúsculas o los metadatos. Si necesitas un comportamiento más Linux-like, activa metadata y ajusta máscaras de permisos a tu gusto.

Red, interoperabilidad, usuario por defecto y arranque

En puedes controlar el hostname, y si WSL autogenera /etc/hosts y /etc/resolv.conf. Ajustar esto es útil si prefieres gestionar DNS a mano para lograr resoluciones más estables o rápidas.

La sección define si puedes lanzar procesos de Windows desde Linux (por ejemplo, notepad.exe) y si se añade el PATH de Windows a $PATH. Si buscas un entorno Linux más “aislado”, desactiva estas opciones para evitar interferencias.

En eliges el usuario por defecto con el que arranca la distro. Conviene ajustarlo a tu usuario normal y no a root por seguridad, aunque siempre puedes entrar como root puntualmente con wsl -u root.

Con puedes disparar un comando al iniciar WSL (por ejemplo, service docker start) y proteger la autogeneración de binfmt si tienes systemd. Es una forma práctica de automatizar servicios al arrancar.

GPU y sincronización de hora

La sección te deja decidir si las apps Linux pueden acceder a la GPU de Windows mediante paravirtualización. Por defecto viene enabled=true, ideal para cargas de trabajo de IA o gráficos.

En puedes hacer que WSL use y sincronice la zona horaria de Windows con useWindowsTimezone=true. Es una ayuda sencilla para evitar desfases y desajustes al cambiar de huso horario o suspender el equipo. Si tu objetivo es usar GPU para cómputo, revisa cómo instalar CUDA en WSL y deja los drivers y toolkits actualizados.

Ejemplo completo de wsl.conf

Este ejemplo muestra varias opciones útiles: cambio de raíz de montajes, permisos de DrvFs, DNS propio y usuario por defecto. Ojo: recuerda reiniciar WSL para ver efectos. Si montas un entorno de desarrollo, puedes seguir pasos para configurar un entorno de desarrollo con WSL que integren estas opciones.

# /etc/wsl.conf

enabled=true
root=/
options="metadata,uid=1003,gid=1003,umask=077,fmask=011,case=off"
mountFsTab=true


hostname=DemoHost
generateHosts=false
generateResolvConf=false


enabled=false
appendWindowsPath=false


default=DemoUser


command=service docker start

.wslconfig: ajustes globales de la VM de WSL 2

Aquí es donde decides cuánta memoria, CPUs o swap tendrá la VM, si usas un kernel personalizado o cómo se comporta la red. Crea el archivo en %UserProfile%\\.wslconfig. Para abrir la carpeta desde PowerShell, usa cd ~ o escribe la ruta directamente en el Explorador con %UserProfile%.

Parámetros clave en la sección :

• kernel: ruta absoluta en Windows a un kernel Linux propio.
• kernelModules: VHD con módulos del kernel personalizado.
• memory: límite de RAM (por defecto 50% de la RAM de Windows).
• processors: núcleos lógicos para la VM de WSL 2.
• localhostForwarding: expone puertos de WSL en localhost:puerto del host.
• kernelCommandLine: parámetros extra del kernel (p. ej., vsyscall=emulate).
• safeMode: modo seguro para recuperar distros problemáticas (Windows 11).
• swap y swapFile: tamaño y ruta del disco de intercambio.
• pageReporting: devuelve memoria no usada al host automáticamente.
• guiApplications: activa o desactiva WSLg (apps GUI de Linux).
• debugConsole, maxCrashDumpCount: depuración y gestión de volcados.
• nestedVirtualization: virtualización anidada on/off.
• vmIdleTimeout: milisegundos de inactividad antes de apagar la VM.
• dnsProxy, networkingMode, firewall, dnsTunneling, autoProxy: controles avanzados de red y proxy.
• defaultVhdSize: tamaño máximo del VHD de la distro (por ejemplo, 1 TB).

Notas de formato: las entradas de tipo path deben usar rutas Windows con doble barra invertida, por ejemplo: C:\\Temp\\myCustomKernel. Los tamaños aceptan unidad (MB/GB); si omites la unidad, se interpretan en bytes. Algunas opciones requieren Windows 11 y versiones recientes de WSL.

Redes: NAT, mirrored, virtio y más

Con networkingMode eliges el modo de red: NAT (por defecto), mirrored, virtioproxy, bridged (en desuso) o none. En NAT, WSL aparece detrás de una NAT interna; en mirrored, la pila de red se refleja y simplifica el acceso desde la LAN a servicios en WSL; con virtioProxy se usa un backend alternativo. Si usas mirrored, puedes afinar con ignoredPorts para permitir que Linux vincule puertos aunque Windows los use.

Para exponer servicios en tu red local con mirrored, añade a .wslconfig:

networkingMode=mirrored

Tras wsl --shutdown, puedes ajustar el firewall de Hyper-V con PowerShell (administrador):

New-NetFirewallHyperVRule -DisplayName WSLPrivateInboundRule -Profiles Private -Direction Inbound -Action Allow -VMCreatorId ((Get-NetFirewallHyperVVMCreator).VMCreatorId)
# (Menos seguro) Desactivar la protección de Hyper-V por completo:
# Set-NetFirewallHyperVVMSetting -Name ((Get-NetFirewallHyperVVMCreator).VMCreatorId) -Enabled False

Mantén el firewall activo en redes públicas y limita la exposición. Si necesitas producción, plantéate proxy inverso y TLS.

Configuración experimental

La sección permite activar características en previa. Entre otras: autoMemoryReclaim (disabled, gradual, dropCache), sparseVhd (VHDs dispersos), bestEffortDnsParsing, dnsTunnelingIpAddress, initialAutoProxyTimeout, ignoredPorts y hostAddressLoopback. Algunas requieren Windows 11 22H2+ y están pensadas para optimizar memoria y red en escenarios concretos.

Ejemplo de .wslconfig comentado

Este ejemplo limita recursos, usa kernel personalizado, ajusta swap y activa funcionalidades de depuración. Perfecto para estandarizar entornos en equipos de desarrollo.

# %UserProfile%\\.wslconfig

memory=4GB
processors=2
kernel=C:\\temp\\myCustomKernel
kernelModules=C:\\temp\\modules.vhdx
kernelCommandLine=vsyscall=emulate
swap=8GB
swapFile=C:\\temp\\wsl-swap.vhdx
pageReporting=false
localhostForwarding=true
nestedVirtualization=false
debugConsole=true
maxCrashDumpCount=10


sparseVhd=true

Optimizar rendimiento de E/S y memoria

Para trabajos intensivos (por ejemplo, procesamiento de cientos de imágenes de 20 MP con ODM), conviene ajustar recursos globales y trabajar en el sistema de archivos nativo de Linux para evitar la penalización de I/O sobre /mnt/c. Establece límites de memoria y swap suficientes en .wslconfig y revisa el uso real con htop o free -h.

Recomendaciones prácticas: guarda tu proyecto en /home/<usuario>, desactiva automontajes si no los necesitas, y si el proceso sigue sin memoria, aumenta swap (p. ej., a 16 GB) y RAM asignada (p. ej., 8–12 GB según tu máquina). Si creas .wslconfig por primera vez y “no funciona”, asegúrate de que está en %UserProfile%, que el nombre es literal .wslconfig (sin extensión oculta) y de reiniciar WSL completamente.

DNS y resolución de nombres

Por defecto WSL usa los DNS del host, pero puedes decidir no autogenerar resolv.conf y poner tus servidores (Cloudflare, Google, corporativos) para lograr resoluciones más predecibles. En /etc/wsl.conf:

generateResolvConf=false

Después crea o edita /etc/resolv.conf con las entradas deseadas:

nameserver 1.1.1.1
nameserver 8.8.8.8

Si usas modos como dnsProxy o dnsTunneling desde .wslconfig, revisa también sus parámetros y, si toca, ajusta dnsTunnelingIpAddress o activa bestEffortDnsParsing para resolver peticiones ignorando registros desconocidos.

Instalación y primeros pasos

WSL viene con Windows, pero hay que habilitarlo e instalar una distro. En builds modernas (20262+), basta con ejecutar desde PowerShell o CMD: wsl --install. Ese comando habilita los componentes de WSL y VM Platform, descarga el kernel, pone WSL 2 por defecto e instala Ubuntu (puede requerir reinicio).

Al abrir la distro desde Inicio por primera vez, se te pedirá crear usuario y contraseña Linux. Son independientes de tu cuenta de Windows, y esa cuenta será la que inicie por defecto. Para cambiar la contraseña, usa passwd; si la olvidas, abre la distro como root con wsl -u root o wsl -d <Distro> -u root y ejecuta passwd <usuario>.

Actualizar paquetes y elegir dónde guardar tus proyectos

Mantén tus paquetes al día con sudo apt update && sudo apt upgrade (Ubuntu/Debian). Y recuerda esta norma de oro: trabaja en el FS donde están tus herramientas. Si compilas y ejecutas con herramientas Linux, guarda en \\wsl$\\<Distro>\\home\\<Usuario>. Si usas herramientas Windows, mantén los archivos en C:\\Users\\<Usuario>.

Para abrir el directorio actual de WSL en el Explorador, ejecuta explorer.exe .. También puedes navegar a rutas como \\wsl$\\Debian\\home\\tu-usuario desde Windows. Si la carpeta aparece vacía, abre una terminal WSL para activar la VM.

Windows Terminal y editores de código

La experiencia mejora mucho con Windows Terminal (pestañas, paneles, GPU rendering, temas…). Cada distro instalada aparecerá como perfil configurable. Para desarrollo, lo más cómodo suele ser Visual Studio Code con la extensión de Desarrollo Remoto (WSL). Desde la distro, lanza code . y tendrás un entorno de edición completo dentro de WSL.

Si trabajas en C++, Visual Studio 2022 integra soporte nativo para proyectos CMake dirigidos a WSL o SSH, permitiendo compilar y depurar en Linux desde la misma instancia de VS.

Git, contenedores y bases de datos

Configura Git en WSL y, si lo necesitas, el gestor de credenciales para no andar tecleando contraseñas. Revisa finales de línea y ficheros .gitignore para evitar sorpresas entre plataformas. VS Code integra comandos de Git que funcionan de lujo con WSL.

Con Docker Desktop y WSL 2 puedes usar contenedores de manera ágil y, si te interesa, conectar tu proyecto a un contenedor de desarrollo remoto. Para bases de datos, WSL soporta sin problema MySQL, PostgreSQL, MongoDB, Redis, SQL Server o SQLite. Es un entorno ideal para desarrollo local multiplataforma.

Aceleración por GPU y apps gráficas

WSL permite aprovechar la GPU del equipo para cargas pesadas (IA, CUDA, etc.). En la práctica, sólo asegúrate de tener drivers y toolkits al día y, si procede, valida con contenedores como nvidia/cuda. Además, con WSLg puedes ejecutar aplicaciones GUI de Linux sin configurar un servidor X externo.

Comandos de interoperabilidad útiles

Hay una convivencia muy práctica entre ambos mundos. Desde Windows: wsl ls -la para listar con herramientas Linux y filtrar con findstr o viceversa (mezclar dir y grep). Desde Linux, lanza cualquier app Windows con .exe, por ejemplo notepad.exe .bashrc. También tienes wslpath para traducir rutas entre sistemas: wslpath RUTA_WINDOWS o wslpath -w RUTA_LINUX.

Montar discos y trabajar con unidades externas

Si necesitas acceder a un disco físico o una memoria USB desde WSL 2, puedes montarlo mediante wsl --mount y gestionarlo como harías en Linux. Recuerda revisar el sistema de archivos y la necesidad de permisos de root para evitar errores de montaje.

Seguridad y administración en empresa (Intune y GPO)

Ahora puedes administrar WSL con herramientas como Microsoft Intune. Desde el portal, crea un perfil del catálogo de configuración y busca “Subsistema de Windows para Linux” para ver todas las opciones disponibles. Es ideal para forzar políticas como uso exclusivo de WSL Store, desactivar WSL 1 o impedir configuraciones personalizadas de kernel y red.

Recomendación de endurecimiento en entornos corporativos: deshabilitar AllowInboxWSL (forzar versión Store), AllowWSL1, el debug shell, configuración de kernel/línea de comandos, red personalizada, firewall vía .wslconfig, virtualización anidada o depuración del kernel. Estas GPO se definen mediante el ADMX de WSL, disponible en GitHub, e importables para gestión local.

Control de acceso y comandos

Las políticas AllowWSL, AllowInboxWSL y AllowWSL1 controlan quién puede usar WSL y qué versión. Asimismo, puedes permitir o bloquear wsl --debug-shell y wsl --mount según tus requisitos de seguridad. Es una capa adicional para evitar configuraciones no deseadas en equipos gestionados.

Solución de problemas: crear .wslconfig y casos de memoria

Si .wslconfig “no hace nada”, verifica que el archivo esté en %UserProfile%\\.wslconfig, sin extensión oculta ni BOM extraño, y que su sintaxis sea válida (sección y pares clave=valor). Tras crearlo o modificarlo, ejecuta wsl --shutdown y abre la distro.

Para cargas que agotan la memoria (como lotes de 470 imágenes de 20 MP), sube la RAM asignada y la swap. Ejemplo de punto de partida:

memory=12GB
processors=8
swap=16GB
swapFile=C:\\WSL\\swap.vhdx
pageReporting=true

Comprueba además que el proyecto esté en el FS de Linux. Si sigues recibiendo “out of memory”, revisa límites propios de la herramienta (parámetros de ODM), activa autoMemoryReclaim si te interesa recuperar caché rápido y monitoriza el consumo con top/ htop. No olvides que Windows también debe disponer de RAM libre suficiente.

Buenas prácticas extra y recursos

Cuando experimentes con network mirrored, ajusta el firewall con cabeza; si desactivas reglas para probar, vuelve a activarlas después. Si necesitas documentación adicional o ejemplos alternativos, puedes curiosear recursos externos como este PDF. Y si trabajas con GPU, valida tu stack (drivers, CUDA/toolkit, versiones) antes de meterte en harina.

Para quienes administran flotas, el combo Intune + ADMX da un control fino sobre qué se puede tocar en .wslconfig, qué comandos están permitidos y si se aceptan distros WSL 1. Esto ayuda a estandarizar entornos, reducir incidencias y elevar el nivel de seguridad.

Con estos ajustes, tienes una guía holística para configurar WSL de manera profesional: usa wsl.conf para perfilar cada distro, .wslconfig para gobernar la VM global, reinicia WSL con cabeza, aprovecha el FS nativo de Linux para rendimiento, saca partido a GPU y redes avanzadas y, si trabajas en empresa, apóyate en políticas para mantener todo bajo control.