← All articles

wsl localhost

wsl localhost: share your Linux dev server from Windows

WSL localhost works from Windows in many cases, but LAN and reviewer access can still break. Learn the options and the fastest review path.

Published May 24, 2026 4 min read
In this article

The wsl localhost problem appears when a dev server runs inside Linux, loads from Windows, then fails from another device or reviewer link.

WSL networking has improved, but the mental model still confuses developers. localhost can mean Windows, the WSL Linux instance, a NAT boundary, or a mirrored network mode depending on where the command runs and which WSL settings you use.

This guide shows the practical paths for local testing, LAN access, and public review.

wsl localhost: the short version

If your browser runs on Windows and your server runs in WSL, try http://localhost:<port> first. Microsoft documents this as the normal path for accessing Linux networking apps from Windows in WSL 2 NAT mode.

If another device on your LAN needs the WSL app, localhost will not work from that device. You need mirrored networking, a Windows port proxy, or a tunnel.

If a client or teammate outside your network needs the app, use a temporary public link from inside WSL:

npx wiremaven-cli 3000 --expires 30m --name wsl-review

That creates a public URL for the local port without asking the reviewer to understand WSL networking.

Access WSL from Windows

Start your dev server inside WSL:

npm run dev -- --host 0.0.0.0

Then open the app from a Windows browser:

http://localhost:3000

Many frameworks bind to 127.0.0.1 by default. That can still work from Windows because WSL forwards localhost in common cases. Binding to 0.0.0.0 helps when you later need access from another interface or a tunnel process that does not share the same assumptions.

If Windows cannot reach the app, confirm the server is listening in WSL:

curl http://localhost:3000

Then check whether the dev server requires an allowed host. Many frameworks block requests from hostnames they do not recognize.

Find WSL and Windows IP addresses

Microsoft documents two common IP lookups.

From Windows PowerShell, get the WSL distribution IP:

wsl.exe hostname -I

From inside WSL, get the Windows host IP as seen by Linux:

ip route show | grep -i default | awk '{ print $3 }'

These IPs matter in default NAT mode. Microsoft notes that mirrored mode lets Windows and WSL connect to each other through localhost, and it can also improve VPN and LAN compatibility on supported Windows 11 versions.

Do not hard-code WSL 2 NAT IPs into a workflow. WSL 2 IP addresses can change after restart.

Access WSL from another device on your LAN

A phone or second laptop cannot open http://localhost:3000 and reach your WSL app. On that device, localhost means that device.

You have three options:

  1. Enable WSL mirrored networking on supported Windows versions.
  2. Use Windows netsh interface portproxy to forward a host port to WSL.
  3. Use a public tunnel and skip LAN routing.

Microsoft documents a netsh interface portproxy approach for WSL 2 NAT mode. The pattern listens on the Windows host and connects to the WSL VM address:

netsh interface portproxy add v4tov4 listenport=3000 listenaddress=0.0.0.0 connectport=3000 connectaddress=<wsl-ip>

You also need Windows firewall rules that allow inbound traffic to the listen port. Microsoft notes that listenaddress=0.0.0.0 accepts requests from any IPv4 address, so restrict the portproxy to specific source addresses with a Windows firewall rule.

Use LAN access for testing your own phone. Use a tunnel for remote reviewers.

Share WSL localhost with a remote reviewer

The simplest public path is to run the tunnel command from the same WSL environment as your app.

npx wiremaven-cli 3000 --expires 30m --name windows-wsl-demo

wiremaven creates a temporary encrypted public link and connects out to the relay over WebSocket. The reviewer opens the link in a browser. During beta, no account is required.

The session can last 15, 30, or 60 minutes. While it runs, you see viewer joins, request outcomes, failures, and remaining time. That matters when a reviewer hits a route that works on Windows but fails in the tunneled WSL path.

For setup details, see the wiremaven docs. For the outbound relay model, read how wiremaven works.

Common WSL localhost failures

If Windows can load the app but the public tunnel cannot, check where the tunnel command runs. A tunnel started in Windows may not see a service bound only inside WSL the same way a tunnel started in WSL does.

If a phone on the same WiFi cannot load the app, check the firewall and whether the dev server binds to 0.0.0.0 instead of 127.0.0.1.

If the app loads but assets fail, check framework host settings and asset URLs. Some dev servers produce absolute URLs that assume localhost.

If the app uses secure cookies, camera APIs, service workers, or OAuth callbacks, confirm that the public URL uses HTTPS and that the callback host matches what the provider expects.

FAQ

Why does WSL localhost work on Windows but not my phone?

Windows can forward localhost to WSL in common WSL 2 setups. Your phone has its own localhost, so it needs a LAN IP, port proxy, mirrored networking, or a public tunnel.

Should I run the tunnel command in Windows or WSL?

Run it where the app runs. If your dev server runs inside WSL on port 3000, start the tunnel inside WSL so the local port reference matches the server.

Is WSL mirrored networking required?

No. It can help on supported Windows 11 versions, but you can also use portproxy for LAN access or a tunnel for remote review.

Start from WSL

From the WSL shell where your app runs:

npx wiremaven-cli 3000 --expires 30m

Related: access localhost from phone and what is a localhost tunnel.