Redes en WSL explicadas: por qué localhost funciona (y por qué a veces no)

febrero 6, 2026 • febrero 6, 2026 • Lectura: 24 min • Views: 0

¿Te fue útil?

Ejecutaste un servicio en WSL, abriste http://localhost:3000 en un navegador de Windows y funcionó. Asentiste como quien tiene la vida bajo control.
Luego reiniciaste, conectaste una VPN o “optimizaste” algo, y localhost empezó a comportarse como si nunca te hubiera conocido.

Las redes en WSL no son misteriosas. Son simplemente por capas. Redes de Windows más una VM Linux (WSL2), más plomería de ayuda que intenta que el flujo de trabajo de desarrollo parezca nativo.
Cuando todas las capas están de acuerdo, localhost parece mágico. Cuando no lo están, obtienes timeouts, connection refused o el peor: funciona en tu máquina y falla en la de los demás.

El modelo mental: qué significa realmente “localhost” en WSL

“Localhost” no es un lugar. Es un nombre de interfaz que se expande a una dirección IP—normalmente 127.0.0.1 para IPv4 y ::1 para IPv6.
El detalle operativo clave: 127.0.0.1 siempre significa “este espacio de nombres de red”. No “esta máquina”. No “este portátil”. No “lo que yo emocionalmente quise decir”.

En Linux puro sobre hardware, “este espacio de nombres de red” se corresponde con la pila de red del host. En WSL2, Linux se ejecuta dentro de una VM ligera con su propia pila de red.
Eso significa:

Dentro de WSL: localhost es la propia VM de WSL.
Dentro de Windows: localhost es Windows.

La razón por la que a menudo sigue funcionando es porque Windows añade pegamento: reenvío automático de puertos para acceso “estilo localhost”, más (en compilaciones más nuevas) un modo de red espejada que reduce la diferencia.

Tu trabajo como operador es dejar de pensar en “máquinas” y empezar a pensar en pilas:
¿Quién es el cliente? ¿A qué pila está enlazado el servidor? ¿En qué interfaz escucha el servicio? ¿Qué firewall está en el camino? ¿Qué NAT o proxy está haciendo traducción?

Hechos e historia interesantes que puedes aprovechar

WSL1 no tenía VM. Tradujo llamadas del sistema de Linux a llamadas del kernel NT, así que el comportamiento de red se parecía mucho más a “Windows nativo con personalidad Linux”.
WSL2 cambió a un kernel Linux real. Genial para compatibilidad; la red se convirtió en red de VM (NAT por defecto), donde nacen la mayoría de las historias de “por qué no funciona localhost”.
127.0.0.1 se especifica como loopback. Los paquetes hacia él nunca salen al cable; circulan dentro de la pila. Por eso firewalls y ruteo pueden comportarse de forma distinta a lo que esperas.
Hyper-V ya no es solo para servidores. WSL2 usa componentes de Hyper-V incluso en portátiles, por eso verás un adaptador vEthernet y un switch virtual implicados.
Windows añadió reenvío de localhost para WSL2. Windows puede escuchar en un puerto de Windows y reenviar el tráfico a la VM de WSL para que localhost:port “simplemente funcione” desde apps de Windows.
Ese reenvío es condicional. Puede romperse por política de firewall, direcciones de bind, filtros de VPN o servicios que solo escuchan en 127.0.0.1 dentro de WSL.
IPv6 es un problemita silencioso. Muchas herramientas prefieren IPv6 cuando está disponible. Si tu servicio enlaza solo IPv4 y el cliente prueba ::1, obtienes fallos confusos.
El DNS en WSL a menudo se genera automáticamente. WSL puede reescribir /etc/resolv.conf. “Arreglar el DNS” manualmente puede funcionar hasta el siguiente reinicio, y entonces tienes un déjà vu de caída.
Existe modo de red espejada. En algunas versiones de Windows/WSL puedes espejar la red del host dentro de WSL, reduciendo la rareza del NAT y haciendo el acceso entrante más predecible.

WSL1 vs WSL2: misma terminal, planeta distinto

WSL1: traducción de syscalls, sin pila de red separada

