WSL "Temporary failure in name resolution" - How to Fix

Seeing "Temporary failure in name resolution" inside WSL? DNS inside the distribution has stopped working. Here is how to confirm that, and how to fix it without hardcoding a public resolver unless you have to.

The Error

$ ping google.com
ping: google.com: Temporary failure in name resolution

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

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

All three are the same failure reported by three different programs. The wording comes from glibc's resolver, which is why it looks identical across Ubuntu, Debian and most other WSL distributions.

Quick Fix

From PowerShell or Command Prompt on the Windows side, not inside WSL:

wsl --shutdown

Wait about ten seconds, then open your WSL terminal again. This shuts down the WSL virtual machine and its virtual network adapter; on the next start, WSL regenerates /etc/resolv.conf and re-establishes the NAT. It fixes the majority of cases, particularly after the host has slept, changed Wi-Fi networks, or been through a Windows update.

Test it:

ping -c 3 google.com

Is It DNS, or Is It the Network?

Before changing configuration, find out which half is broken. Inside WSL:

# Can we reach the internet at all, without DNS?
ping -c 3 1.1.1.1

# Can we resolve a name?
ping -c 3 google.com

• IP works, name fails - DNS only. Continue with the fixes below.
• Both fail - WSL has no network path at all. The wsl --shutdown fix still applies, but also check whether a VPN, a third-party firewall, or a corporate endpoint agent is filtering the WSL adapter on the Windows side.

Then look at what WSL thinks its resolver is:

cat /etc/resolv.conf

Healthy output looks like this:

# This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf:
# [network]
# generateResolvConf = false
nameserver 172.20.16.1

That 172.x.x.1 address is the Windows host acting as a DNS proxy. If the file is empty, missing, or points at an address that no longer exists, that is your fault line.

Fix 1: Regenerate resolv.conf

If the file is stale or empty, force WSL to rebuild it. Inside WSL:

sudo rm /etc/resolv.conf

Then from PowerShell:

wsl --shutdown

Reopen WSL. The file is recreated on start. Confirm the nameserver address matches the Windows-side adapter:

Get-NetIPAddress -InterfaceAlias "vEthernet (WSL)" -AddressFamily IPv4

The IPAddress shown there should be the nameserver line inside WSL.

Fix 2: VPN Connected? Use Mirrored Networking

This is the single most common cause on corporate laptops. Cisco AnyConnect, GlobalProtect, Zscaler and similar clients install routes and set adapter metrics that WSL's default NAT networking does not pick up, so the WSL nameserver becomes unreachable the moment the tunnel comes up.

On Windows 11 with WSL 2.0.0 or newer, switch WSL to share the Windows network stack instead of sitting behind its own NAT. Create or edit %USERPROFILE%\.wslconfig on the Windows side:

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

Then:

wsl --shutdown

In mirrored mode WSL sees the same interfaces and DNS configuration as Windows, so VPN split-DNS works the way it does for any Windows application. Check your WSL version first:

wsl --version

If that command is not recognised, you are on the older inbox WSL and should run wsl --update before using mirrored mode. If wsl --update is blocked by policy on your machine, wsl --update --web-download fetches the package directly instead of going through the Microsoft Store.

Fix 3: Set a Static Nameserver

Only reach for this if the fixes above did not work, and understand the tradeoff: a hardcoded public resolver bypasses your organization's DNS, which breaks internal hostnames and may conflict with security tooling that expects all lookups to pass through an approved resolver. On a personal machine it is fine.

First, stop WSL from regenerating the file. Inside WSL:

sudo nano /etc/wsl.conf

Add:

[network]
generateResolvConf = false

From PowerShell:

wsl --shutdown

Reopen WSL and write your own resolver:

sudo rm -f /etc/resolv.conf
echo "nameserver 1.1.1.1" | sudo tee /etc/resolv.conf
echo "nameserver 8.8.8.8" | sudo tee -a /etc/resolv.conf

If something still rewrites the file, make it immutable:

sudo chattr +i /etc/resolv.conf

To reverse that later, sudo chattr -i /etc/resolv.conf, and remove the generateResolvConf line from /etc/wsl.conf to hand control back to WSL.

Fix 4: Reset the Windows Network Stack

If WSL still cannot resolve anything and Windows itself is fine, a stale Winsock or adapter state on the host can be the cause. In an elevated PowerShell:

wsl --shutdown
netsh winsock reset
netsh int ip reset

Both commands require a reboot to take effect. This resets network settings for the whole machine, so save your work first and expect to re-enter any manual proxy configuration afterwards.

Verify the Fix

# Resolution works
getent hosts example.com

# Full path from lookup to TLS connection
curl -I https://example.com

# Package manager can reach its mirrors
sudo apt update

getent hosts is a better test than nslookup, because nslookup queries DNS directly and can succeed while the system resolver configuration is still broken.

Prevention

• After connecting or disconnecting a VPN, run wsl --shutdown rather than fighting the symptom. It is a two-second habit that avoids most recurrences.
• On Windows 11, adopt networkingMode=mirrored permanently if your environment supports it - it eliminates the entire class of NAT-versus-VPN DNS problems.
• Keep WSL current with wsl --update. DNS handling has changed substantially across WSL 2.x releases, and several long-standing resolver bugs are fixed in newer builds.
• If you must pin a nameserver, prefer your organization's internal resolver over a public one so that internal hostnames keep working.

Summary

1. First: wsl --shutdown from PowerShell, then reopen WSL
2. Diagnose: ping 1.1.1.1 versus ping google.com to separate DNS from connectivity
3. On VPN: set networkingMode=mirrored in %USERPROFILE%\.wslconfig
4. Last resort: generateResolvConf = false in /etc/wsl.conf plus a manual nameserver entry
5. Verify: getent hosts example.com