Unable to connect to local server started in WSL 2 from windows host machine

[PritamSangani]

Please use the following bug reporting template to help produce issues which are actionable and reproducible, including all command-line steps necessary to induce the failure condition. Please fill out all the fields! Issues with missing or incomplete issue templates will be closed.

If you have a feature request, please post to the UserVoice.

If this is a console issue (a problem with layout, rendering, colors, etc.), please post to the console issue tracker.

Important: Do not open GitHub issues for Windows crashes (BSODs) or security issues. Please direct all Windows crashes and security issues to secure@microsoft.com. Ideally, please configure your machine to capture minidumps, repro the issue, and send the minidump from "C:\Windows\minidump".

Please fill out the below information:

• Your Windows build number: (Type ver at a Windows Command Prompt)
  10.0.18922.1000

• 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.)

• What's wrong / what should be happening instead:
  I am unable to connect to my node server (started with firebase serve in my WSL 2 Ubuntu distro). I understand that localhost can not be reached from windows for wsl 2 server yet. Therefore, I followed the instructions as shown in this Microsoft blog post. However, I am still not able to connect to my server. I also added a rule to my firewall rules to allow connections to any port for my WSL 2 ip address.

• Strace of the failing command, if applicable: (If some_command is failing, then run strace -o some_command.strace -f some_command some_args, and link the contents of some_command.strace in a gist here).

• For WSL launch issues, please collect detailed logs.

See our contributing instructions for assistance.

[ghost]

We’ve labelled your issue as ‘need-repro’ since we need more steps to help identify your problem. Could you please provide us with reproducible steps for the issue you’re experiencing, including things such as the specific command line steps necessary to reproduce the behavior and their output. Thank you! -The WSL Team

[craigloewen-msft]

Can you please provide the command line steps that you're running when experiencing this issue? I'm not able to reproduce it.

My guess is that your app is not accepting connections from anything but localhost. Please see issue #4136 for an example of what to change.

[edwindijas]

You can try a work around, to port forward your services to your ip address.
Check link below.

#4150

[tuananh]

Unable to connect in build 18963 / WSL 2. Not sure if this because of this build or not.

[chenjianxin]

Unable to connect in build 18963 / WSL 2. Not sure if this because of this build or not.

Me too!!

[craigloewen-msft]

@tuananh and @chenjianxin this could be due to which address the application is bound to. Please bind to 0.0.0.0 in this build. For example in Flask this would be done with: app.run(host='0.0.0.0')

More details (and where we are tracking this issue) are here: #4353 (comment)

[tuananh]

@tuananh and @chenjianxin this could be due to which address the application is bound to. Please bind to 0.0.0.0 in this build. For example in Flask this would be done with: app.run(host='0.0.0.0')

More details (and where we are tracking this issue) are here: #4353 (comment)

it's jekyll in my case. lemme try it later today

[tuananh]

@tuananh and @chenjianxin this could be due to which address the application is bound to. Please bind to 0.0.0.0 in this build. For example in Flask this would be done with: app.run(host='0.0.0.0')

More details (and where we are tracking this issue) are here: #4353 (comment)

it works.

for jekyll i use jekyll serve --host=0.0.0.0 and i can access it

[cmeiklejohn]

I'm running into a similar problem with build 18990.vb_release.190921-1704.

I have -- for about 2 years with WSL 1 -- run Docker in Windows and enabled the "listen for connections on tcp://localhost:2375 without SSL" option. This allowed me to, from WSL, connect to the Docker daemon running in Windows. While I can connect to localhost on port 2375 from Windows, from within WSL, I can no longer connect to 2375 on localhost -- connection refused. This only happens when running in WSL 2.

[craigloewen-msft]

@cmeiklejohn this is because as of right now when connecting to the Windows host you need to use the IP address of the host. More details here on our docs page.

And as for your scenario, I'd recommend looking into the docker tech preview that uses WSL 2 as this might simplify your setup.

[cmeiklejohn]

@craigloewen-msft I ended up switching to the new version of Docker with the WSL2 preview. Now, I can use the socket instead of tcp to communicate with Docker from inside of WSL. This is great, however, I'm running into problems arising because of #4166.

For instance, building containers uses up all available virtual memory; from there, I need to wsl --shutdown to reclaim the memory to keep working. However, this causes the Docker Tech Preview to report Docker as "failed" and it can't be restarted without a reboot and then manually starting the WSL2 docker backend.

[craigloewen-msft]

@cmeiklejohn a fix is on the way for #4166 , we will ping that thread when it arrives to Windows Insiders so make sure to stay subscribed there for any news! :)

[cmeiklejohn]