Los procesos de WSL1 comparten la pila de red de Windows. Cuando un proceso WSL1 escucha en 127.0.0.1:8000, es efectivamente el mismo loopback que Windows.
Esto hizo que “localhost” fuera simple, y también provocó que algunas suposiciones de redes en Linux fueran sutilmente incorrectas (porque no es realmente Linux).

WSL2: una VM con NAT por defecto

WSL2 ejecuta un kernel Linux real en una VM. La VM obtiene su propia IP, típicamente en una subred privada detrás de un switch virtual.
Windows es el host. Linux es el invitado. NAT es el valor por defecto.

Eso implica:

Desde WSL, el acceso saliente (a Internet o LAN) suele funcionar bien porque NAT es sencillo.
Desde Windows hacia WSL, el acceso entrante es la parte delicada porque cruzas pilas.
Desde tu LAN hacia WSL, el acceso entrante es aún más delicado porque cruzas pilas y luego cruzas NAT.

Rutas de tráfico: Windows → WSL, WSL → Windows, WSL → LAN

Cliente Windows → servidor WSL

Bucle típico de desarrollo: ejecutas un servidor web en WSL (python -m http.server), luego lo navegas desde Windows.
Esto puede funcionar vía reenvío de localhost o vía la IP de la VM WSL directamente.

Operativamente, necesitas saber cuál estás usando:

Usando localhost desde Windows: dependes de que Windows haga reenvío de puertos hacia WSL.
Usando la IP de la VM WSL: evitas algo de magia, pero ahora el filtrado de firewall y el cambio de IPs son tu problema.

Cliente WSL → servidor Windows

Común: herramientas en WSL hablando con servicios de Windows (SQL Server, proxies locales, agentes corporativos).
WSL a menudo puede alcanzar Windows vía un nameserver especial o la puerta de enlace por defecto. Algunas configuraciones también usan nombres estilo host.docker.internal (no garantizado en todas partes).

Servidor WSL → clientes LAN

Aquí es donde la gente monta “demos rápidas” que se convierten en semi-producción. Quieres que colegas en la LAN accedan a un servicio dentro de WSL.
Bajo NAT, o bien:

Usas Windows como ingreso y reenvías el tráfico hacia WSL (portproxy o el comportamiento de reenvío integrado), o
Cambias al modo espejo (si está disponible y es adecuado), o
Dejas de fingir y ejecutas el servicio en una VM/host/contenedor pensado para exposición LAN.

Por qué localhost funciona (cuando funciona)

Cuando escribes localhost:PORT en un navegador de Windows y un servicio en WSL responde, normalmente te estás beneficiando de una función de Windows que detecta puertos escuchando en WSL
y reenvía conexiones desde el loopback de Windows hacia la VM de WSL.

Los requisitos del camino feliz suelen ser:

El servicio está escuchando en una interfaz de WSL alcanzable desde Windows (a menudo 0.0.0.0 o la IP de la VM WSL; a veces 127.0.0.1 funciona según el comportamiento de reenvío y la versión).
No hay una regla de Windows Firewall que bloquee la conexión entrante en ese puerto/interfaz.
Ningún driver de VPN/filtro está interceptando o alterando el tráfico de loopback/VM de forma que rompa el reenvío.
El cliente y el servidor coinciden en IPv4 vs IPv6.

En modo espejo, la historia cambia: WSL puede compartir la red del host más directamente, así que enlazar a 0.0.0.0 en WSL puede comportarse más como “enlazar al host”.
Es más cercano a lo que la gente asume que obtiene.

Broma #1: Si alguna vez te sientes inútil, recuerda que hay personas enlazando servicios a 127.0.0.1 y preguntándose por qué la LAN no puede alcanzarlos.

Por qué localhost a veces no funciona

Los fallos se agrupan en unas pocas categorías. La mayoría son autoinfligidos. El resto es “tu pila de endpoint corporativa está haciendo algo ingenioso”.

1) El servicio está enlazado a la dirección equivocada

Enlazar a 127.0.0.1 dentro de WSL significa “solo dentro del espacio de nombres de red de WSL”.
Si el reenvío de Windows no está activo o no reenvía ese bind, las apps de Windows no lo alcanzarán.
Enlazar a 0.0.0.0 (todas las interfaces) dentro de WSL suele ser el movimiento correcto para acceso entre límites.

2) Preferencia por IPv6 convierte “localhost” en ::1

Algunos clientes resuelven localhost tanto a ::1 como a 127.0.0.1 y prueban IPv6 primero.
Si tu servicio es solo IPv4, puedes ver “connection refused” instantáneo aunque IPv4 funcionaría.

3) Windows Firewall (o controles endpoint corporativos) lo bloquean

Muchos ingenieros tratan el loopback como “sin firewall”. Eso es mayormente cierto en una sola pila. Pero el tráfico de WSL2 puede atravesar interfaces virtuales donde se aplican perfiles de firewall.
Las políticas de dominio también pueden endurecer el loopback y la exposición de puertos locales de formas sorprendentes.

4) Clientes VPN y drivers de filtro rompen ruteo/reenvío

Las VPN pueden:

Sobrescribir DNS y rutas de split-tunnel de formas que WSL no sigue automáticamente.
Instalar filtros que interfieren con el tráfico del switch virtual de Hyper-V.
Deshabilitar comportamientos de “acceso LAN local” o tratar a los adaptadores vEthernet como no confiables.

5) La IP de WSL cambió

Las IPs de la VM WSL2 pueden cambiar tras reinicios. Si codificas en duro la IP de la VM en un cliente de Windows, estás construyendo una bomba de tiempo.
Prefiere el reenvío de localhost (cuando sea fiable), el modo espejo o reglas estables de reenvío del lado Windows.

6) “Optimizaste” la pila de red

Deshabilitar servicios, ajustar la generación de resolv.conf, trastear con iptables/nftables o cambiar la configuración de WSL puede producir comportamientos localmente consistentes pero globalmente rotos.
Depurarlo después se siente como leer una novela donde el villano eres tu yo del pasado.

Guion de diagnóstico rápido

La meta no es “entenderlo todo”. La meta es encontrar el cuello de botella en menos de cinco minutos, con evidencias.

Primero: identifica qué pila falla

Desde dentro de WSL: ¿puedes alcanzar el servicio vía localhost de WSL?
Desde Windows: ¿puedes alcanzar el servicio vía localhost de Windows?
Desde Windows: ¿puedes alcanzar el servicio vía la IP de la VM WSL?

Esto divide el problema en “el servicio no está escuchando” vs “problema de reenvío/firewall/NAT”.

Segundo: confirma la dirección de bind y el listener

Revisa a qué dirección/puerto está ligado el servidor en WSL (salida de ss).
Comprueba si Windows está escuchando/reenviando en ese puerto (salida de netstat en Windows).

Tercero: revisa los dos firewalls y la VPN

Reglas de firewall en WSL (iptables/nftables) si las usas.
Perfil/reglas de Windows Firewall para el puerto y la interfaz.
¿VPN conectada? Si sí, prueba con ella apagada (o en otra red) para aislar.

Cuarto: DNS solo después de confirmar conectividad

No empieces por DNS a menos que el síntoma sea un nombre que falla. Si la conectividad por IP falla, el DNS es irrelevante.

Tareas prácticas: comandos, salidas y la decisión que tomas

Los comandos abajo están diseñados para ser ejecutables y diagnósticos. Cada uno incluye qué significa la salida y la decisión que tomas a partir de ella.
Mezcla y combina. Esto es trabajo SRE: mide, no vibes.

Tarea 1: Confirma si estás en WSL1 o WSL2

cr0x@server:~$ uname -r
5.15.133.1-microsoft-standard-WSL2

Significado: Si la cadena del kernel incluye microsoft-standard-WSL2, estás en WSL2 con red de VM.

Decisión: Asume que aplican comportamientos de NAT/reenvío. No trates localhost como compartido con Windows sin verificar.

Tarea 2: Encuentra la dirección IP de WSL

cr0x@server:~$ ip -brief addr show eth0
eth0             UP             172.24.85.101/20 fe80::215:5dff:fe12:3456/64

Significado: eth0 de WSL tiene una dirección IPv4 privada. Esta es la dirección que Windows puede usar para alcanzar WSL directamente.

