[mirrored/NAT] Networking fully breaks into ARP/HNS blackhole after residual HKCU proxy settings (ProxyEnable=0 with non-empty ProxyServer) — not recoverable by wsl --shutdown / service restart / full reboot

Windows Version

Microsoft Windows [Version 10.0.26200.8246]

WSL Version

2.6.3.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

6.6.87.2-1

Distro Version

Ubuntu 24.04 (systemd enabled)

Other Software

Clash for Windows / Clash.Meta (system-proxy mode, no TUN / no virtual adapter) — used briefly 7 days after installing
KB5083769, then exited

TAP-QuickFox v1.0.0.0 driver installed (from a previously-used accelerator) — disconnected during incident, not an
active component

No third-party antivirus, no VPN client active, no Docker Desktop, no third-party network filter driver bound to WLAN
or vEthernet adapters

Repro Steps

1. Clean Windows 11 Pro 25H2 (26200.8246) with WSL 2.6.3.0 + Ubuntu, using default networkingMode=mirrored.
   Networking works normally for days.

2. Launch a third-party proxy client (in this case Clash) in system-proxy mode only (not TUN / not a virtual
   adapter). This causes Windows to set:

   • HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyEnable → 1
   • ProxyServer → 127.0.0.1:<port> (Clash default 7897)
   • ProxyOverride → a bypass list that includes 172.16.*–172.31.* (covering WSL's default NAT range)

3. Exit the proxy client. Clash disables the proxy (ProxyEnable → 0) but does not clear ProxyServer or
   ProxyOverride. This leaves HKCU in a mixed state:

   • ProxyEnable = 0
   • ProxyServer = 127.0.0.1:7897
   • ProxyOverride = localhost;127.*;...;172.16.*;...;172.31.*;<local>

4. Resume normal WSL usage. At some point (next wsl --shutdown, sleep/wake, or network change), WSL's mirrored
   networking enters a failure state where the WSL VM can no longer ARP-resolve the host gateway, and the Hyper-V vSwitch
   starts emitting persistent OID_GEN_STATISTICS took too long warnings (Event ID 285) on the Default Switch NIC.

5. Attempting to switch to default NAT mode does not help — NAT gets an IP from DHCP but never installs a default
   route, and cannot ARP-resolve vEthernet (WSL (Hyper-V firewall)).

6. Reboot, service restart, adapter disable/enable, HNS network delete+recreate — none recover WSL to a working
   state.

7. The only thing that did recover WSL:

   # Clear stale WinINet proxy settings
   Set-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" -Name ProxyServer   -Value ""
   Set-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" -Name ProxyOverride -Value ""
   
   # Full network stack reset
   netsh winsock reset
   netsh int ip reset
   netsh int ipv4 reset
   netsh int ipv6 reset
   ipconfig /flushdns
   arp -d *
   
   # Reboot Windows
   After reboot, mirrored + firewall=false works perfectly.
   
   

Honest caveat: I did not isolate whether clearing ProxyServer/ProxyOverride alone would have been sufficient, or
whether netsh winsock reset alone was enough. Both were done before the reboot. I'd value the WSL team's ability to
reproduce in a lab to narrow this down.

Timeline evidence that rules out being purely a 25H2 CU regression:

• KB5083769 installed 2026-04-15, WSL worked normally for 7 days afterwards.
• Failure started 2026-04-22, the same day the third-party proxy client was used.
• No other Windows updates, no driver updates, no WSL update in that 7-day window.

Expected Behavior

WSL 2's mirrored and NAT networking should be resilient to stale/disabled WinINet proxy settings in HKCU.
Specifically:

1. When HKCU\...\Internet Settings\ProxyEnable = 0, WSL's internal proxy-propagation logic (including autoProxy in
   mirrored, and whatever DNS/proxy path NAT uses) should ignore ProxyServer and ProxyOverride entirely, treating
   them as the explicit "off" state the user/system has configured.

2. No user-space registry state should be capable of inducing a kernel-level failure on the Hyper-V vSwitch such that
   ARP broadcasts silently fail between host and VM on an internal-switch bridge. That's an invariant violation — the
   vSwitch forwarding plane should not depend on HKCU WinINet values.