@craigloewen-msft thanks for all of the help!

[seandearnaley]

I got this working: so apparently there was some confusion about these posts regarding the linux file system, I was creating my project in the ubuntu terminal under /mnt/c/Users/seand , thinking this was the linux file system, but actually it seems that is some kind of virtualized service.... if I go to /home, and create a project my personal folder, it works great.... I guess it's the difference between windows file system and linux file system and it's new to WSL 2. The performance difference is dramatic also.

I've been writing about WSL 2 on my medium blog, I've added the notes there: https://medium.com/swlh/wsl-2-docker-edge-tech-preview-native-linux-containers-w-o-emulation-b41667e6dbef

[chuck-confluent]

I am running a flask app in WSL2 and am not able to connect to it via chrome on the windows 10 host. I bound to 0.0.0.0 and it still didn't work.

For sanity, I also ran sudo nc -l 80 and made an http request on port 80 to localhost from windows and did not see the request reach nc

Microsoft Windows [Version 10.0.19041.172]

[mickdewald]

wsl --shutdown helped me in Win 2004

[slavo]

wsl --shutdown helped me in Win 2004

Thank you! I've had the connectivity problems despite latest builds and setting up forwarding and everything. It seems this was the only thing which fixed the issue.

For what it's worth, I created by distro (Ubuntu) before I upgraded to WSL2, then converted it to WSL2 and noticed problems. After shutting down all seems to be fine and Flask apps run again.

[mickdewald]

wsl --shutdown helped me in Win 2004

Thank you! I've had the connectivity problems despite latest builds and setting up forwarding and everything. It seems this was the only thing which fixed the issue.

For what it's worth, I created by distro (Ubuntu) before I upgraded to WSL2, then converted it to WSL2 and noticed problems. After shutting down all seems to be fine and Flask apps run again.

I had connection problems with both approaches. I did the same as you did with the converting from WSL 1 to 2 but the problems where also there with a newly created WSL 2 image.

[bakszero]

wsl --shutdown helped me in Win 2004

Thanks! Can confirm it helps in Win 2004!

[widersky]

wsl --shutdown helped me in Win 2004

Doesn't work for me...

[ardhitama]

This also happen recently for my nginx http proxy, used to be working before upgrading to 20H2 (19042.330).

wsl --shutdown solved it

[ecometer]

It worked in Win 2004! Thanks

[gembancud]

Hi, im developing a flask app that's served in WSL2 to utilize websocketing, a client from windows then connects to it using localhost. wsl --shutdown is the workaround I have when the server collapses due to the connections closing. Restarting wsl seems to be the only fix. Its a band-aid fix and I'm trying to persist the server. Are there any other fixes for this?

Edit: Reproducing the bug is also sporadic, but succumbs to eventual Murphys law

[AlexMenor]

Also experiencing this. Any permanent fix so far? wsl --shutdown works for me too.

[boburxon]

Also experienced this. This problem occurs randomly and I can not reproduce it on purpose. But wsl --shutdown works for me.

[eromoe]

How do I make wsl be able to connect particular service/port on host ?
Now I have to shutdown firewall to make it pass .

[acmoles]

Also experienced this and found wsl --shutdown in Command Prompt fixed the issue.

Some ports from wsl were working, some not.

Working:
Docker
Postgres

Not:
Node
Visual Studio Code

[cbnsndwch]

welp, wsl --shutdown fixed it for me as well. Really a band-aid, though.

[sclowbird]

I have exactly the same problem. Only solution is a WSL restart. Windows version 20H2

[mateusz-owczarek]

Same here, wsl --shutdown.

[aaronamm]

Same to me, only wsl --shutdown works. Windows version 21H1 (10.0.19043.1055)

[nycynik]

As everyone else said, wsl --shutdown works, and then it will immediately prompt you to restart - click restart, and then you are good to go again.

Just for the record, above it says to "change your launch config from localhost to 0.0.0.0" - that was not my issue, it was just that I had to restart.

[NgxDev]

wsl --shutdown not working for me (WSL2 / Win 21H2).
As @nycynik said. it will immediately prompt to restart Docker backend. No matter if I restart it or not, I still can't access localhost:4200.
If I try serving the app on another port (say 3000 or 4000 - ng serve --port 3000) then it works, I can access the app. But I haven't done anything to block 4200, not sure why it's not working (and I've also randomly tried 4201, 4202 - also not working... not sure why ports with 42xx aren't working).

P. S. I'm not running inside a Docker container or anything. I just have a web app under the WSL file system which is served (by default) on port 4200. If I try serving the app on random ports, not sure why some ports work (randomly tried 3000, 4280) while other ports don't work (4200, 4201, 4202).