Decisión: Usa esta IP para una prueba directa desde Windows. No la codifiques a fuego para flujos de trabajo a largo plazo a menos que aceptes el cambio.

Tarea 3: Verifica que el servicio realmente está escuchando (y dónde)

cr0x@server:~$ ss -ltnp | head
State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
LISTEN 0      4096   127.0.0.1:3000      0.0.0.0:*     users:(("node",pid=2123,fd=19))

Significado: El servicio escucha solo en 127.0.0.1:3000 dentro de WSL. Eso es loopback únicamente dentro del espacio de nombres de red de WSL.

Decisión: Si Windows no puede alcanzarlo, reconfigura el servicio para enlazar a 0.0.0.0 (o a la IP de WSL) cuando se requiera acceso entre pilas.

Tarea 4: Reenlazar un servidor de desarrollo a todas las interfaces (ejemplo)

cr0x@server:~$ python3 -m http.server 8000 --bind 0.0.0.0
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...

Significado: El servidor escucha en todas las interfaces IPv4, no solo en loopback.

Decisión: Ahora prueba desde Windows usando la IP de WSL y (si aplica) el reenvío de localhost de Windows.

Tarea 5: Probar desde dentro de WSL usando localhost

cr0x@server:~$ curl -sS -D- http://127.0.0.1:8000/ | head
HTTP/1.0 200 OK
Server: SimpleHTTP/0.6 Python/3.10.12
Date: Tue, 06 Feb 2026 18:22:11 GMT
Content-type: text/html; charset=utf-8
Content-Length: 1093

Significado: El servicio funciona dentro de WSL. La aplicación está bien.

Decisión: Si Windows no puede alcanzarlo, enfoca en el límite: reenvío, firewall, VPN, IPv6.

Tarea 6: Probar desde WSL hacia Windows vía la puerta de enlace por defecto

cr0x@server:~$ ip route | head -n 3
default via 172.24.80.1 dev eth0
172.24.80.0/20 dev eth0 proto kernel scope link src 172.24.85.101

Significado: La puerta de enlace por defecto (a menudo la interfaz virtual del host) es 172.24.80.1.

Decisión: Cuando WSL necesite alcanzar un servicio de Windows, esta IP de gateway es un buen primer intento.

Tarea 7: Revisar la configuración DNS dentro de WSL

cr0x@server:~$ cat /etc/resolv.conf
nameserver 172.24.80.1
search corp.example

Significado: WSL apunta el DNS a un resolvedor proporcionado por el host. Los cambios de VPN pueden afectar si ese resolvedor puede alcanzar el DNS corporativo.

Decisión: Si las búsquedas de nombres fallan pero la conectividad por IP funciona, arregla el DNS (o la integración con la VPN). No lo toques si la conectividad misma está rota.

Tarea 8: Validar resolución de nombres rápidamente

cr0x@server:~$ getent hosts github.com | head -n 1
140.82.121.4   github.com

Significado: La resolución DNS funciona al menos para esta consulta.

Decisión: Si tu problema es “no puedo alcanzar el servicio por nombre”, prueba la IP del servicio a continuación. Si eso falla, enfócate en DNS/VPN/comportamiento de resolv.conf.

Tarea 9: Comprobar si WSL puede alcanzar la LAN (saneamiento de ruteo y NAT)

cr0x@server:~$ ping -c 2 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=115 time=12.4 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=115 time=11.9 ms

--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms

Significado: La conectividad saliente funciona. NAT y ruteo no están totalmente rotos.

Decisión: Si el acceso Windows→WSL entrante falla mientras el saliente funciona, probablemente trates con firewall/reenvío/bind.

Tarea 10: Confirmar el estado de listeners del lado Windows desde WSL (sondeo rápido)

cr0x@server:~$ nc -vz 172.24.80.1 445
Connection to 172.24.80.1 445 port [tcp/microsoft-ds] succeeded!

Significado: Puedes alcanzar un servicio de Windows (SMB en este ejemplo) en la IP de la gateway.

Decisión: Si WSL no puede alcanzar servicios de Windows en absoluto, sospecha políticas de VPN/firewall en el host o un switch virtual roto.

Tarea 11: Revisar reglas de firewall en WSL (iptables) si las usas

cr0x@server:~$ sudo iptables -S | head
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

Significado: Políticas por defecto ACCEPT; WSL en sí no está bloqueando inbound.

Decisión: Si las políticas son DROP/REJECT, arréglalas o vacía temporalmente las reglas mientras depuras. Si son ACCEPT, sigue al firewall/reenvío de Windows.

Tarea 12: Comprobar listeners solo IPv6 o solo IPv4

cr0x@server:~$ ss -ltn | grep -E ':3000|:8000'
LISTEN 0      4096   0.0.0.0:8000   0.0.0.0:*
LISTEN 0      4096   [::1]:3000     [::]:*

Significado: El puerto 8000 escucha en IPv4 todas las interfaces; el puerto 3000 escucha solo en loopback IPv6.

Decisión: Si un cliente Windows prueba IPv4 y falla, habilita escucha en IPv4 o prueba explícitamente con IPv6 donde corresponda.

Tarea 13: Inspeccionar el reenvío Windows→WSL usando la prueba de IP de WSL (desde la perspectiva de WSL)

cr0x@server:~$ curl -sS -D- http://172.24.85.101:8000/ | head
HTTP/1.0 200 OK
Server: SimpleHTTP/0.6 Python/3.10.12
Date: Tue, 06 Feb 2026 18:24:51 GMT
Content-type: text/html; charset=utf-8
Content-Length: 1093

Significado: El servicio responde en la IP de la VM WSL. Eso es bueno para acceso directo desde Windows y cualquier mecanismo de reenvío.

Decisión: Si localhost:8000 en Windows falla pero la IP de WSL funciona desde Windows, el problema es el reenvío de localhost específicamente.

Tarea 14: Atrapa el error “funciona en localhost de WSL pero no en eth0”

cr0x@server:~$ curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:3000/
200

cr0x@server:~$ curl -sS -o /dev/null -w '%{http_code}\n' http://172.24.85.101:3000/
curl: (7) Failed to connect to 172.24.85.101 port 3000 after 0 ms: Connection refused

Significado: El servicio escucha solo en loopback. Por eso conectar vía la IP de la VM falla.

Decisión: Reconfigura la dirección de bind del servicio. No “arregles” firewalls para un servicio que no está escuchando donde crees que lo está.

Tarea 15: Identificar la interfaz y MTU (rarezas relacionadas con VPN)

cr0x@server:~$ ip link show eth0 | sed -n '1,2p'
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:15:5d:12:34:56 brd ff:ff:ff:ff:ff:ff

Significado: MTU es 1500. Si una VPN corporativa reduce la MTU y WSL no coincide, puedes obtener “algunos sitios funcionan, otros cuelgan”.

Decisión: Si sospechas agujeros MTU, prueba con tamaños de paquete más pequeños (o ajusta MTU) en lugar de cambiar DNS al azar.

Tarea 16: Comprobación rápida de la ruta de paquetes con traceroute

cr0x@server:~$ traceroute -n -m 3 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 3 hops max, 60 byte packets
 1  172.24.80.1  0.295 ms  0.260 ms  0.250 ms
 2  192.168.1.1  1.987 ms  1.912 ms  1.901 ms
 3  1.1.1.1      9.812 ms  9.766 ms  9.742 ms

Significado: Ves la gateway del host, luego la gateway de la LAN, luego el destino. Eso es esperado para conectividad estilo NAT.

Decisión: Si el salto 1 falla, tu red virtual WSL está rota. Si el salto 2 falla solo con VPN, la política/ruteo de la VPN es la culpable.

Tres microhistorias corporativas desde el terreno

Microhistoria 1: El incidente causado por una suposición equivocada

Un equipo de producto montó un entorno de demo interno en portátiles Windows porque la compra de infraestructura tardó y la fecha límite no.
La pila era una pequeña API en WSL2, un cliente de escritorio en Windows y una UI de administración en el navegador. Funcionaba de maravilla en la oficina.

