After upgrade from 1.2.5 to 2.0.9 and Debian 11 to 12, https://localhost from Windows to WSL is not working anymore

[lfiorini]

Windows Version

Microsoft Windows [Version 10.0.22631.2715]

WSL Version

WSL version: 2.0.9.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

Kernel version: 5.15.133.1-1

Distro Version

Debian 12

Other Software

No response

Repro Steps

start wsl
open browser to http://localhost WORKS
open browser to https://localhost HANGS for 10-20 secs then reports "This site can’t be reached.. The connection was reset."
curl https://localhost
curl: (35) Recv failure: Connection was reset

In wsl curl https://localhost works and openssl s_client localhost:443 work as expected. I've tried to disable Windows Firewall,

Expected Behavior

Everything worked with 1.2.5 and Debian 11. I only changed in apt/sources.list from bullseye to bookworm and everything in wsl works as expected. I did this because I've just upgraded my development stack to the new .NET 8.0 and I wanted an updated environment.

Actual Behavior

https://localhost from Windows to wsl hangs and fails
WslLogs-2023-11-14_20-52-30.zip

Diagnostic Logs

No response

[github-actions]

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you!

Open similar issues:

• Unable to access WSL2 localhost on Windows Host Browser (#8691), similarity score: 0.78
• Unable to connect to HTTP urls in WSL2; but HTTPS works (#6166), similarity score: 0.78

Closed similar issues:

• WSL2 not connect to http://localhost (#4773), similarity score: 0.80
• Windows 11 22H2 WSL error - Windows cannot access \wsl.localhost (#8983), similarity score: 0.79
• localhost doesn't work on WSL2 (#6482), similarity score: 0.79
• WSL2 networking issue: unable to connect to localhost for dev server after update (#6638), similarity score: 0.78
• Does not connect from WSL to localhost (#6168), similarity score: 0.78
• Unable to access windows localhost from WSL2 (#4935), similarity score: 0.78
• WSL 2 - Can't access to localhost after server reloaded (#4366), similarity score: 0.78
• WSL2 - Unable to access localhost:3000 from Windows browser (#4365), similarity score: 0.78

You can give me feedback by thumbs upping or thumbs downing this comment.

[benhillis]

@pmartincic - could you please look at this one?

[sec]

Maybe also lnked with #9760 as those kind of errors started to happen long time ago.

[lfiorini]

Thanks @benhillis I'll check.

Thanks @sec I'll check. Maybe the update has spotted a previous problem. With 1.2.5 and Debian 11 everything has worked smoothly for months.

[ghost]

@sec, I think that's a separate issue that was closed a while back.

@lfiorini, What program are you using within wsl to host this? And what's the output of sudo ss -lntp.

[lfiorini]

@pmartincic I use nginx as proxy for .Net webapps. The output of sudo ss -lntp

State Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
LISTEN 0 511 127.0.0.1:43331 0.0.0.0:* users:(("node",pid=430,fd=19))
LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=166,fd=5),("nginx",pid=165,fd=5),("nginx",pid=164,fd=5),("nginx",pid=163,fd=5),("nginx",pid=162,fd=5),("nginx",pid=161,fd=5),("nginx",pid=160,fd=5),("nginx",pid=159,fd=5),("nginx",pid=158,fd=5))
LISTEN 0 200 127.0.0.1:5432 0.0.0.0:* users:(("postgres",pid=180,fd=6))
LISTEN 0 511 0.0.0.0:443 0.0.0.0:* users:(("nginx",pid=166,fd=7),("nginx",pid=165,fd=7),("nginx",pid=164,fd=7),("nginx",pid=163,fd=7),("nginx",pid=162,fd=7),("nginx",pid=161,fd=7),("nginx",pid=160,fd=7),("nginx",pid=159,fd=7),("nginx",pid=158,fd=7))
LISTEN 0 511 [::]:80 [::]:* users:(("nginx",pid=166,fd=6),("nginx",pid=165,fd=6),("nginx",pid=164,fd=6),("nginx",pid=163,fd=6),("nginx",pid=162,fd=6),("nginx",pid=161,fd=6),("nginx",pid=160,fd=6),("nginx",pid=159,fd=6),("nginx",pid=158,fd=6))

[lfiorini]

@pmartincic thanks to you I've found that the listen directive was only 443 and not [::]:443. I don't know why it worked before but now it works.