My WSL2 VM Kept Losing Network Every Five Minutes

The flapping

The symptom was a host-wide network blip on a short, regular interval, correlated tightly with WSL2 being up. The cause: WSL2's default networking mode creates a virtual NAT switch on the Windows side, and on this machine that virtual switch was intermittently conflicting with the real network adapter - enough to cause the whole host to briefly renegotiate its connection.

The fix was switching WSL2's networking mode entirely, via .wslconfig (on Windows, not inside the Linux filesystem):

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

Mirrored networking makes the WSL2 interface share the host's actual network identity instead of sitting behind a separate virtual NAT switch. You can confirm it actually took effect (rather than just trusting the config file) by checking, from inside WSL after a full restart:

• its network interface holds the same IP as the Windows host
• the default route points at the real LAN gateway rather than a private NAT range
• loopback carries mirrored mode's marker address rather than a 172.x NAT address

If any of those don't match, the setting isn't actually active yet. Worth noting: this requires a reasonably recent WSL version and Windows build. If you're on an older one, mirrored mode may not be available at all.

The memory landmines, found the hard way

Separately - and this had actually caused full VM crashes, not just hangs, at one point - I'd been carrying a few .wslconfig settings that looked reasonable and were each, individually, a documented source of instability:

• An explicit kernelCommandLine override.
• Resizing swap past a few GB, which forces WSL to rebuild its virtual disk and can leave things in a bad state mid-rebuild.
• [experimental] autoMemoryReclaim = gradual - has documented freeze bugs in the versions I was on.

Any one of these coinciding with a memory-constrained session was enough to take the WSL VM down hard enough that it wouldn't restart cleanly - the actual failure mode was a service-level "catastrophic failure" error, not just a slow hang.

The safe way to adjust swappiness, instead of a kernel command-line flag, is a plain sysctl drop-in that gets applied on every boot:

# /etc/sysctl.d/99-swappiness.conf
vm.swappiness = 10

Recovery, when it won't come back up at all

If WSL refuses to launch after something like this:

1. Close the terminal window outright. Don't keep hitting Enter - that just re-hits whatever service is already wedged.
2. From PowerShell: wsl --shutdown, then wait a beat before trying again.
3. If it's still refusing: restart the underlying WSL service (as admin), then wsl --update.
4. If it's still unhappy: quit anything with its own WSL integration (a container runtime, for instance) and test again - integrations like that are a common second point of contention over the same resources.

What I'd tell past-me

• A periodic, host-wide network blip that correlates with a VM being up is almost always that VM's networking mode, not your actual network hardware - don't start troubleshooting the router.
• Verify a networking-mode config change actually took effect (interface, route, loopback marker) instead of assuming the file being correct means the behavior changed.
• Some "obvious" tuning flags for a VM are documented landmines. Change one at a time, and check what's actually been reported broken about it before adding it.
• When recovery is needed, follow the same escalation path in order - don't jump straight to the most drastic fix before ruling out the cheap ones.