WSL2 HTTPS Connections Timeout

Environment

Microsoft Windows [Version 10.0.19042.685]
Release: 20.04
WSL2
Linux version 4.19.128-microsoft-standard (oe-user@oe-host) (gcc version 8.2.0 (GCC)) #1 SMP Tue Jun 23 12:58:10 UTC 2020

Steps to reproduce

For example, trying to install NVM fails with a timeout error.

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.37.2/install.sh | bash

After further debugging I found that the script just tries to clone the repo using https. I then tried to clone any repo via https and it fails with a timeout error, SSH works perfectly fine.

WSL logs:
https://gist.github.com/edarioq/0198119f6c461b4025a3344a354b8d20

Expected behavior

https connections should work and git clone should work without any timeouts.

Actual behavior

fatal: unable to access 'https://github.com/nvm-sh/nvm.git/': Operation timed out after 300038 milliseconds with 0 out of 0 bytes received

Things I've tried:

Changing MTU
Reinstalling (brand new Windows and Ubuntu install)
Disabling IPv6
Updating Git
Updating network drivers

Awesome support from the Microsoft team, guess it's back to good old Mac OS for my development needs.

Edgar Quintero (@edarioq)

Thanks for reporting the issue Edgar Quintero (@edarioq) .

Can you please follow these instructions and share the script output, and both wsl.etl and packets.etl ?

Blue (@OneBlue)

Hi Blue (@OneBlue),

I'm a former Microsoft employee. I filed feedback about what might be a similar issue here: https://aka.ms/AAaztwh (and I included networking diagnostics).

Let me know if you need any help looking at this, I am willing to run further diagnosis if needed, as this is a blocking issue for me at the moment.

While my computer is in the hung network state, it is probably spamming the network one way or another, because my mom can't watch the television until I unplug the network cable and replug it.

In case anyone wonders what to do in this situation, my solution for now has been to install Telerik Fiddler on the Windows side, and setup my Linux machine to use it as a proxy. Because of that trick, all traffic to the web is routed through Windows instead of Linux, and that has prevented the network connection from hanging so far.

Additional instructions

Install Telerik Fiddler

Configure Fiddler to enable proxying VMs
2.1. Enable external connections to the proxy
2.2. Enable interception of HTTPS traffic
2.3. Enable response streaming (New Fiddler version: click on the first button of the toolbar (called "Stream responses" on hover))

Export Fiddler's certificate to your desktop, then install that certificate as root on Linux
sudo mkdir /usr/share/ca-certificates/extra
sudo cp /mnt/c/Users/franc/Desktop/FiddlerRootCertificate.crt /usr/share/ca-certificates/extra
sudo dpkg-reconfigure ca-certificates
Enable connections to go through your firewall
In the Windows firewall, add an inbound rule to enable port 8866
Find your IP address
grep -m 1 nameserver /etc/resolv.conf | awk '{print $2}'
Enable the proxy temporarily for the system:
export http_proxy=172.25.112.1:8866
export https_proxy=172.25.112.1:8866
Enable the proxy for apt-get
sudo nano /etc/apt/apt.conf
Acquire::http::Proxy "http://172.25.112.1:8866";
Acquire::https::Proxy "http://172.25.112.1:8866";
Enable the proxy for pip
mkdir /home/fremy/.config/pip/
vi /home/fremy/.config/pip/pip.conf
[global]
trusted-host = pypi.python.org
               pypi.org
               files.pythonhosted.org

François REMY (@FremyCompany)

I've been experiencing something potentially similar for the past 2-3 weeks (I can't see the Feedback Hub submission François REMY (@FremyCompany)) . Larger downloads with curl will slowly degrade in download speed until the speed reaches zero, then curl just hangs without the download ever completing. It's possible this is affecting all downloads, it's just that the behaviour is easily observable with 30+ MB downloads. This has completely blocked me from using WSL, however François REMY (@FremyCompany)'s fiddler proxy workaround has actually made it useable.

However, in my case I don't believe this is WSL specific as I've observed the same behaviour in an Ubuntu Hyper-V VM. Since WSL2 uses Hyper-V and generates a dedicated WSL Hyper-V switch I can only assume it is something in the Hyper-V virtual network stack.

