Skip to content
#️⃣ General

Can't connect to linux localhost from Windows browser #2471

#️⃣ General
3y ago
· 25 replies

I am trying to run two localhost applications (not at the same time) in bash on Ubuntu on Windows: flask and jekyll. I'm starting the services from the bash on Windows terminal using 'jekyll serve' and 'python -m flask run'. In both cases I copy and paste the localhost address printed to the terminal (127.0.0.1:5000, and 127.0.0.1:4000, respectively) to a browser on Windows 10, and get 'This site can't be reached'.

Edit: I have installed flask on windows and am able to run and access a local server from the Windows command line as expected (but still not bash).

I have tried upgrading to the newer version of Ubuntu (uninstalled and reinstalled to go from v14 to v16) as well as creating a firewall rule for the bash.exe file on Windows Defender.

Microsoft Windows build number [Version 10.0.15063]

Replies

If you telnet to that port from within the Linux SubSystem does it connect, or fail?

telnet localhost 5000
telnet localhost 4000

Fails. I tried it in a separate window and the same window (both bash).

If it doesn't work in bash it makes me think you have a firewall restriction of some sort, can you try just blanket rule shutting the firewall off to see? Also do sudo ufw status to make sure Ubuntu isn't running a firewall.

Disabling the Windows Defender Firewalls didn't work. Trying to run 'sudo ufw status ' gave me an error:

ERROR: problem running iptables: iptables v1.6.0: can't initialize iptables table `filter': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.

Silly question, but if you do ps -ef | grep python do you see the apps running and not in a failed state? Can you check your logging to confirm it's working properly?

Perhaps the problem is simpler than we think...

'acmshar 12 2 10 07:44 tty1 00:00:00 python -m flask run'

So it appears to be running.

Hi

I am trying to get Memcached running on WSL and try to access it via the port in Windows browser.
It says Could not open port.
I am getting the same error when trying to sudo ufw status
I am also facing the same issue and python seems to be running.

Same here with a Node.js HTTP server.

winver => 15063.608

I think this is a duplicate of #1498

This is a problem that bothers me, too,Would you like to have a solution?

WSL runs via Docker like technology and has the same restrictions.
You have to point your web app inside the WSL to use the IP ‘0.0.0.0’ and then you can see the app in a browser at 127.0.0.1

@karenyyng
Best answer thus far, though it did not resolve my issue.
FLASK_APP=basic.py flask run -h 0.0.0.0 -p 12345

Simple program to test with

import flask

app = flask.Flask(__name__)


@app.route('/')
def hello_world():
    return 'Hello, World!'

Any thoughts?

I have exactly the same problem too, I'm on Windows 7.

So my Flask app runs on 0.0.0.0:5000. Using Bash on Windows, I dockerized the app and started the service from a docker-compose file. I cannot access it through Windows Chrome browser, same error message This site can't be reached.

If I run the Flask app from my IDE (IntelliJ) on Windows (outside of Bash), then I can simply access the API through Chrome on 127.0.0.1:5000/test for example.

I also disabled the firewall completely for testing purposes and it didn't solve it. I'm not sure how to tell Bash that the localhost the service is starting on, is the machine's localhost. Because I started the app through IntelliJ at the same time, using the same host and port, and it successfully started although the service in my Bash is running on the same host:port too!! How can that be possible? I would think they all refer to the same machine localhost.

Update:

I figured out what's happening and it all makes sense now. It's my first time using Docker ToolBox not knowing that it is different to Docker for Windows. So whenever I'm running services using docker in Bash, it's not using the Windows localhost despite docker-compose logs <service name> shows that service is running on 0.0.0.0:5000 it's in fact running on <docker machine ip address>:5000 in my case because I set the port to 5000.

You can grab the docker machine ip address simply by running docker-machine ip and use it as follow:
<ip>:<port> in your windows browser to access the service running by docker-compose.

This started happening to me with WSL 2 on Windows 10-18917. Never had issues before.

Edit: Downgraded to WSL 1 and it works fine. WSL 2 doesn't.

Edit2: Didn't realize support for it was dropped in WSL2. That's a deal-breaker for me.

https://docs.microsoft.com/en-us/windows/wsl/wsl2-ux-changes#accessing-network-applications

@benhillis benhillis
Maintainer

@clshortfuse - We are working on enhancing our networking story to allow connecting to services running in the guest via localhost in a future update.

Seems this support is live in build 18945, but still not working for me.
Serving Angular app inside WSL 2, works fine (wget localhost:4200 downloads index.html). While trying wget from Windows returns unable to connect. I'm running build 18950.1000. Any help / workaround would be vastly appreciated.

seems my real issue is #4353

You can fix this issue by updating your Windows hosts file.

In a shell in WSL 2 Ubuntu run $ip addr to find the VM's IP address. Then edit the Window's host file at C:\Windows\System32\drivers\etc\hosts and add the IP address and a name at the bottom of the file. For example: 111.22.333.444 wsl which will allow you to access processes serving to localhost in WSL 2 by navigating to http://wsl:{your_port_number}

wsl --shutdown helped me in Win 2004

@chicagobuss

thank you, this worked for me, too

I also have experienced this where initially I can run an api server in wsl2 and call its endpoints using postman (localhost) running in the host machine. But after some time, it just stops working and I get connection error. But after running wsl --shutdown, and restarting wsl2, it works again. A fix would be much better than this workaround

@jsoriao, I appreciate hearing about your workaround, it works for me; WSL2 has one annoyance that may have roots in Docker WSL2 integration: mapping kubernetes to 127.0.0.1 in the Windows hosts file, then that same mapping is transferred to /etc/hosts in BASH. I believe you can turn off the sync between BASH and Windows HOSTS static mappings with a change to /etc/wsl.conf noted in the hosts file headers. Perhaps this is the way to prevent Docker from closing connections on 127.0.0.1? I don't use Docker extensively so not sure. I would check out "Network", "Proxy" and "WSL Integration" settings under Resources in Docker Dashboard, they seem to impact when Windows stops being able to connect to BASH on 127.0.0.1.

You can fix this issue by updating your Windows hosts file.

In a shell in WSL 2 Ubuntu run $ip addr to find the VM's IP address. Then edit the Window's host file at C:\Windows\System32\drivers\etc\hosts and add the IP address and a name at the bottom of the file. For example: 111.22.333.444 wsl which will allow you to access processes serving to localhost in WSL 2 by navigating to http://wsl:{your_port_number}

problem for me is that the IPv4 address seems to be "dynamic" between restarts of WSL2, so entering it in a static HOSTS file is a bit like the dog chasing its tail. I'd rather track down what causes the CONNECTION_REFUSED in my windows browser. I am pretty sure it is sporadic on one particular 2004 instance, on a different one, I have never had this problem, although pretty much the same basic configuration: Docker, WSL2, nginx within WSL2 as a proxy, attaching to :80 on the BASH host (nginx proxying a Django Web App).

hi I have a problem that when I want to use vscode to connect WSL2,there is something wrong /root/.vscode-server/bin/93c2f0fbf16c5a4b10e4d5f89737d9c2c25488a3/server.sh: line 12: /root/.vscode-server/bin/93c2f0fbf16c5a4b10e4d5f89737d9c2c25488a3/node: not found
what can I do to fix it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Converted from issue
Beta
You can’t perform that action at this time.