Fixing WSL2 Networking and DNS Resolution Failures

WSL2 networking failures usually fall into a small number of specific, diagnosable categories — this walks through isolating which one you actually have before reaching for a fix.

Step 1: confirm basic connectivity first

ping 8.8.8.8

If this fails entirely, the problem is more fundamental than DNS — check your networking mode configuration and whether the WSL2 VM has basic network connectivity at all before troubleshooting DNS specifically.

Step 2: isolate DNS specifically

ping 8.8.8.8       # works
ping google.com    # fails

This specific pattern — raw IP connectivity working, but domain resolution failing — isolates the problem to DNS resolution specifically, not general networking.

Step 3: check the current resolv.conf configuration

cat /etc/resolv.conf

WSL2 automatically generates this file by default, pointing to a DNS server based on your Windows host’s own network configuration — if this file looks empty, points to an unreachable address, or wasn’t regenerated after a network change, that’s your specific problem.

Step 4: check whether automatic resolv.conf generation is actually enabled

/etc/wsl.conf

[network]
generateResolvConf = true

If this has been set to false (sometimes done to allow manual DNS configuration) but no manual configuration was actually put in its place, WSL2 has no working DNS configuration at all.

Step 5: manually set a known-working DNS server as a direct test

sudo bash -c 'echo "nameserver 8.8.8.8" > /etc/resolv.conf'

If this immediately fixes resolution, the problem was specifically with whatever DNS server was previously configured (often an internal corporate or VPN-provided DNS server that WSL2 couldn’t actually reach) — not a general WSL2 networking fault.

Step 6: check for VPN interference specifically

VPN software running on the Windows host frequently changes routing and DNS configuration in ways that don’t propagate correctly into WSL2’s virtualized network, particularly under NAT networking mode — this is one of the single most common root causes of “WSL networking suddenly broke” reports.

Step 7: try mirrored networking mode if VPN interference is confirmed

%UserProfile%\.wslconfig

[wsl2]
networkingMode=mirrored

Mirrored networking mode gives WSL2 the same network configuration as the Windows host directly, often resolving VPN-related DNS and routing conflicts that NAT mode’s separate virtual network can introduce.

wsl --shutdown

Networking configuration changes, including .wslconfig edits and /etc/wsl.conf changes, generally require a full WSL2 restart to take effect — testing without this step first can make a genuine fix look like it didn’t work.

Why isolating DNS from general connectivity is the essential first step

Treating every WSL2 networking complaint as one undifferentiated “networking is broken” problem leads to trying fixes at random — the ping-by-IP-versus-ping-by-name test in Step 2 alone correctly routes you toward either a DNS-specific fix or a broader connectivity investigation, saving considerable troubleshooting time either way.

Trying DNS tunneling as a more targeted alternative to mirrored mode

If switching networking modes entirely feels like a bigger change than the problem warrants, first confirm DNS tunneling under the current section and restart WSL:

# %UserProfile%\.wslconfig
[wsl2]
dnsTunneling=true

Microsoft documents DNS tunneling as enabled by default on supported Windows 11 22H2-and-newer systems. Explicitly setting it can remove ambiguity in an audited configuration, but it will not add the feature to an outdated WSL installation. It targets the DNS path without changing the broader networking architecture the way mirrored mode does.

Making a manually-set DNS server persist across restarts

The manual resolv.conf edit in Step 5 is a diagnostic test, not a permanent fix — it gets overwritten the next time WSL regenerates the file unless generateResolvConf = false is also set in /etc/wsl.conf. If a manually-specified DNS server turns out to be the right permanent answer for your network, making that change explicit and intentional (rather than relying on an edit that silently reverts) avoids the confusing experience of a fix that appeared to work then mysteriously stopped.

Related:

Sources: