WSL2中Fedora及更新后Arch发行版curl访问https://sh.rustup.rs出现Recv failure: Connection reset by peer问题排查求助

I've worked through similar WSL2 network issues before, so let's break down what's going on and fix this step by step:

First, Answering Your Core Questions #

1. Why does this hit Fedora and updated Arch but not fresh Arch/another device's Fedora?
   Fedora comes with newer curl and OpenSSL versions out of the box, which use TLS 1.3 and stricter cipher suites by default. Fresh Arch starts with older library versions that play nicely with your WSL2 network stack—until you run pacman -Syu and upgrade those libraries to match Fedora's. The other device probably has a different WSL2 network config (like MTU) or less restrictive security software that doesn't block these newer TLS handshakes.

2. Is this tied to updated TLS libraries and network/security settings?
   100% yes. The connection reset happens during the TLS handshake, which means either your upgraded system libraries' TLS behavior is clashing with WSL2's virtual network stack, or Windows-level security tools (firewall/Defender) are intercepting or dropping handshake packets. Even when you tried forcing TLS 1.2, your logs showed a TLS 1.3 Client Hello—this is likely because your system's OpenSSL config is overriding curl's flags, or WSL2's network layer is modifying traffic behind the scenes.

3. Root Cause & Fixes
   The most common culprits here are misconfigured MTU in WSL2, Windows security tool interference, or a corrupted WSL2 network stack. Let's go through each fix in order:

Step 1: Fix WSL2 MTU Mismatch #

WSL2's default MTU often doesn't match your host machine's network interface, which can cause large TLS handshake packets to get dropped (resulting in connection resets).

1. Check your host's MTU: Open Windows Command Prompt and run:

   netsh interface ipv4 show subinterfaces
   

   Note the MTU value for your active network adapter (usually 1500, or lower if you're on a VPN).
2. Set WSL2 MTU to a slightly lower value (e.g., 1492, which avoids fragmentation):
   In your WSL2 terminal:

   sudo ip link set dev eth0 mtu 1492
   

   Test the connection again with curl -4 -v https://sh.rustup.rs—if it works, make this permanent:
   • Fedora: Create a NetworkManager script:

     sudo nano /etc/NetworkManager/dispatcher.d/99-mtu-setup
     

     Paste this content:

     #!/bin/bash
     if [ "$1" = "eth0" ]; then
         ip link set dev eth0 mtu 1492
     fi
     

     Make it executable:

     sudo chmod +x /etc/NetworkManager/dispatcher.d/99-mtu-setup
     

   • Arch: Edit the systemd-networkd config:

     sudo nano /etc/systemd/network/20-wsl.network
     

     Add these lines (create the file if it doesn't exist):

     [Match]
     Name=eth0
     
     [Network]
     MTU=1492
     

     Restart the network service:

     sudo systemctl restart systemd-networkd
     

Step 2: Force Strict TLS 1.2 (Bypass TLS 1.3 Issues) #

If your system's OpenSSL is overriding curl's TLS flags, explicitly disable TLS 1.3 and enforce TLS 1.2:

1. Test with a strict TLS 1.2 command:

   curl -4 -v --tlsv1.2 --tls-max 1.2 https://sh.rustup.rs
   

2. Make this permanent for curl (optional):
   Edit your user's curl config:

   nano ~/.curlrc
   

   Add these lines:

   --tlsv1.2
   --tls-max 1.2
   

3. Install Rustup with these flags:

   curl --proto '=https' --tlsv1.2 --tls-max 1.2 -sSf https://sh.rustup.rs | sh
   

Step 3: Rule Out Windows Security Interference #

Windows Defender or third-party firewalls often block WSL2's outbound TLS traffic without explicit rules:

1. Temporarily disable Windows Defender Real-Time Protection and Network Protection (Settings > Privacy & Security > Windows Security > Virus & Threat Protection > Manage Settings). Test the connection again—if it works, you'll need to add an exception.
2. Allow WSL2 traffic in Windows Firewall:
   • Open Windows Defender Firewall > Advanced Settings.
   • Create a new Outbound Rule that allows all traffic from wsl.exe, or allow traffic from your WSL2 subnet (check with ip addr show eth0 in WSL2, usually 172.x.x.x or 192.168.x.x) over port 443 (HTTPS).

Step 4: Reset WSL2 Network Stack #

Corrupted WSL2 network state can cause weird connection issues. Reset it from Windows Command Prompt:

wsl --shutdown
netsh winsock reset
netsh int ip reset all
netsh winhttp reset proxy
ipconfig /flushdns

Restart WSL2 and test the connection again.

Step 5: Use a Rustup Mirror (If Network Nodes Are the Issue) #

If the problem is with your ISP's routing to Rustup's official servers, switch to a domestic mirror:

export RUSTUP_DIST_SERVER=https://mirrors.ustc.edu.cn/rust-static
export RUSTUP_UPDATE_ROOT=https://mirrors.ustc.edu.cn/rust-static/rustup
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

To make this permanent, add the export lines to your ~/.bashrc or ~/.zshrc.

内容的提问来源于stack exchange，提问作者MioMelliot