How is a WSL2 distribution attached to the network by default, and why can a browser on Windows reach a server listening on localhost inside WSL2 while a process inside WSL2 cannot reach a Windows service the same way?

## The default: a NAT'd utility VM Under WSL2 the distribution runs inside a Hyper-V utility VM with a virtual network adapter on a virtual switch created for WSL. Windows holds an interface on that same internal network, and outbound traffic from the VM is **network-address-translated** behind the host. Practically: - The VM has its own private IP address, distinct from any address Windows shows for its physical NIC. - Outbound connections from Linux to the internet work transparently, appearing to come from the Windows host. - Inbound connections from the LAN do **not** reach the VM, because nothing on the outside knows it exists. WSL1 behaved completely differently: it had no VM and shared the Windows network stack directly, so `localhost` was the same `localhost` on both sides. Everything below is a consequence of that change. ## Windows → Linux: a relay, not routing Start a dev server inside WSL2 on port 3000 and a browser on Windows can usually open `http://localhost:3000`. That is not routing — a Windows `localhost` connection cannot traverse into a separate VM by itself. WSL runs a **forwarding relay** on the Windows side that accepts connections to `localhost:<port>` and proxies them into the VM on the same port. It is governed by `localhostForwarding` in `%UserProfile%\.wslconfig`, enabled by default, and it works even when the Linux service is bound only to `127.0.0.1` inside the VM. ```ini [wsl2] localhostForwarding=true ``` Because it is a relay rather than a route, it has relay-shaped failure modes: it applies to the running distribution, it can miss ports opened at unusual moments, and a `wsl --shutdown` plus restart is the standard remedy when a port stops forwarding. ## Linux → Windows: no relay exists There is no symmetric relay. Inside the VM, `127.0.0.1` is the VM's own loopback interface, so a Linux process pointing at `localhost:8080` is asking for a Linux service on 8080 and gets `ECONNREFUSED` if none is listening. To reach a service hosted on Windows you must use the **host's address on the WSL network**. When `generateResolvConf` is left enabled, WSL writes that address into `/etc/resolv.conf` as the `nameserver`, which makes it the conventional way to discover it at runtime: ```bash WIN_HOST=$(grep -m1 '^nameserver' /etc/resolv.conf | awk '{print $2}') curl "http://$WIN_HOST:8080/health" ``` Then expect a second obstacle: **Windows Defender Firewall**. The WSL adapter is a separate network the firewall evaluates on its own, and inbound rules commonly block traffic from it, so a service that works from a Windows browser still times out from Linux until a rule permits it. Note too that a Windows service bound only to `127.0.0.1` is unreachable from the VM no matter what the firewall says — it must listen on the interface the VM can see. ## The address is not stable Both the VM's address and the host's address on the WSL network can change when WSL shuts down and restarts. Hard-coding either into a config file, a hosts entry or a container definition is a classic bug that works all afternoon and breaks the next morning. Derive it at runtime, as above. ## Exposing a WSL service to the rest of the LAN Other machines see the Windows host, not the VM. To publish a WSL2 service externally you forward the port on the Windows side — `netsh interface portproxy` is the built-in mechanism — and add a firewall rule for it. Because the VM's IP moves, that mapping needs refreshing, which is exactly why people script it or avoid the arrangement altogether for anything long-lived. ## Mirrored networking removes the asymmetry Current WSL on Windows 11 offers an alternative mode, set in `.wslconfig`: ```ini [wsl2] networkingMode=mirrored ``` In mirrored mode the VM mirrors the host's network interfaces instead of sitting behind NAT. `localhost` then works in **both** directions, the Linux side sees the host's addresses including IPv6, and services in WSL become reachable from the LAN. It also brings related options such as DNS tunnelling and a Hyper-V firewall applied to the VM. Mention the version dependency when you recommend it — it is not available on older Windows 10 builds, where NAT is all you have. ## What the interviewer is checking That you explain the asymmetry with a mechanism — a one-way relay on top of NAT — instead of calling it a quirk; that you know `localhost` means different things on the two sides; that you reach for the firewall as the second suspect; and that you do not hard-code an address the platform reassigns.