EDIT: Found this post: https://hungyi.net/posts/wsl2-reserved-ports/ saying that some dynamic port ranges are "aggresively reserved by Hyper-V" (WHY? 😭)
Indeed, running netsh int ipv4 show excludedportrange protocol=tcp (in a Windows shell - like Command Prompt, NOT in WSL2/Ubuntu) gave me this output:

Protocol tcp Port Exclusion Ranges

Start Port    End Port
----------    --------
      3916        4015
      4016        4115
      4116        4215
     50000       50059     *

* - Administered port exclusions.

So, in my case port 4200 is within the reserved range [4116 - 4215].

[fjeddy]

Why would you close this @PritamSangani ? A workaround is not a fix.

[Balaji2810]

I solved this by port forwarding.

on WSL 2 run the following commands

ifconfig
this will show your ip address. (my ip address in WSL 2 was 172.23.18.82 )

uvicorn app.main:app --host 0.0.0.0 --port 8000 --reload
this will run my fastapi server in port 8000

on windows run the following command as Administrator

netsh interface portproxy add v4tov4 listenport=8000 listenaddress=0.0.0.0 connectport=8000 connectaddress=172.23.18.82
this will do the magic.

now I'm able to access this service from any device which are connected to the same network

note : you need to use your windows local ip address (you can use ipconfig cmd) while connecting from other devices.

[ireznik]

@Balaji2810 thx for your comment. It helped me to find the actual ip of the wsl instance to connecto to the websocket

[mindplay-dk]

I just got hit by this - I was lucky enough to find this thread, and wsl --shutdown helped.

Mine was a completely trivial node JS example:

import http from "http";

http.createServer(function (req, res) {
  res.writeHead(200, {'Content-Type': 'text/plain'});
  res.write('Hello World!');
  res.end();
}).listen({ port: 8080, host: "0.0.0.0" }, () => { console.log("server up") });

I saw the "server up" message, but there was nothing on localhost:8080.

This is a recently-upgraded WSL1 to WSL2 installation - Node version 14.4.0 on Ubuntu 16.04.7 LTS, if that helps with a repro.

If this is something that happens at random, perhaps this issue should be reopened?

EDIT: I don't understand how or why the wsl --shutdown command would permanently help? But it does appear to. It wasn't working last night, when I shut down the computer - and it wasn't working after a fresh boot this morning. But after the wsl --shutdown command and a reboot, it's still working now. Perhaps WSL doesn't shut down properly when you shut down Windows? I mean, why would wsl --shutdown do something very different (with persistent effects) from merely shutting down Windows? 🤨

[kpost]

This randomly pops up for me, but enough to be annoying as hell. Like 70/80% of the time. wsl --shutdown helps, but is a pain in the butt, especially when I have multiple tabs open in terminal, Docker running and VS Code in remote. Which is all the time.

No upgade from wsl1, have this issue since I moved over to WSL2 from linux about a year ago. Other than this, the experience is good, but this needs to be fixed!

[cip8]

I have the same problem, it happens randomly and wsl --shutdown is only a temporary fix.
I love working with Ubuntu in WSL2, but this really needs to be addressed - shutting down WSL and restarting Docker, VSCode, etc is really painful!

[yujin-wu]

Literally switching to mac because of this.

[filipe-costa]

I am currently having an issue where I have an application running within WSL2 using Websockets, and I am unable to connect to it using an application like Postman to connect to it. However, it works via the browser, and I can reach any other endpoint I might have that doesn't use WebSockets.

None of the solutions above has worked.

Do I need to set any special permissions - i.e. firewall - for this to work flawlessly?

You can use the following repository:

https://github.com/filipe-costa/repro-demo-wsl2-websockets

Open Postman or any other postman-like application. Use "ws://localhost:3000/" and get:

" Error: connect ECONNREFUSED 127.0.0.1:3000".

I have raised this matter with the Postman team, just in case.

[mindplay-dk]

Could someone please reopen this issue? It's clearly unresolved.

[m-salman-afzal]

For anyone,
My issue was server was started on ipv6 which was unable to listen. You can use sudo lsof -i -P -n | grep LISTEN to check if your port is ipv6 or ipv4. If ipv6, then try putting 0.0.0.0 after port. The issue for connection refused will be solved.

BUT, you might get a new error socket hang up. Now, this will be because you are using socket.io library and going through the documentation, it seems like it expects socket.io-client, its own library for proper handshake to establish a connection. So, we might not be able to do it from postman at all.

What you can try is using the base ws library which is barebone of websockets (upon which socket.io runs). I was able to establish a connection through it. But being barebone, you will have to do everything yourself if you go down this road.