3. If WSL cannot bring networking up after wsl --shutdown + a Windows reboot, it should emit a clear diagnosable
   signal (wsl --status warning, an Event Log error, stderr on next wsl invocation) rather than silently present what
   looks like a working network with dead ARP underneath.

Actual Behavior

WSL networking breaks silently and irrecoverably without reinstallation or stack-level reset.

mirrored failure

$ wsl -e ip addr show eth0 | grep inet
    inet 10.x.x.x/16 brd 10.x.255.255 scope global noprefixroute eth0   # same as host
$ wsl -e ip route
default via 10.x.0.1 dev eth0 proto kernel metric 35
$ wsl -e ping -c 3 10.x.0.1
From 10.x.x.x icmp_seq=1 Destination Host Unreachable
From 10.x.x.x icmp_seq=2 Destination Host Unreachable
From 10.x.x.x icmp_seq=3 Destination Host Unreachable
--- 10.x.0.1 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss

ARP resolution from WSL to the host gateway fails despite mirrored mode claiming to share the host's L2.

Default NAT failure (after switching .wslconfig)

$ wsl -e ip addr show eth0 | grep inet
    inet 172.25.153.68/20
$ wsl -e ip route
172.25.144.0/20 dev eth0 proto kernel scope link src 172.25.153.68
# ONLY link-scope route, NO default route installed
$ wsl -e ping -c 2 172.25.144.1    # the host's vEthernet (WSL (Hyper-V firewall))
From 172.25.153.68 icmp_seq=1 Destination Host Unreachable
From 172.25.153.68 icmp_seq=2 Destination Host Unreachable

From the host side, pinging the WSL VM's IP also returns no response. So even though both endpoints sit on the same
Hyper-V internal vSwitch, L2 frames are not being forwarded.

HNS

> hnsdiag list networks
Network : 790E58B4-...
    Name           : WSL (Hyper-V firewall)
    Type           : ICS
    Subnet Address : 172.25.144.0/20
    Gateway        : 172.25.144.1

> hnsdiag list endpoints
# empty — no endpoint was registered for the running WSL VM

Ineffective remediation (all tried while networking was broken)

• wsl --shutdown (multiple times)
• Restart-Service hns, vmcompute
• Disable-NetAdapter "vEthernet (WSL*)" ; Enable-NetAdapter "vEthernet (WSL*)"
• Full Windows reboot
• Set-NetFirewallHyperVVMSetting {40E0AC32-...} -DefaultInboundAction Allow
• hnsdiag delete networks 790E58B4-... then relaunch wsl — network was recreated with the same ID, failure pattern
  identical.

Post-fix state (after proxy clear + winsock reset + reboot)

$ wsl -e ip addr show eth2 | grep inet
    inet 10.x.x.x/16
$ wsl -e ip route
default via 10.x.0.1 dev eth2 proto kernel metric 36
$ wsl -e ping -c 2 10.x.0.1
64 bytes from 10.x.0.1: icmp_seq=1 ttl=254 time=2.72 ms
64 bytes from 10.x.0.1: icmp_seq=2 ttl=254 time=2.54 ms
2 packets transmitted, 2 received, 0% packet loss
$ wsl -e bash -c "curl -sI https://www.google.com | head -1"
HTTP/2 200

Why this is a WSL bug even though the trigger is a third-party app

Third-party clients that leave HKCU\...\Internet Settings in (ProxyEnable=0, ProxyServer!="") state are extremely
common — Clash, v2rayN, Shadowsocks-Windows, and many campus-network/VPN clients all do this. WSL should either ignore
these stale values (since ProxyEnable=0 is the canonical "disabled" signal) or fail loudly, but should never
degrade into silent ARP/vSwitch breakdown that requires a Winsock reset to escape.

Diagnostic Logs

HKCU WinINet state (at failure time)