Luego el equipo fue al sitio de un cliente. El portátil se unió a otra red, la VPN corporativa se activó y la UI de administración murió.
La API seguía corriendo. curl dentro de WSL devolvía 200s. Pero el navegador de Windows sufría timeouts con localhost.

La suposición equivocada: “localhost siempre es local”. Supusieron que porque Windows podía alcanzar WSL vía localhost en un entorno, era un contrato estable.
En realidad, dependían de un reenvío que un driver de filtro de la VPN rompió parcialmente.

La solución no fue sofisticada. Cambiaron el servidor de desarrollo para enlazar a 0.0.0.0, validaron acceso vía la IP de WSL y añadieron una regla portproxy en Windows para los puertos de la demo.
También documentaron una alternativa: si la VPN es necesaria, usar modo espejo donde esté soportado o mantener el navegador dentro de WSL (navegador Linux) para evitar cruzar la frontera de pilas.

La lección real: si tu sistema depende de una función de conveniencia, trátala como cualquier otra dependencia. Pruébala bajo VPN, políticas de firewall y cambios de red—o te probará a ti.

Microhistoria 2: La optimización que salió mal

Otro equipo tenía descargas lentas de dependencias en WSL. Alguien “optimizó el DNS” fijando /etc/resolv.conf a un resolvedor público y deshabilitando la generación automática.
Las descargas fueron más rápidas. Todos celebraron y siguieron. Así sabes que va a doler después.

Dos semanas después, los ingenieros no podían resolver nombres internos desde WSL estando conectados a la VPN corporativa.
Windows los resolvía bien. WSL podía alcanzar IPs. Pero cualquier cosa que necesitara internal.service.corp fallaba.

La optimización salió mal porque WSL ahora evitaba la ruta DNS proporcionada por el host/ VPN. La VPN esperaba que los nombres internos se resolvieran mediante los resolvedores corporativos.
Windows cumplía. WSL lo ignoraba. El resultado fue una flota de portátiles donde los servicios internos “fallaban aleatoriamente”.

El rollback fue simple: restaurar la generación automática de DNS de WSL y enseñar a la gente a medir en lugar de hacer cargo-cult.
Para el rendimiento, arreglaron el problema real: cachés, mirrors de artefactos y sacar descargas repetidas de la ruta caliente.

Broma #2: Nada es más permanente que un ajuste temporal de DNS que “solo por hoy” hizo las cosas más rápidas.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Un equipo de plataforma estandarizó el desarrollo local para un repositorio grande. No lucharon contra WSL; escribieron un pequeño script de “saneamiento de red” y lo incluyeron en el onboarding.
Comprobaba binds de listeners, imprimía la IP de WSL, validaba que Windows podía alcanzar puertos clave y advertía sobre listeners solo IPv6.

Meses después, una actualización de Windows cambió algo de comportamiento relacionado con virtualización y perfiles de firewall.
La mitad de la organización empezó a reportar “la API de desarrollo está caída” porque localhost desde Windows dejó de alcanzar WSL para algunas personas.
La otra mitad no tuvo problema, porque por supuesto era inconsistente.

El script de saneamiento convirtió el caos en triage. Los ingenieros pudieron responder, rápida y consistentemente:
“El servicio está escuchando solo en loopback de WSL.” O “Windows firewall está bloqueando el puerto reenviado.” O “Tu cliente VPN está interceptando el adaptador vEthernet.”

El equipo de plataforma no necesitó heroísmos. Necesitó comparabilidad: mismas comprobaciones, mismas salidas, mismas siguientes decisiones.
La corrección se desplegó como un cambio de configuración (valores por defecto de bind, además de fallback documentado con portproxy) y una regla única de Windows Firewall para puertos de desarrollo.

“Aburrido pero correcto” escala. “Funciona en mi máquina” no es una estrategia; es una confesión.

Errores comunes: síntoma → causa raíz → arreglo

1) Síntoma: El navegador de Windows no alcanza el servicio WSL en localhost, pero curl en WSL funciona

Causa raíz: Servicio enlazado a 127.0.0.1 dentro de WSL, y el reenvío Windows→WSL no lo está manejando (o está bloqueado).
Arreglo: Enlazar a 0.0.0.0 (o a la IP de eth0 de WSL). Volver a probar vía la IP de WSL desde Windows. Si necesitas localhost, configura explícitamente reenvío del lado Windows (y la regla de firewall).

