My WSL2 VM Kept Losing Network Every Five Minutes

Every five minutes or so, my entire Windows machine would drop off the network for a few seconds — not just WSL, the whole host. Browser tabs would stall, calls would drop, and it only happened while WSL2 was running. This is the story of finding that, plus the WSL memory-tuning landmines I hit right alongside it.

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, that its network interface holds the same IP as the Windows host, that the default route points at the real LAN gateway rather than a private NAT range, and that 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.