Cannot access http server located in Windows from WSL2

[alshdavid]

Please fill out the below information:

• Your Windows build number: (Type ver at a Windows Command Prompt)
  Microsoft Windows [Version 10.0.19041.264]

• WSL Details:
  WSL2
  Ubuntu 20.04

• What you're doing and what's happening: (Copy&paste the full set of specific command-line steps necessary to reproduce the behavior, and their output. Include screen shots if that helps demonstrate the problem.)

I am unable to access a web server located in Windows from inside WSL2.

Below I will create an http server, run it inside a Windows Command Prompt then attempt to curl it from WSL2.

I'm not familiar with an easy way to spin up an http server from Windows so I will use Go to write a tiny http server. I'm sure there is a better way, so feel free to use whatever you'd like to.

Video:

Open a powershell window

mkdir server
cd server
touch main.go

Paste the following code into main.go

package main

import (
	"fmt"
	"net/http"
)

func main() {
	http.HandleFunc("/", func(w http.ResponseWriter, req *http.Request) {
		fmt.Fprintf(w, "hello world\n")
	})
	http.ListenAndServe(":8090", nil)
}

Then in the powershell window run:

go run main.go

Accept the firewall prompt
Verify your server is working by opening Edge browser and navigating to http://localhost:8090

You can also verify it works by using curl form another Windows Command Prompt

Now open a new terminal window with WSL2 and Ubuntu 20.04

curl http://localhost:8090

We would expect to see Hello World but instead we see:

curl: (7) Failed to connect to localhost port 8090: Connection refused

** Use cases **

Puppeteer cannot be accessed from WSL
puppeteer/puppeteer#5957

[alshdavid]

For visibility, users can access the IP of the wsl host using the following line

tail -1 /etc/resolv.conf | cut -d' ' -f2

The http server must also be given access to public networks

Then running the following commands inside WSL2 will allow access to the http server.

export WSL_HOST=$(tail -1 /etc/resolv.conf | cut -d' ' -f2)
curl http://$WSL_HOST:8090

This does not solve the issue of puppeteer because Chrome would need to be granted similar firewall permissions and also is hardcoded to only accept connections from localhost

[bobvandevijver]

This direction (wsl -> windows) looks unsupported yet: I have the same issue.

[craigloewen-msft]

Since you're using WSL 2, you'll need to access your Windows networking applications using the IP of your host machine. We're investigating adding 'localhost' support to this in the future!

Instructions on how to do that are here. Let me know if that works for you!

[bobvandevijver]

@craigloewen-msft I found that page, but interestingly, /etc/resolv.conf does not contain the IP of the host machine, but a private network IP (172.21.xx.1) which doesn't respond to anything.

Using the actual IP of the machine does work, but that is something that changes all the time for me... Without a way of retrieving it from the WSL2 machine, I cannot use it consistently. For now, I downgraded to WSL1.

Edit: I'm opening a separate issue for that.

[kilork]

I was able to get response from Windows server after I did this:

New-NetFirewallRule -DisplayName "WSL" -Direction Inbound  -InterfaceAlias "vEthernet (WSL)"  -Action Allow

[alshdavid]

Since you're using WSL 2, you'll need to access your Windows networking applications using the IP of your host machine. We're investigating adding 'localhost' support to this in the future!

Instructions on how to do that are here. Let me know if that works for you!

While this does generally work as a workaround, there are certain applications which validate that the client is running on localhost - such as when trying to debug Chrome through a tool like "puppeteer"

[therealkenc]

From puppeteer/puppeteer/#2242 it looks like (?) it will accept *.localhost names which you can set up with avahi-daemon(8) or an alias in /etc/hosts. Other option is to run chromium and puppeteer in WSL with an X Server.

Localhost in the windows direction is /dupe #4619.

[ghost]

Hi! We've identified this issue as a duplicate of another one that already exists in this repository. This specific instance is being closed in favor of tracking the concern over on the referenced thread.

Thanks for your report!

[alshdavid]

avahi-daemon(8)

Sadly this will not work because Chrome does the validation. The proxy needs to live on the Windows side as the "remote client" is the address of the WSL guest.

I don't mind working around this, but I'd need to write a readme for my team to follow and I can't guarantee everyone can

[therealkenc]

Sadly this will not work

Will not or did not.

[doctorchuks]

This Microsoft page helped solve this on my end

https://docs.microsoft.com/en-us/windows/wsl/networking

Check in the "Accessing Windows networking apps from Linux (host IP)" section

[godotc]

try:

http.ListenAndServe("127.0.0.1:8090", nil)

[MiCurry]

try:

http.ListenAndServe("127.0.0.1:8090", nil)

This worked for me! Thanks!

HttpRouter was running fine on MacOS. Transfered it to WSL and the exe would just start, and then exit, without any error message. But changing it to the above worked.

[brunolm]

I ran the firewall commands, but I don't know if they did anything. What definitely worked for me was to grab the IP address from here:

tail -1 /etc/resolv.conf | cut -d' ' -f2

Is this in some documentation somewhere? I got lucky to find it in this thread...