Fixing WSL2 Networking and DNS Resolution Failures
Ping works, but domain names won't resolve inside WSL2 — or the reverse. Here's how to actually diagnose whether the problem is DNS configuration, VPN interference, or the networking mode itself.
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.8If 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 # failsThis 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.confWSL2 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 = trueIf 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=mirroredMirrored 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.
Step 8: restart WSL2 fully after any networking-related configuration change
wsl --shutdownNetworking 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.