2) Síntoma: `curl http://localhost:PORT` falla en Windows, pero `curl http://WSL_IP:PORT` funciona

Causa raíz: La ruta de reenvío de localhost está rota (actualización de Windows, firewall, driver de filtro VPN o integración deshabilitada).
Arreglo: Usa la IP de WSL para pruebas locales, o configura un listener estable en Windows que reenvíe a WSL. Si el modo espejo está disponible y es compatible, considéralo.

3) Síntoma: Funciona hasta que la VPN se conecta, luego WSL pierde resolución de nombres

Causa raíz: DNS de WSL apuntando a un lugar que no puede resolver zonas internas bajo la política de la VPN, o resolv.conf personalizado que evita el DNS corporativo.
Arreglo: Restaura la generación automática de /etc/resolv.conf. Si la política lo requiere, usa el resolvedor proporcionado por la VPN o configura DNS por interfaz de forma soportada.

4) Síntoma: Timeouts aleatorios, especialmente en descargas grandes, solo en ciertas redes

Causa raíz: Desajuste de MTU o problemas de Path MTU Discovery debido a VPN, túneles o filtrado.
Arreglo: Prueba con paquetes más pequeños; alinea ajustes de MTU cuando proceda. Si no puedes controlarlo, evita la ruta (otra red, política de split tunnel o modo espejo si cambia la ruta).

5) Síntoma: Dispositivos LAN no pueden alcanzar un servicio en WSL, pero Windows sí

Causa raíz: Límite de NAT. La VM WSL no es directamente alcanzable desde la LAN y Windows no está reenviando el puerto externamente.
Arreglo: Exponer el puerto en Windows (regla de firewall entrante + reenvío hacia WSL). O dejar de usar WSL para servicios expuestos a la LAN y desplegar en un entorno real.

6) Síntoma: “Connection refused” en vez de timeout

Causa raíz: No hay listener en esa IP:puerto (bind equivocado, puerto equivocado, mismatch IPv6/IPv4).
Arreglo: Revisa listeners con ss -ltnp. Arregla el bind. Si el listener existe solo en IPv6, prueba con [::1] o habilita IPv4.

7) Síntoma: “Timeout” en lugar de refused, pero el servicio está escuchando

Causa raíz: Drop de firewall (Windows Firewall, protección endpoint, política VPN), o ruta rota.
Arreglo: Prueba desde Windows a la IP de WSL; revisa reglas de firewall; desconecta la VPN temporalmente para aislar. No cambies la app hasta probar que los paquetes llegan a la VM.

Listas de verificación / plan paso a paso

Checklist A: Quieres que las apps de Windows alcancen un servicio en WSL de forma confiable

Bind sensato: configura el servicio de WSL para escuchar en 0.0.0.0 (o la IP de WSL), no solo en 127.0.0.1.
Pruébalo localmente: desde WSL, curl http://127.0.0.1:PORT y curl http://WSL_IP:PORT.
Prueba desde Windows usando la IP de WSL: si esto falla, tienes un problema de firewall o ruteo. Arregla eso antes de preocuparte por la magia de localhost.
Decide tu método de acceso:
- Prefiere el reenvío de localhost de Windows cuando sea estable en tu entorno.
- Si no es estable, usa reenvío explícito del lado Windows y documéntalo.
Endurece para la realidad corporativa: prueba con VPN conectada y desconectada; prueba en una red Wi-Fi de invitados una vez.

Checklist B: Quieres que dispositivos LAN alcancen algo que corre en WSL

Pregúntate “¿deberíamos?” Si esto es más que una demo, despliega correctamente.
Si procedes de todos modos: expón un puerto en Windows (regla de firewall entrante + reenvío a WSL).
Elige un puerto estable: no uses puertos efímeros altos que choquen con herramientas de desarrollo.
Registra y monitorea: si el servicio importa, añade al menos logs de acceso y un endpoint de health.

Checklist C: Problemas de DNS bajo VPN