ProxyEnable  : 0
ProxyServer  : 127.0.0.1:7897
ProxyOverride: localhost;127.*;192.168.*;10.*;
               172.16.*;172.17.*;172.18.*;172.19.*;172.20.*;
               172.21.*;172.22.*;172.23.*;172.24.*;172.25.*;
               172.26.*;172.27.*;172.28.*;172.29.*;172.30.*;
               172.31.*;<local>

Note that ProxyOverride explicitly covers 172.16.0.0/12, the WSL NAT subnet range.

WinHTTP

> netsh winhttp show proxy
Current WinHTTP proxy settings:
    Direct access (no proxy server).

(clean — nothing WinHTTP-related)

Winsock catalog (LSP chain)

All entries point to %SystemRoot%\system32\mswsock.dll (Microsoft). No third-party LSP.

Network filter drivers

Both vEthernet (WSL (Hyper-V firewall)) and WLAN expose only ms_* components (Microsoft's stock bindings). No
third-party filter driver on either adapter.

Services

Name          Status StartType
hns          Running    Manual
vmcompute    Running    Manual
SharedAccess Running    Manual      # ICS
WslService   Running Automatic

Hyper-V VM Firewall

Name                  : {40E0AC32-46A5-438A-A0B2-2B479E8F2E90}
Enabled               : NotConfigured
DefaultInboundAction  : Block
DefaultOutboundAction : Allow
LoopbackEnabled       : True
AllowHostPolicyMerge  : True

(Changing DefaultInboundAction to Allow had no effect on the failure.)

Event Log during failure (Microsoft-Windows-Hyper-V-VmSwitch-Operational)

Event ID 285, firing approximately once per minute:

V-Switch operation OID_GEN_STATISTICS (131334) took too long to complete.
  Operation Type     : OID HOST VNIC
  Execution time     : 0 ms
  Queued time        : 0 ms
  Expected execution : less than 0 ms
  NicName            : C08CB7B8-9B3C-408E-8E30-5E16A3AEB445
  NicFriendlyName    : Default Switch

This warning stream ceased after the cleanup + reboot.

WSL internal configuration (all clean, ruled out as cause)

• /etc/hosts — default WSL-generated, no extra entries
• /etc/nsswitch.conf — hosts: files mdns4_minimal [NOTFOUND=return] dns
• /etc/resolv.conf — symlink to /mnt/wsl/resolv.conf, auto-generated, points to upstream DNS
• /etc/netplan/ — empty
• No http_proxy / https_proxy / all_proxy variables anywhere in shell env or /etc/environment
• git config --global — no proxy settings

Windows Update history (10 days prior, excluding Defender definitions)

• 2026-04-15 : KB5083769 (26200.8246) — April SEC CU
• 2026-04-15 : KB5082417 (.NET)
• (no other non-Defender updates in the 7 days between CU install and failure onset)

wsl --version

WSL version: 2.6.3.0
Kernel version: 6.6.87.2-1
WSLg version: 1.0.71
MSRDC version: 1.2.6353
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.26200.8246

Related reports (same symptoms, suspected same underlying class of bug)

• #14393 — "Diagnostics complets WSL2 — Réseau cassé" (100% loss to gateway under 26200)
• #13714 — WSL service crashes during VM creation on 26200.7171
• #12297 — NAT → VirtioProxy fallback after system recovery
• anthropics/claude-code#27652 — HcnCreateNetwork ICS fails with 0x80070057 on 26200

Reproducibility note

I cannot currently reproduce on demand because the machine is now in a working state. If the team can provide a
Clash-or-equivalent test harness that toggles HKCU\...\Internet Settings\ProxyServer without clearing it on exit, on
Windows 11 25H2 26200.x with networkingMode=mirrored, I suspect the state is reproducible within 1–2 wsl
shutdown/restart cycles.

Start with the reported wsl --shutdown and .wslconfig networking-mode scenarios on Windows 11 25H2, using the HKCU Internet Settings values and diagnostic commands described here. Compare mirrored and NAT behavior around ARP, HNS endpoints, routes, and Event ID 285; done means stale disabled proxy values no longer break networking, or a clear failure diagnostic is emitted.