How to Configure and Switch WSL2's Networking Mode

WSL2 supports two distinct networking modes — this walks through configuring and verifying each one directly.

Step 1: check your current networking mode

wsl --version

Do not infer the active mode solely from an address range. Record the Windows build and WSL package version, then verify behavior after the restart: mirrored mode lets the Windows host and WSL reach each other over IPv4 localhost, while NAT normally requires the peer’s virtual address. Current WSL packages also provide wslinfo --networking-mode inside the distribution; when present, use its direct answer instead of guessing from ip addr.

Step 2: identify why you might need to switch

Need a service running inside WSL2 to be reachable
  from another device on your LAN? → mirrored mode
  helps directly

Experiencing VPN-related connectivity or DNS issues
  under NAT mode specifically? → mirrored mode is
  worth trying

Step 3: edit .wslconfig to enable mirrored mode

%UserProfile%\.wslconfig

[wsl2]
networkingMode=mirrored

Step 4: fully restart WSL2 for the change to take effect

wsl --shutdown

Then relaunch your distro — networking mode changes require this full restart, not just reopening a terminal window.

Step 5: verify the new networking mode is active

wslinfo --networking-mode 2>/dev/null || true

Then test the documented behavior you need. For example, start a service on Windows bound to IPv4 localhost and connect to 127.0.0.1 from WSL. Mirrored mode supports that host/guest localhost path; a label or config file by itself does not prove the restarted VM adopted the setting.

Step 6: test LAN reachability directly

# from inside WSL2, start a simple test server:
python3 -m http.server 8000

Before testing from another LAN device, create a narrow Hyper-V firewall rule from an elevated PowerShell window. Replace the port with the one you actually intend to expose:

New-NetFirewallHyperVRule -Name "WSL-Test-8000" `
  -DisplayName "WSL test server 8000" `
  -Direction Inbound `
  -VMCreatorId '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}' `
  -Protocol TCP -LocalPorts 8000

Then reach the Windows host’s LAN address on port 8000 from a separate device. Remove the test rule when finished if it is not part of the intended service design. A local browser test does not exercise the LAN path or the Hyper-V firewall.

Step 7: revert to NAT mode if mirrored mode causes different issues

[wsl2]
networkingMode=nat

Mirrored mode isn’t universally better for every setup — some VPN configurations or specific network environments behave better under the original NAT default, and reverting is as simple as changing this setting back and restarting WSL2 again.

Step 7b: confirm DNS tunneling instead if the problem is specifically name resolution

If your actual symptom is broken DNS resolution behind a VPN rather than a broader LAN-reachability need, confirm dnsTunneling=true under .wslconfig’s [wsl2] section. It is enabled by default on supported Windows 11 22H2-and-newer systems and targets the resolver path without changing the whole networking architecture.

Step 8: test VPN behavior specifically if that was your original motivation

If you switched modes specifically to address VPN-related connectivity issues, test with your VPN actually connected in both modes to directly compare behavior, rather than assuming the mode switch resolved the issue without confirming it under real conditions.

Why testing both modes directly, rather than picking based on general advice, matters

Networking behavior depends heavily on your specific router, VPN client, and network configuration — general guidance about which mode is “better” can’t account for your specific setup’s particulars, making a direct, deliberate test of your actual reachability or connectivity concern the only way to confirm which mode genuinely works better for you.

Checking whether mirrored mode is actually available before configuring it

Mirrored networking requires Windows 11 version 22H2 or higher and a sufficiently current WSL version. Unsupported or unrecognized networking values can leave WSL using NAT, so confirm the Windows build, wsl --version, the post-restart mode, and the exact functional path instead of treating a saved .wslconfig file as proof.

The Hyper-V firewall’s role once mirrored mode is active

Enabling mirrored mode on Windows 11 22H2+ with a current WSL version also activates the Hyper-V firewall for WSL traffic by default — meaning a service reachable from the Windows host itself isn’t automatically reachable from the wider LAN if this firewall layer blocks it. Testing reachability specifically from a separate machine on the network, not just from the Windows host, confirms mirrored mode’s LAN-reachability benefit is actually working end to end.

Using the older port-forwarding approach if you need to stay on NAT

For setups with a specific reason to remain on NAT mode but still needing a WSL2-hosted service reachable from the LAN, netsh interface portproxy rules on the Windows side relay traffic from the host’s LAN-facing address into WSL2’s private NAT address — more manual per-port configuration than mirrored mode requires, but a valid option when switching networking modes entirely isn’t desirable.

Document whichever mode you settle on, and why, directly alongside your .wslconfig file — the reasoning behind a non-default networking choice is exactly the kind of context that’s easy to forget months later when troubleshooting an unrelated issue.

Confirming the change actually took hold after a restart

Beyond checking ip addr once, re-running the same check after closing and reopening the WSL terminal (not just the wsl --shutdown step itself) confirms the new networking mode persists across ordinary daily use, rather than only appearing correct immediately after the deliberate restart used to apply the change.

Related:

Sources: