localhost:PORT from windows host no longer gets handled by process running in WSL2

[mwidmann]

Version

Microsoft Windows [Version 10.0.25169.1000]

WSL Version

• WSL 2
• WSL 1

Kernel Version

5.15.57.1

Distro Version

Ubuntu 20.04

Other Software

No response

Repro Steps

• update WSL to the newest insider store version
• spin up any kind of server inside WSL (tried with node applications running on Port 3000, 4400, 8080 and a mysql instance running on docker on port 3306)
• try to access the exposed service from f.e. Edge by running http://localhost:3000

Expected Behavior

Whatever is running on localhost:3000 in WSL is getting delivered to the Browser requesting it.

Actual Behavior

Edge get's an ERR_CONNECTION_REFUSED error.

Accessing through the IP address of eth0 with the port works. So f.e. http://localhost:3000 or http://127.0.0.1:3000 fail, but http://172.25.170.221:3000 works.

This worked until this morning when I updated to the latest version (0.65.1) in the store.

Diagnostic Logs

No response

[benhillis]

Thanks for reporting. @pmartincic could you please take a look?

[mickdewald]

Maybe this has something do with that:
I cannot reach my Kubernetes cluster build with KinD anymore.
I also tested the Kubernetes cluster from Docker Desktop

Suddenly, I got (for Docker Desktop)
The connection to the server kubernetes.docker.internal:6443 was refused - did you specify the right host or port?
or for the KinD cluster
The connection to the server 127.0.0.1:30000 was refused - did you specify the right host or port?

It worked perfectly for months. The only thing changed was a Windows Update with update of WSL to 0.65.1

❯ wsl --version
WSL version: 0.65.1.0
Kernel version: 5.15.57.1
WSLg version: 1.0.41
MSRDC version: 1.2.3213
Direct3D version: 1.601.0
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22622.450

[olivierchatry]

Same here, minikube cannot ssh to it container anymore.
I can SSH to it from a "normal" windows prompt, but not from WSL linux distro.
Happen since the last update I got this morning :

WSL version: 0.65.1.0
Kernel version: 5.15.57.1
WSLg version: 1.0.41
MSRDC version: 1.2.3213
Direct3D version: 1.601.0
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22622.450

[ghost]

/logs

[ghost]

Hello! Could you please provide more logs to help us better diagnose your issue?

To collect WSL logs, download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The scipt will output the path of the log file once done.

Once completed please upload the output files to this Github issue.

Click here for more info on logging

Thank you!

[benhillis]

Are you guys by chance using a private kernel? Could you share the output of cat /proc/version?

[mickdewald]

❯ cat /proc/version
Linux version 5.15.57.1-microsoft-standard-WSL2 (oe-user@oe-host) (x86_64-msft-linux-gcc (GCC) 9.3.0, GNU ld (GNU Binutils) 2.34.0.20200220) #1 SMP Wed Jul 27 02:20:31 UTC 2022

Are you guys by chance using a private kernel? Could you share the output of cat /proc/version?

I use the default Ubuntu 20.04 image

I will provide logs later, when I am home

[felpasl]

uninstalling 10.0.22622.450 on Windows Update>Update history>Uninstall updates doesn't fix remain the message

The connection to the server kubernetes.docker.internal:6443 was refused - did you specify the right host or port?

I'm trying to find an option to downgrade wsl back to [0.64.0]

Versão do WSL: 0.65.1.0
Versão do kernel: 5.15.57.1
Versão do WSLg: 1.0.41
Versão do MSRDC: 1.2.3213
Versão do Direct3D: 1.601.0
Versão do DXCore: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows versão: 10.0.22622.440

WslLogs-2022-08-03_16-15-51.zip

on WSL Ubuntu:

• telnet kubernetes.docker.internal 6443 doesn't work,
• name resolution returns 127.0.0.1

on Windows Host:

• port 6443 is listening in windows
• kubectl on powershell works.

[NotTheDr01ds]

Just an additional data point that I am not able to reproduce after installing 0.65.1 on Windows 11 non-Insider (10.0.22000.795). I installed from the Releases page using Add-AppxPackage in an Administrative PowerShell:

I can now reproduce in Windows 11 GA with 0.65.1 based on @mwidmann's updated description.

$ $env:WSL_UTF8=1
$ wsl --status | clip.exe

Default Distribution: Ubuntu-22.04
Default Version: 2
WSL version: 0.65.1.0
Kernel version: 5.15.57.1
WSLg version: 1.0.41
MSRDC version: 1.2.3213
Direct3D version: 1.601.0
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22000.795

In Ubuntu 22.04:

python3 -m http.server

And can browse in Edge to localhost:8000 and view the directory contents. Also tried with port 3000, which worked as well.

So perhaps it's something else in Insider causing the issue rather than the WSL update? Or perhaps an interaction between the two.

[felpasl]

I'm using Insider back to 22622.450, the connection from windows to localhost:80 hosted in kubernetes WSL2 "Docker Desktop" worked.

from WSL2 Ubuntu docker ps worked

from WSL2 Ubuntu kubectl get namespaces doesn't work

from windows Powershell kubectl get namespaces worked

i'm trying to export my wsl Ubuntu distro, to uninstall wsl from windows, and try reinstall wsl without the Preview, in last scenario start work again in windows powershell until solution or work around was found 😥

[mickdewald]

I'm using Insider back to 22622.450, the connection from windows to localhost:80 hosted in kubernetes WSL2 "Docker Desktop" worked.

from WSL2 Ubuntu docker ps worked

from WSL2 Ubuntu kubectl get namespaces doesn't work

from windows Powershell kubectl get namespaces worked

i'm trying to export my wsl Ubuntu distro, to uninstall wsl from windows, and try reinstall wsl without the Preview, in last scenario start work again in windows powershell until solution or work around was found 😥

I can confirm the same behavior.
I can also add, that I installed a new WSL distro Ubuntu 18.04 and got the same behavior with the freshly installed distro.

[ghost]

Ahhhh, this helps. I read the original bug description as saying that localhost:port was inaccessible from the windows host.

I'm using Insider back to 22622.450, the connection from windows to localhost:80 hosted in kubernetes WSL2 "Docker Desktop" worked.

from WSL2 Ubuntu docker ps worked

from WSL2 Ubuntu kubectl get namespaces doesn't work

from windows Powershell kubectl get namespaces worked

i'm trying to export my wsl Ubuntu distro, to uninstall wsl from windows, and try reinstall wsl without the Preview, in last scenario start work again in windows powershell until solution or work around was found 😥

[DmytryEmery]

I'm trying to find an option to downgrade wsl back to [0.64.0]

Any luck on this?
[0.65.1] has broken Kind cluster.

Everything (docker desktop, kind) latest version, but since yesterday when this got updated it doesn't work, even with clean install.

Just as a work around: just using docker destop without WSL engine, everything still works.

[benhillis]

@DmytryEmery - I'd suggest downloading a previous release from the github releases page.

[DmytryEmery]

@benhillis thanks!
just to confirm reverting to 0.64.0 resolved the issue for me

[benhillis]

While debugging this locally we have pushed https://github.com/microsoft/WSL/releases/tag/0.65.2 which will revert to the previous behavior.

[mwidmann]

Sadly the update was installed before I could get the logs, but I can confirm that with this version, the described issues are gone.

I have to revert this. While the first couple of requests worked fine, it is back to ERR_CONNECTION_REFUSED now.

Tried on ports 8080 and 4400. localhost and 127.0.0.1 don't work. The IP Address eth0 has in ubuntu instance can be used to connect.

I ran the collect-wsl-logs.ps1 command and have the following logs. Hope those help to identify the issue.
WslLogs-2022-08-04_08-02-22.zip

BTW, the machine is already updated to the latest DEV Insider build Microsoft Windows [Version 10.0.25174.1000]

This is what wsl --version outputs:

WSL-Version: 0.65.2.0
Kernelversion: 5.15.57.1
WSLg-Version: 1.0.41
MSRDC-Version: 1.2.3213
Direct3D-Version: 1.601.0
DXCore-Version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows Version: 10.0.25174.1000

and this is the output of cat /proc/version inside my Ubuntu installation:

Linux version 5.15.57.1-microsoft-standard-WSL2 (oe-user@oe-host) (x86_64-msft-linux-gcc (GCC) 9.3.0, GNU ld (GNU Binutils) 2.34.0.20200220) #1 SMP Wed Jul 27 02:20:31 UTC 2022

[Tychoblood]

@benhillis thanks! just to confirm reverting to 0.64.0 resolved the issue for me

Can you explain how you did it ? Downloaded the packages and launched the installer but it wouldn't finish.
Tried in Powershell via this command : Add-AppPackage -path "C:\Users\xxxxxx\Downloads\Microsoft.WSL_0.64.0.0_x64_ARM64.msixbundle"
but to no avail. It states that the superior version is already installed and so cant downgrade...