Here are a couple of downloads that typically stall:

curl -L https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip -o /dev/null
curl -L https://github.com/backstage/backstage/archive/master.zip -o /dev/null

I have tried multiple things to address this (recreating the virtual switch, disabling AV), however I have experienced this on multiple machines including a freshly re-imaged Windows 10 20H2. I'm in a corporate environment so the desktops get installed with an array of bloatware but at this point the only culprit is a Jan 2021 Windows Patch that mentions security updates to "Windows Virtualization": https://support.microsoft.com/en-us/topic/january-12-2021-kb4598242-os-builds-19041-746-and-19042-746-ab18a1a1-d572-598f-4d86-7137aad34056

I think the issue is more generic than some HTTPS URLs. I suspect it's a Hyper-V related TCP NAT problem. ICMP echo requests are transmitted and responded and UDP-based DNS queries can succeed also. No TCP connection can be established though (eg. with nc). I'm on Windows 10 x64 Pro 20H2 19042.928, WSL2 running OpenSuSE Tumbleweed.

Windows update resolved my TCP NAT problem. I'm on Windows 10 x64 Pro 20H2 19042.964 now.

I think this issue can be closed indeed. There was a networking driver update and that fixed this issue for me as well, quite a while ago in fact.

Might it be related to #7254 ?

Was related to an open VPN connection for me. Once that was closed no more timeouts.

Well I am getting the same issue; about an year later than the Original Post.
I'm on Microsoft Windows 11 Pro | Version 10.0.22000.493, and I run into the same issue on WSL2.

I think this issue can be closed indeed. There was a networking driver update and that fixed this issue for me as well, quite a while ago in fact.

An automatic one by Windows update, or a manual one?

Update :

I went to the actual Github repository and there they had this option :
wget -qO- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh | bash

It seemed to work, and $ command -v nvm returns nvm after a restart of the terminal.
I do not know if this is the right way to do this, however.

I'm having this exact same problem now. Fresh Windows 11 Enterprise update, running WSL2/g. wget downloads sometimes time out, sometimes they works In other software, R, the same thing happens when grabbing packages from online repositories. It's a big problem.

Update :

I went to the actual Github repository and there they had this option :
wget -qO- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh | bash

It seemed to work, and $ command -v nvm returns nvm after a restart of the terminal.
I do not know if this is the right way to do this, however.

It is not. Any future installations of node suffer timeouts. It was strange to have my git on WSL and Node on Windows, so I had to reinstall git for windows. While WSL is good for simulating other features in Linux, not having nvm and Node.js really restricts any development environment.

If someone stumbles here, i couldnt get brew package to install, so fiddling with MTU seems to fix it (althought i did try a couple of things).
#4698 (comment)
Note that on my side mtu 1350 vEthernet (WSL)

Hello,

I've got the same trouble and try all this solution:

Current : Windows 10 22H2 19045.2251

Update Kernel : 5.10.102.1-microsoft-standard-WSL2
Update Windows to 22H2 latest possible
Uninstall WSL / HyperV / VM Windows plateform
Try Debian insteed of Ubuntu in WSL

Everything doesn't work, at least i've found a solution for me, change the MTU of the eth0 in WSL to 1350, after this my apt update / upgrade / install work properly.

This is command to use

sudo ip link set dev eth0 mtu 1350

I have the same issue and tried all proposed solutions above. None worked. I also tried solutions there , none worked.

I end up trying removing Docker desktop for Windows and only installing it like a native Linux.
I also activated systemd support.
https://nickjanetakis.com/blog/install-docker-in-wsl-2-without-docker-desktop

I works well and didn't get any troubles.

I'm running into https timeouts on WSL with windows 11. Just checking in.

I was having the same problem, but only after upgrading WSL to WSL2.

I tried changing SSH keys, switching to HTTPS, deleting the repo and failing to clone back again, blaming my VPN, punching my screen... the error wouldn't budge.

Then I just used powershell to downgrade it back:

wsl --set-version Ubuntu-20.04 1

