Para los que trabajamos diariamente con WSL (Windows Subsystem for Linux), cualquier cambio en el stack de red de Windows es motivo de temblor. La actualización de enero de 2026 ha introducido mejoras en el modo Mirrored Networking, pero a costa de romper la resolución de rutas en entornos de desarrollo que utilizan VPNs o contenedores Docker complejos.
Llevo una semana lidiando con el error No route to host cada vez que intento hacer un simple apt update o conectar con un microservicio en local. Tras investigar los cambios en el kernel de WSL, he dado con la tecla.
Esta es la solución que me ha funcionado en el 90% de los casos. Debemos volver a una configuración manual más estable.
[wsl2]
networkingMode=mirrored
dnsTunneling=true
firewall=true
autoProxy=false
Al establecer autoProxy=false, evitamos que el parche de 2026 intente "adivinar" la ruta de red, permitiendo que Windows maneje la conexión de forma nativa como hacía antes.
wsl --shutdown Get-VMSwitch -Name "WSL" | Remove-VMSwitch -Force
Al reiniciar WSL, Windows reconstruirá el switch virtual limpio, eliminando las tablas de rutas corruptas que provocan el No route to host.
Llevo una semana lidiando con el error No route to host cada vez que intento hacer un simple apt update o conectar con un microservicio en local. Tras investigar los cambios en el kernel de WSL, he dado con la tecla.
El origen del conflicto: El nuevo modo "AutoProxy"
Microsoft ha intentado automatizar la detección de proxies y VPNs dentro de WSL. El problema es que esta automatización crea un conflicto con el archivo de configuración .wslconfig. El sistema intenta enrutar el tráfico a través de una interfaz virtual que el parche de enero deja "huérfana".Solución 1: Forzar la configuración del archivo .wslconfig
Esta es la solución que me ha funcionado en el 90% de los casos. Debemos volver a una configuración manual más estable.
- Abrid vuestra carpeta de usuario en Windows (C:\Users\TuUsuario).
- Buscad o cread el archivo .wslconfig.
- Aseguraos de que contenga las siguientes líneas (o modificadlas si son distintas):
[wsl2]
networkingMode=mirrored
dnsTunneling=true
firewall=true
autoProxy=false
Al establecer autoProxy=false, evitamos que el parche de 2026 intente "adivinar" la ruta de red, permitiendo que Windows maneje la conexión de forma nativa como hacía antes.
Solución 2: Limpieza del Virtual Switch de Hyper-V
A veces, el parche deja residuos en los conmutadores virtuales. Si la Solución 1 no basta, haced lo siguiente desde una terminal de PowerShell con privilegios de Administrador:wsl --shutdown Get-VMSwitch -Name "WSL" | Remove-VMSwitch -Force
Al reiniciar WSL, Windows reconstruirá el switch virtual limpio, eliminando las tablas de rutas corruptas que provocan el No route to host.