Prueba conectividad por IP primero. Si no puedes hacer ping a una IP, el DNS no es tu problema principal.
Revisa la generación de /etc/resolv.conf. Si está fijado manualmente, espera deriva y dolores.
Prueba resolución usando getent. Ejercita el comportamiento del resolvedor del sistema, no solo una herramienta.
Alinea con la política. Si la VPN corporativa exige DNS corporativo, no lo “arregles” con resolvedores públicos y esperes que funcione.

Preguntas frecuentes

1) ¿WSL2 es básicamente una VM? ¿Debería tratarla como tal?

Sí. Es una VM ligera con un kernel Linux real. Trata la red como red de VM: pila separada, NAT por defecto y una frontera que necesita manejo explícito.

2) ¿Por qué Windows a veces puede alcanzar servicios WSL vía localhost?

Windows puede reenviar conexiones desde el loopback de Windows hacia WSL. Cuando funciona, parece un localhost compartido. Cuando no, recuerdas que no lo es.

3) ¿Por qué enlazar a 127.0.0.1 dentro de WSL rompe el acceso desde Windows?

Porque 127.0.0.1 es loopback para el espacio de nombres de red de WSL, no para Windows. Si el reenvío no traduce ese bind, Windows no puede alcanzarlo. Enlaza a 0.0.0.0 para acceso entre pilas.

4) ¿Debería siempre enlazar servidores de desarrollo a 0.0.0.0 en WSL?

Si necesitas acceso desde Windows (o LAN), sí. Si solo necesitas acceso interno a WSL, enlaza a loopback para menor exposición. Decide intencionalmente, no por hábito.

5) ¿Por qué falla solo cuando conecto la VPN?

Las VPN cambian rutas, DNS y a veces instalan drivers de filtro que interfieren con adaptadores virtuales. Si la falla se correlaciona con la VPN, aísla probando sin la VPN y comparando DNS y rutas.

6) ¿Por qué localhost a veces se resuelve a IPv6 y rompe mi servicio?

Muchos clientes prefieren IPv6 y prueban ::1 primero. Si tu servicio es solo IPv4, verás fallos aunque IPv4 funcionaría. Asegura que tu servicio escuche en ambos o prueba explícitamente con 127.0.0.1.

7) ¿Puedo hacer estática la IP de WSL?

En el modelo NAT por defecto, la IP de la VM WSL puede cambiar. Puedes construir automatización alrededor del descubrimiento, usar reenvío del lado Windows o usar modo espejo donde proceda. “IP estática WSL” suele ser una trampa.

8) ¿Por qué WSL puede alcanzar Internet pero Windows no puede alcanzar WSL?

NAT facilita el saliente. El entrante requiere listeners, binds correctos y reglas de firewall. Dirección distinta, reglas distintas. Diagnostica el entrante por separado.

9) ¿Es el modo espejo siempre mejor?

Puede reducir la confusión y simplificar el acceso entrante, pero también cambia la exposición y interactúa de forma distinta con la política corporativa. Pruébalo en tu entorno antes de estandarizar.

10) ¿Cuál es el hábito operativo que previene la mayoría de fallos de red en WSL?

Verifica siempre “¿dónde estoy escuchando?” usando ss -ltnp y prueba siempre desde ambos lados (WSL y Windows) antes de declarar victoria.

Conclusión: pasos prácticos siguientes

Las redes en WSL son previsibles una vez que dejas de antropomorfizar localhost. En WSL2 estás cruzando una frontera de VM.
A veces Windows lo suaviza. Otras veces la VPN, la política de firewall o un bind inocente te devuelven a la realidad.

Pasos siguientes que realmente aguantan en entornos cercanos a producción:

Estandariza binds de listeners: para servicios que deben ser alcanzables desde Windows, enlaza a 0.0.0.0 en WSL y documenta la decisión.
Adopta el guion de diagnóstico rápido: WSL localhost, Windows localhost, IP de WSL. No improvises.
Prueba bajo VPN: si tu organización la usa, es parte de tu “normal”, no un caso borde.
Prefiere herramientas aburridas: un pequeño script de saneamiento que imprima listeners, IPs y estado DNS evita horas de arqueología en Slack.

“La esperanza no es una estrategia.” — General Gordon R. Sullivan