And then everything started working again 🤡

sudo hwclock -s
syncing system time with windows works for me

Checking Docker desktop on

Want to chime in here to add my own experience with this issue. All https requests would fail by timing out, and every fix listed here didn't help. It clearly wasn't a DNS issue because urls could be correctly resolved to IP addresses. Ultimately it turned out that that the Hyper-V firewall was blocking WSL in a way that caused it to fail. Running these commands in powershell fixed my issue:

Set-NetFirewallHyperVVMSetting -Name '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}' -DefaultInboundAction Allow
Set-NetFirewallHyperVVMSetting -Name '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}' -AllowHostPolicyMerge False

The first command modifies the firewall to allow all inbound connections by default. This should probably be a bit more precise to avoid unwanted traffic, but as a first pass it worked. The second command is necessary to prevent the host firewall policy from overriding the locally set values. After this, everything worked as expected.

same problem, and still have no idea

installing with curl, with ethernet connection, first try failed but second try after Ctrl+C worked, still have no idea....

I started getting many different but related errors where I previously had no issues. Setup is WSL2 using Ubuntu 22.04 + Windows 11, building Docker images that contain RUN composer install --ignore-platform-reqs --optimize-autoloader :

A connection timeout was encountered. If you intend to run Composer without connecting to the internet, run the command again prefixed with COMPOSER_DISABLE_NETWORK=1 to make Composer run in offline mode.
Resolving timed out after 10000 milliseconds
SSL Connection timed out
etc...

Setting RUN COMPOSER_IPRESOLVE=4 composer install --ignore-platform-reqs --optimize-autoloader as described in the composer troubleshooting docs fixed the errors for me where many, many other solutions did not work.

I was having the same problem, but only after upgrading WSL to WSL2.

I tried changing SSH keys, switching to HTTPS, deleting the repo and failing to clone back again, blaming my VPN, punching my screen... the error wouldn't budge.

Then I just used powershell to downgrade it back:

wsl --set-version Ubuntu-20.04 1
And then everything started working again 🤡

This fixed it for me also.

4 years later, still an issue.

I have run these from the host machine:

 wsl --update
Checking for updates.
Updating Windows Subsystem for Linux to version: 2.5.7.

and the HTTPS connections are now a bit faster.

5 years later, still an issue.

I am having the exact same issue. Started happening today and can't find a way to fix it.

Navigation Menu

Repository navigation

WSL2 HTTPS Connections Timeout #6416

Environment

Steps to reproduce

Expected behavior

Actual behavior

Things I've tried:

Update :

Update :

14 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

WSL2 HTTPS Connections Timeout #6416

Description

Environment

Steps to reproduce

Expected behavior

Actual behavior

Things I've tried:

Activity

edarioq commented on Jan 15, 2021

OneBlue commented on Jan 29, 2021

FremyCompany commented on Feb 1, 2021

FremyCompany commented on Feb 2, 2021

roovic commented on Feb 10, 2021

dlakatos847 commented on Apr 29, 2021

dlakatos847 commented on Apr 29, 2021

FremyCompany commented on Apr 30, 2021

ekalkutin commented on Aug 4, 2021

rstone commented on Oct 12, 2021

bhargavmodak commented on Feb 9, 2022

Update :

kmshort commented on Apr 5, 2022

bhargavmodak commented on Apr 10, 2022

Update :

brunoAltinet commented on Apr 14, 2022

14 remaining items

Driftminder commented on Dec 5, 2022

cgagnonqc commented on Dec 30, 2022

lxe commented on Apr 16, 2023

gyohza commented on Sep 22, 2023

portwatcher commented on Sep 23, 2023

nicejin74 commented on Oct 23, 2023

DominikM commented on Jan 16, 2024

fooyun commented on Feb 7, 2024

CaoKha commented on Feb 12, 2024

jess-disguise commented on May 14, 2024

ayatim commented on Nov 30, 2024

jbmckeon commented on Feb 5, 2025

la-force-tranquille commented on Jun 4, 2025

chris2k20 commented on Mar 12, 2026

luistcostaDVS commented on Mar 12, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions