Reaching localhost:5173 from Windows when Vite runs in WSL2

Windows can already reach it, the LAN cannot

This is the part that confuses people who come from Docker. In WSL2 the Windows side is not "another machine" — WSL forwards localhost into the distribution, so Edge or Chrome on Windows opens localhost:5173 against a dev server that is still bound to loopback inside Linux. Nothing else on your network can, because the distribution sits behind a virtualised ethernet adapter with its own IP address. Vite states this plainly in the server.host option: on WSL2, host: true is not sufficient to reach the server from your LAN.

• Windows browser → localhost:5173 — works with the default config.
• Phone or second laptop → your Windows IP on 5173 — does not, until the Windows side forwards it.

Which networking mode are you in

WSL uses a NAT architecture by default, and the answer to every LAN question below depends on whether you have left it there. Two commands tell you: the WSL version, and whether the distribution has an address of its own or one of the Windows addresses.

PS> wsl --version
WSL version: 2.6.1.0            # mirrored mode needs 2.0.0+ on Win11 22H2+

$ wsl hostname -I
172.24.118.43                   # own subnet -> NAT mode
                                # a Windows LAN address -> mirrored mode

NAT mode: forward the port on the Windows side

Microsoft documents the workaround as the one you would use for any virtual machine: a portproxy on Windows that listens on your LAN address and connects to the WSL2 VM. The connect address is the output of wsl hostname -I — with a capital I. The lowercase variant returns 127.0.1.1, a placeholder that will forward to nothing.

PS> netsh interface portproxy add v4tov4 \
     listenport=5173 listenaddress=0.0.0.0 \
     connectport=5173 connectaddress=(wsl hostname -I)

The WSL2 VM address changes on restart — this entry goes stale.

Mirrored mode: the LAN reaches WSL directly

On Windows 11 22H2 and higher you can switch networking mode instead of maintaining a port proxy. Mirrored mode mirrors the Windows network interfaces into Linux; Microsoft lists "connect to WSL directly from your local area network" as one of its benefits, along with IPv6 support and reaching Windows servers from Linux over 127.0.0.1. It is a per-machine setting in .wslconfig, not a per-project one.

[wsl2]
networkingMode=mirrored

Mirrored mode still has a firewall in front of it

Since WSL 2.0.9 on Windows 11 22H2 and higher the Hyper-V firewall is on by default, and it drops inbound connections to the distribution before Vite ever sees them. Microsoft gives two ways to open it: allow inbound traffic for the WSL VM creator, or add a single rule for the port you actually want.

# one port only — the narrower of the two
New-NetFirewallHyperVRule -Name "ViteDev" -DisplayName "Vite dev server" \
  -Direction Inbound -Protocol TCP -LocalPorts 5173 \
  -VMCreatorId '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}'

Once traffic arrives, --host matters again

Both routes above deliver connections that look like LAN connections to the dev server. A server still bound to loopback inside the distribution refuses them, so the Windows-side work only pays off together with the bind. Set it for the run you need it in rather than in the committed config — the dev server serves your source and applies no authentication.

$ npm run dev -- --host

The page loads but never reloads

This is the second WSL2 problem and it has nothing to do with networking. Vite documents that on WSL2 file system watching does not work when a file is edited by a Windows application — a non-WSL2 process — because of a WSL2 limitation, and that the same applies to Docker running on a WSL2 backend. If you keep the project under /mnt/c and edit it from a Windows editor, the dev server never hears about the change.

• Recommended by Vite: edit with WSL2 applications, and move the project folder off the Windows filesystem — reaching it from WSL2 is slow on top of being unwatchable.
• Fallback: server.watch.usePolling, which Vite flags for high CPU utilisation.

Polling is the fallback, not the setting

Enable it where events genuinely do not arrive, and leave it off everywhere else. On a project of any size it keeps a core busy for as long as the server runs.

export default {
  server: {
    watch: { usePolling: true },
  },
}

If you reach it through VS Code instead

VS Code forwards the port itself rather than using either route above, and Vite documents a separate fix for it: with a Dev Container or the port forwarding feature in VS Code, set server.host to 127.0.0.1, because that forwarding does not support IPv6.

server: { host: '127.0.0.1' }

• Reaching the Vite dev server from anything other than localhostThe Vite dev server binds to localhost only and rejects unknown hostnames, so a second device, a container or a tunnel needs two separate settings: server.host to bind wider, and server.allowedHosts to accept the name being used.
• Reaching localhost:5173 from your phone or another machineThe dev server listens on localhost by default, so nothing else on the network can reach it — start it with --host (or set server.host) to listen on your LAN address.
• Running the Vite dev server in a containerInside a container localhost means the container, so the dev server has to listen on 0.0.0.0 and the port has to be published — mapping the port alone is not enough.
• localhost:5173 — the port itselfWhat the address means, common dev ports, and the autocomplete fix.