7

I got the err_connection_refused when trying to accessing django running on wsl2 (http://localhost:8000) from Windows but when I use curl http://localhost:8000 from Windows terminal bash, it's working fine. I have tried to add a new firewall inbound rule for port 8000 but it's still not working. Is there anything else I need to take care of.

django server started

browser is not working

curl directly not working

bash curl is working

Thanks a lot

Nguyen Pham
  • 444
  • 1
  • 4
  • 14

1 Answers1

18

Seems like a forwarding problem. WSL2's interface is NAT'd, whereas WSL1 was bridged by default. WSL seems to do some "auto-forwarding" of ports, but only on localhost. However, sometimes this auto-forwarding mechanism seems to "break down". The main culprit seems to be hibernation or Windows Fast Startup (which are both closely-related features).

  • Does the problem resolve if you do a wsl --shutdown and then restart the WSL2 session? If so, try disabling Windows' Fast Startup. I already had Fast Startup disabled due to a different (non-WSL issue) on my system, so that could be related to why I am not able to reproduce.

  • Along the same lines, do you Hibernate instead of powering off? In that case, a wsl --shutdown might resolve as well.

For future readers, note that the above two points seem to resolve the issue for most people who have upvoted and responded in the comments. However, if that does not work for you, the following were my original "additional suggestions":

  • For some additional ideas, see this github issue. There are some suggestions on services that might be needed. (Side question - Are you running Windows Home or Professional?)

  • Is there any chance that your Windows hosts file (e.g. c:\windows\system32\drivers\etc\hosts) points localhost to an IP other than 127.0.0.1? If I attempt to access via my local Windows IP address, rather than 127.0.0.1 or localhost, I get an ERR_CONNECTION_REFUSED as well.

  • Since you were looking at the firewall rules, maybe look at a forwarding rule instead of just an inbound allow?

  • If all else fails, try exporting/backing up the WSL2 session (see wsl --export), then import it in as a new WSL1 session. See if it works there.

On my WSL2/Ubuntu 20.04 system, I attempted to reproduce (but haven't been able to yet) with the following steps:

mkdir -p ~/src/dj-test
cd ~/src/dj-test
python3 -m venv dj
source dj/bin/activate
pip install Django
django-admin startproject config .
python manage.py runserver

(although I used activate.fish since I'm running the fish shell)

From Vivaldi web browser in Windows, accessed localhost:8000, which returned "The install worked successfully! Congratulations! ..."

curl under Powershell Core worked as well.

NotTheDr01ds
  • 15,620
  • 5
  • 44
  • 70
  • 1
    Thanks for your answer. I think the shutdown is the things to go. I haven't tried it but I restarted my computer and the firewall inbound rule for port 8000 is working fine now. – Nguyen Pham Aug 18 '20 at 01:46
  • I am facing the same issue. The `wsl --shutdown` and restart works. I'll give a try disabling `windows fast startup` like u said – Guilherme Jan 04 '21 at 14:05
  • `wsl --shutdown` + disable `windows fast startup` + restart worked – MartinJH Feb 09 '21 at 07:34
  • Good to hear it worked for you. I will also say that although I wasn't able to reproduce the problem at the time I wrote up the answer, I've seen it at least once (maybe twice) since then (even with Fast Startup disabled). A `wsl --shutdown` resolved it for me as well, of course. There definitely seems to be some corner-case where WSL "loses" the ability to auto-map localhost port forwarding, but I'm not sure what triggers it. – NotTheDr01ds Feb 09 '21 at 14:24
  • I *think* the "Fast Startup" just gets in the way of a normal Windows reboot fixing it. If you have Fast Startup disabled, then you can reboot Windows and it should resolve. If Fast Startup is enabled, then the problem persists across the reboot, and a `wsl --shutdown` is required. – NotTheDr01ds Feb 09 '21 at 14:26
  • FYI: `wsl --shutdown` did not help at my side **until I ran it as administrator**. Note that as ordinary user, WSL is indeed shut down, but it does not resolve the localhost problem. – Tino Aug 24 '22 at 19:48