Having the same problem after this night update , and of course the day it is most needed (merge and review for client project release...)

Sadly the update was installed before I could get the logs, but I can confirm that with this version, the described issues are gone.

I have to revert this. While the first couple of requests worked fine, it is back to ERR_CONNECTION_REFUSED now.

Tried on ports 8080 and 4400. localhost and 127.0.0.1 don't work. The IP Address eth0 has in ubuntu instance can be used to connect.

I ran the collect-wsl-logs.ps1 command and have the following logs. Hope those help to identify the issue. WslLogs-2022-08-04_08-02-22.zip

BTW, the machine is already updated to the latest DEV Insider build Microsoft Windows [Version 10.0.25174.1000]

This is what wsl --version outputs:

WSL-Version: 0.65.2.0
Kernelversion: 5.15.57.1
WSLg-Version: 1.0.41
MSRDC-Version: 1.2.3213
Direct3D-Version: 1.601.0
DXCore-Version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows Version: 10.0.25174.1000

and this is the output of cat /proc/version inside my Ubuntu installation:

Linux version 5.15.57.1-microsoft-standard-WSL2 (oe-user@oe-host) (x86_64-msft-linux-gcc (GCC) 9.3.0, GNU ld (GNU Binutils) 2.34.0.20200220) #1 SMP Wed Jul 27 02:20:31 UTC 2022

I have the exact same problem, it works for a few http/https requests and then back to ERR_CONNECTION_REFUSED afterwards

[mwidmann]

@benhillis thanks! just to confirm reverting to 0.64.0 resolved the issue for me

Can you explain how you did it ? Downloaded the packages and launched the installer but it wouldn't finish. Tried in Powershell via this command : Add-AppPackage -path "C:\Users\xxxxxx\Downloads\Microsoft.WSL_0.64.0.0_x64_ARM64.msixbundle" but to no avail. It states that the superior version is already installed and so cant downgrade...

Having the same problem after this night update , and of course the day it is most needed (merge and review for client project release...)

The update was just offered to me through the Windows Store. That's why it was faster than my logs gathering.

[mwidmann]

This is getting stranger and stranger. It appears that the problems start when a second port is opened with the same process. Running one node process on port 8080 works, starting a second one on port 4400 produces the ERR_CONNECTION_REFUSED. Same with the simple python webserver. Running python3 -m http.server works, but starting a second instance python3 -m http.server 8080 breaks both.

Here's a new set of logs...
WslLogs-2022-08-04_08-50-11.zip

[olivierchatry]

Still the same issue with minikube using 0.65.2. Forcing downgrade to 0.64.0 fixed the issue. Sidenote, to downgrade: 1. download the package from github https://github.com/microsoft/WSL/releases/download/0.64.0/Microsoft.WSL_0.64.0.0_x64_ARM64.msixbundle 2. Open a powershell prompt 3. On the prompt, navigate to folder in which you downloaded the file 4. then type ( or copy paste ) : Add-AppxPackage -Path .\Microsoft.WSL_0.64.0.0_x64_ARM64.msixbundle -ForceUpdateFromAnyVersion -ForceApplicationShutdown

[hf35]

Have the same issue with opening localhost and 127.0.0.1 on diffrent ports. It can work with localhost:3000, but doesn't work on localhost:3020 or vise versa. Both 0.65.1 and 0.65.2 have this issue.

Downgrade to 0.64.0 is fixed problem

Added logs (while launched server and tryed to get it from Windows)
WslLogs-2022-08-04_13-39-38.zip

[hf35]

One more thing
react application doesn't work on localhost:3000, but "nc -l 3000" - worked correctly on localhost:3000

[Tychoblood]

Still the same issue with minikube using 0.65.2. Forcing downgrade to 0.64.0 fixed the issue. Sidenote, to downgrade, download the package from github then, on a powershell prompt : powershell Add-AppxPackage -Path .\Microsoft.WSL_0.64.0.0_x64_ARM64.msixbundle -ForceUpdateFromAnyVersion -ForceApplicationShutdown

I can confirm this work, I was just missing the ForceUpdate part.
Downgrading to 0.64.0 also fixed the issue , whereas the 0.65.2 would work for a few requests and then no more, with ERR_CONNECTION_REFUSED http status.

[zed76r]

0.65.2 not work for me

[felpasl]

0.65.2 doesn't work, thx @olivierchatry, reverting is an solution, but an --upgrade "version" or some type of downgrade procedure in docs will be easy.

[mickdewald]

