Unable to reach WSL from Windows with mirrored networking mode

[gaac510]

Windows Version

Microsoft Windows [Version 10.0.26100.4202]

WSL Version

2.5.7.0

Are you using WSL 1 or WSL 2?

• [x] WSL 2
• [ ] WSL 1

Kernel Version

6.6.87.1-1

Distro Version

Ubuntu 24.04

Other Software

No response

Repro Steps

Preparation

1. Set WSL to use mirrored networking mode, make sure systemd is enabled, and leave everything else default.
2. Reboot Windows to make sure the settings take effect. (The reboot has been necessary for me, I'm not sure about everyone else's situation.)

Scenario A - Docker 101 served from port 80

In WSL, run docker run --rm -p 80:80 docker/getting-started to start serving Docker 101 tutorial from port 80.

Scenario B - Serve a Next.js dev app from port 3000

1. In WSL, run npx create-next-app@latest to create a Next.js app.
2. cd into the project directory, and run npm run dev to start a dev server at port 3000.

Scenario C - Serving various Supabase services with Docker from port 5432*

1. In WSL, run npx create-next-app@latest to create a Next.js app.
2. cd into the project directory, and run npm install supabase --save-dev to install Supabase as a project dev dependency.
3. Run npx supabase init and then npx supabase start to start various containerised services - they should occupy port 54321, 54323 and 54324.

Expected Behavior

These URLs should all be reachable from both within WSL and from host Windows:

• http://localhost:80
• http://localhost:3000
• http://localhost:54321
• http://localhost:54323
• http://localhost:54324
• http://127.0.0.1:80
• http://127.0.0.1:3000
• http://127.0.0.1:54321
• http://127.0.0.1:54323
• http://127.0.0.1:54324

Actual Behavior

• All URLs listed were only reachable from within WSL.
• Loading any of the URLs in MS Edge running in host Windows resulted in (address differed for each URL):

  Hmmm… can't reach this page
  localhost refused to connect.
  
  Try:
  Search the web for [localhost](https://www.bing.com/search?form=ANLKDR&q=localhost)
  Checking the connection
  [Checking the proxy and the firewall](chrome-error://chromewebdata/#buttons)
  
  ERR_CONNECTION_REFUSED
  

  I also tried requesting using Bruno, and I always got connect ETIMEDOUT 127.0.0.1:3000 (port differed for each URL).

Additional troubleshooting I've done

• Installed a brand-new Ubuntu 24.04 distro and tested from there - got same issue.
• Changed to NAT networking mode while leaving everything else unchanged - didn't get the same issue, i.e. can reach WSL from Windows.
• Tried systemctl disable network-manager.service and systemctl disable NetworkManager.service - neither worked since neither service existed.
• Realised there's systemd-networkd.service and it was already disabled; in vain hope, tried enabling & starting the service and then stopping & disabling the service - in the end, nothing changed i.e. still got the same issue.
• Tried both Hyper-V firewall commands noted at https://learn.microsoft.com/en-us/windows/wsl/networking#mirrored-mode-networking - made no difference i.e. still got the same issue.
• Played with disabling/enabling the "Hyper-V" and/or the "Windows Hypervisor Platform" Windows features - made no difference i.e. still got the same issue.

Diagnostic Logs

WslNetworkingLogs-2025-05-30_21-43-52.zip

[github-actions[bot]]

Diagnostic information

.wslconfig found
Detected appx version: 2.5.7.0
optional-components.txt not found

[IbrahimTanyalcin]

I have an unrelated issue across devices on WSL2 even with older docker images that used to work. What is broken in my case is the detection of whether the app is running as container or not. And to do that, the old school method is to grep inside /proc/1/cgroup and check if it matches docker|lxc. This recently stopped working, across WSL2, across docker versions suddenly.

Did they push something on the wsl kernel?

The above check is important because if running inside container, you listen to 0.0.0.0:3000 otherwise 127.0.0.1:3000. I believe somewhere in your stack, a similar check has failed resulting in the behavior you observe: reachable inside WSL, but otherwise EMPTY response from windows because it is not listening on 0.0.0.0

[gaac510]

@IbrahimTanyalcin Thanks for the input. What you described is a little over my head. Does the cgroup issue only impact docker containers running inside a WSL distro? Or does it impact WSL distros themselves?

I did an additional check based on your info, which was to check if my (only) distro supports cgroup v2 following this, and I did get nodev cgroup2.

Also, my issue occurs even in scenario B where a web app was not served from a docker container. Does this mean I'm more likely experiencing a different issue?

[WangMinan]

same issue

[kjkent]

Similar issue here. It seems that binding to 0.0.0.0 vs localhost is involved, at least in my case. However, there's something non-intuitive/quirky/broken with the forwarding of localhost between Windows host and Linux VM. Example:

1. Inside WSL, start an Astro dev server: pnpm run dev

   By default, this listens to localhost only. Similarly, WSL sets the linux hosts file, with 127.0.0.1 defining localhost. WSL's own settings default to localhostForwarding=true

   • Astro server runs and listens to http://localhost:4321.
   • Inside WSL: curl http://localhost:4321 works.
   • On host: curl http://localhost:4321 times out (error 28)
   • On host: curl http://127.0.0.1 returns a "couldn't connect" error (error 27).

2. Stop the dev server and re-run to bind to all host addresses: pnpm run dev --host

   • Astro's dev server now listens to http://localhost:4321, http://10.255.255.254:4321, and http://<the host's LAN IP>
   • Out of these, one works from Windows: localhost:4321

So, in order for Windows to be able to connect to a server in WSL via localhost, the server needs to be listening on all addresses, not just localhost.