Fix: WSL2 has no network or DNS does not resolve

Typical symptoms inside WSL:

$ sudo apt update
Err:1 http://archive.ubuntu.com/ubuntu noble InRelease
  Temporary failure resolving 'archive.ubuntu.com'

$ curl https://example.com
curl: (6) Could not resolve host: example.com

$ ping 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=57 time=12.3 ms

WSL2 runs in a small virtual machine with its own network adapter. By default that network is translated (NAT) through Windows, and WSL writes a /etc/resolv.conf that points at the Windows host as DNS server. VPN clients, corporate firewalls, some antivirus products and a few misbehaving resolv.conf edits can break either half. The first job is to find out which half.

Step 1: DNS or network?

ping -c 3 1.1.1.1            # raw connectivity by IP
ping -c 3 example.com        # name resolution
cat /etc/resolv.conf         # which DNS server is WSL using?
ip addr show eth0            # does WSL have an address at all?

• IP works, names fail: DNS problem, continue with step 2.
• Nothing works, eth0 has no inet address or everything times out: network problem, jump to step 4.
• Everything works on the home network and breaks only on the VPN: step 5.

Step 2: restart WSL first

A surprising number of cases are fixed by letting WSL rebuild its network. From PowerShell:

wsl --shutdown
wsl

Also run wsl --update and restart Windows if it has been a while; several networking bugs were fixed in WSL releases in 2023 and 2024.

Step 3: fix DNS with a static resolv.conf

If /etc/resolv.conf points at an address like 172.x.x.1 and that server does not answer, tell WSL to stop generating the file and write your own. Inside Ubuntu:

sudo tee /etc/wsl.conf > /dev/null <<'EOF'
[network]
generateResolvConf = false
EOF

sudo rm -f /etc/resolv.conf
printf 'nameserver 1.1.1.1\nnameserver 8.8.8.8\n' | sudo tee /etc/resolv.conf

Then from PowerShell run wsl --shutdown and open Ubuntu again. If /etc/resolv.conf was a symlink, the rm is what makes the new file stick. Careful: this hard-codes public DNS servers, so names that exist only on your company network will stop resolving inside WSL. To undo, delete the [network] section from /etc/wsl.conf (or the whole file if that is all it contains), remove /etc/resolv.conf and run wsl --shutdown; WSL generates the file again on the next start.

On a corporate network, use your company’s DNS servers instead of public ones. Find them on the Windows side with Get-DnsClientServerAddress -AddressFamily IPv4.

Step 4: try mirrored networking (Windows 11)

On Windows 11 version 22H2 and later with WSL 2.0 or newer, mirrored mode gives the Linux side the same network interfaces as Windows, which removes the NAT layer and makes most VPN setups just work. It also lets WSL use the host’s DNS through DNS tunneling. Check your version with wsl --version, then create or edit %UserProfile%\.wslconfig on the Windows side:

[wsl2]
networkingMode=mirrored
dnsTunneling=true
autoProxy=true

Save the file and run wsl --shutdown; the settings apply when WSL starts again. Careful: mirrored mode changes how ports and addresses behave (localhost is shared with Windows, and services bind on the same interfaces as Windows). If something else breaks, delete those lines from .wslconfig and shut WSL down again to return to the default NAT mode.

If mirrored mode is not available, dnsTunneling=true on its own, under the same [wsl2] header, often fixes DNS in NAT mode on recent WSL versions because queries go through Windows instead of over the virtual network.

Step 5: VPN clients

Many VPN clients install a filter driver or a firewall rule that drops traffic from the WSL virtual switch, or they change Windows DNS to servers only reachable through the tunnel. In order of least to most effort:

1. Try mirrored networking with dnsTunneling=true (step 4). It is the fix Microsoft designed for this.
2. Connect the VPN before starting WSL, then wsl --shutdown and start it again, so WSL picks up the VPN’s DNS servers.
3. Point /etc/resolv.conf at the VPN’s DNS servers (from Get-DnsClientServerAddress while connected) as in step 3.
4. Check the vendor’s documentation for a WSL or Hyper-V setting; several VPN products have one.

Step 6: firewall and antivirus

Windows 11 includes a Hyper-V firewall that also governs WSL. Check whether a third-party security product is blocking the vEthernet (WSL) adapter, and look at what Windows thinks of it:

Get-NetAdapter | Where-Object Name -like '*WSL*'
Get-NetIPInterface | Where-Object InterfaceAlias -like '*WSL*'
Get-NetFirewallHyperVVMSetting -PolicyStore ActiveStore

Temporarily disabling the third-party firewall to see whether the problem disappears is the fastest diagnosis; remember to turn it back on. If it is the culprit, add an allow rule for the WSL adapter in that product rather than leaving it off.

Still stuck

• Check for an old /etc/resolv.conf edit from a previous fix that now points at a server that no longer exists.
• Check proxy settings: on a network with an HTTP proxy, set http_proxy and https_proxy inside WSL or let autoProxy=true import them.
• Collect logs with the official script linked below before opening an issue on the WSL GitHub repository.

Official documentation

• Accessing network applications with WSL (networking modes, mirrored mode, DNS tunneling)
• Advanced settings configuration in WSL (wsl.conf and .wslconfig)
• Troubleshooting WSL