Another thing I noticed is that my computer freezes now regularly when I do wsl --shutdown. This never happened before in previous versions. It's a complete freeze and I can't do anything. Have to unplug the A/C connector.

EDIT:
I also downgraded to 0.64 and everything works again. Kubernetes in WSL is reachable again. No sudden connection lost with react apps and no freeze during WSL --shutdown

[hf35]

Another thing I noticed is that my computer freezes now regularly when I do wsl --shutdown. This never happened before in previous versions. It's a complete freeze and I can't do anything. Have to unplug the A/C connector.

EDIT: I also downgraded to 0.64 and everything works again. Kubernetes in WSL is reachable again. No sudden connection lost with react apps and no freeze during WSL --shutdown

Btw, i had the same complete freezes after "WSL --shutdown" on 0.65...

[benhillis]

Taking another look, the revert should have fixed the issue...

[benhillis]

@hf35 - I'll try to repro locally, but it looks like 0.65.2 may not have the full revert. Taking a look.

[benhillis]

Ok I sorted this out, I tagged the wrong commit. Pushing a new build (0.65.3) here shortly.

[benhillis]

@hf35 - coudl you please file a new bug for that issue? I suspect this is vgpu related.

[benhillis]

https://github.com/microsoft/WSL/releases/tag/0.65.3

[swichers]

@benhillis Should we be seeing 0.65.3 as an update for insiders at this point, or is that for manual install?

[zed76r]

@benhillis Should we be seeing 0.65.3 as an update for insiders at this point, or is that for manual install?

[hf35]

@benhillis everyhing is ok on 0.65.3 with localhost

@hf35 - coudl you please file a new bug for that issue? I suspect this is vgpu related.

About freezes? I am not sure, how i can save log, because after shutdown command - my pc is completly freeze and and can't press button to collect logs

[nunix]

I went through podman/docker desktop/rancher desktop/k3d/kind with 0.65.3 and as far as I can tell, it's fixed now.

Thank you @benhillis and team for the fast fix, really appreciated

[mickdewald]

I haven't tested it myself yet with the new version but I can only say also thanks especially for the extremely fast response time and fixes. Very much appreciated.

[benhillis]

Thanks everyone for the kind words, we're working on a fix here because the new localhost behavior is really neat (minus this bug).

@hf35 - please file a new issue, that is unrelated.

[Ankit1598]

I downgraded wsl, rolledback windows update, tried all the combinations possible but nothing works, when I run any of my WebApp (React, Next, Nuxt, etc) and try to access https://localhost:3000, I keep getting ERR_CONNECTION_RESET

WSL Versions tried: 0.65.3, 0.64.0, 0.61.8

$ ver
Microsoft Windows [Version 10.0.25169.1000]

$ wsl.exe --status
Default Distribution: Ubuntu-20.04
Default Version: 2
WSL version: 0.65.3.0
Kernel version: 5.15.57.1
WSLg version: 1.0.41
MSRDC version: 1.2.3213
Direct3D version: 1.601.0
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.25169.1000

[onomatopellan]

@Ankit1598 Make sure you are not hitting #5575

[olivierchatry]

I'm quite sure it is unrelated to this issue. Maybe you should try to use http instead of https ?

[filippomc]

The same issue appears on wsl 1.1.0 (now installed by default on insider previews). Downgrading to 1.0.3 fixed for me

[olivierchatry]

Yup, same for me.

[forberg]

Same with WSL 1.1.0 for me. Works if i downgrade to 1.0.3. Maybe create a new issue? Seems to be some localhost related updates in 1.1.0: https://github.com/microsoft/WSL/releases/tag/1.1.0

Updated issue here: #9508

[ghost]

Back from the dead!

Sorry for the inconvenience. This issue you're experiencing in 1.1.0 is currently being worked on and tracked at #9508 This issue, 8679, tracked other problems with the relay.

[felpasl]

same behavior again, downgraded from 1.1.2 to 1.0.3 and worked:

Add-AppxPackage -Path .\Microsoft.WSL_1.0.3.0_x64_ARM64.msixbundle -ForceUpdateFromAnyVersion -ForceApplicationShutdown

[Persedes]

Popped up for the first time up after upgrading to 1.1.3:

wsl --version
WSL version: 1.1.3.0
Kernel version: 5.15.90.1
WSLg version: 1.0.49
MSRDC version: 1.2.3770
Direct3D version: 1.608.2-61064218
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22000.1574

[ghost]

@Persedes, I just realized that this bug was tracking code that was reverted. Could you open a new bug and post logs? Thanks!

I'm going to lock this thread to direct people elsewhere.