Very slow network speeds
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 33.7k
- Forks
- 1.8k
- Avg merge
- 3d 17h
- Merged PRs (30d)
- 116
Description
Version
Microsoft Windows [Version 10.0.22000.556]
WSL Version
- WSL 2
Kernel Version
5.10.60.1
Distro Version
Ubuntu 20.04
Repro Steps
- Install branch latest version of windows 11 (just did a complete reinstall of my computer)
- Install everything wsl2 related from the docs (I did this twice to ensure it was not a faulty setup)
- Install NVM from the docs
- Try to download a node env (very slow speeds)
- Try to download the same tar using curl instead (also very slow speeds)
Downloading this from windows is almost instant.
Speedtest in my windows environment:

Speedtest in my WSL environment
$ speedtest
Retrieving speedtest.net configuration...
Testing from REDACTED...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by REDACTED [28.19 km]: 44.639 ms
Testing download speed
Download: 788.47 Mbit/s
Testing upload speed
Upload: 137.57 Mbit/s
Expected Behavior
I would expect it to not be much slower than my host machine.
Actual Behavior
~4 hours for 14mb makes it quite unusable...

Diagnostic Logs
Let me know if I should include the networking diagnostic from windows as well, they are long, so I did not add it.
WSL Networking Summary:
paul@PAUL-DESKTOP:~/temp/wsl/diagnostics $ ./networking.sh
If you see 'ping: socket: Operation not permitted' errors, run this command as root.
+ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.4 LTS
Release: 20.04
Codename: focal
+ uname -a
Linux PAUL-DESKTOP 5.10.60.1-microsoft-standard-WSL2 #1 SMP Wed Aug 25 23:20:18 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
+ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether d2:c0:01:6a:1b:ed brd ff:ff:ff:ff:ff:ff
3: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 76:4b:c8:32:c2:9a brd ff:ff:ff:ff:ff:ff
4: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
link/ipip 0.0.0.0 brd 0.0.0.0
5: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
link/sit 0.0.0.0 brd 0.0.0.0
6: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1350 qdisc mq state UP group default qlen 1000
link/ether 00:15:5d:7c:a2:af brd ff:ff:ff:ff:ff:ff
inet 172.30.22.56/20 brd 172.30.31.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::215:5dff:fe7c:a2af/64 scope link
valid_lft forever preferred_lft forever
+ ip route show
default via 172.30.16.1 dev eth0
172.30.16.0/20 dev eth0 proto kernel scope link src 172.30.22.56
++ ip route show
++ awk '/default/ { print $3 }'
+ gateway=172.30.16.1
+ ping -c 4 172.30.16.1
PING 172.30.16.1 (172.30.16.1) 56(84) bytes of data.
--- 172.30.16.1 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3097ms
+ ping -c 4 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=18.6 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=58 time=19.0 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=58 time=18.8 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=58 time=18.7 ms
--- 1.1.1.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 18.639/18.811/19.028/0.143 ms
+ traceroute 1.1.1.1
./networking.sh: line 28: traceroute: command not found
+ cat /etc/resolv.conf
nameserver 8.8.8.8
+ type curl
+ curl -m 5 -v https://microsoft.com
* Trying 104.215.148.63:443...
* TCP_NODELAY set
* Connected to microsoft.com (104.215.148.63) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN, server accepted to use h2
* Server certificate:
* subject: C=US; ST=WA; L=Redmond; O=Microsoft Corporation; CN=microsoft.com
* start date: Jan 24 04:39:56 2022 GMT
* expire date: Jan 19 04:39:56 2023 GMT
* subjectAltName: host "microsoft.com" matched cert's "microsoft.com"
* issuer: C=US; O=Microsoft Corporation; CN=Microsoft Azure TLS Issuing CA 06
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55dc5d401880)
> GET / HTTP/2
> Host: microsoft.com
> user-agent: curl/7.68.0
> accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 301
< date: Sat, 19 Mar 2022 09:44:03 GMT
< location: https://www.microsoft.com/
< server: Kestrel
< content-length: 0
< strict-transport-security: max-age=31536000; includeSubDomains
<
* Connection #0 to host microsoft.com left intact
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by rerunning networking.sh and the curl and download steps in Ubuntu 20.04 under WSL 2, comparing results with Windows. The issue names no source file or test, so use the collected WSL networking diagnostics to locate the relevant entry point. Done means downloads no longer show the reported severe slowdown without regressing normal WSL network access.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- linux, ubuntu
- Domain
- networking, operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 38/100