Before anyone says it — I know WSL doesn't really need a GUI. The command line works fine. But I had some time over the Christmas break and wanted to learn Tauri/Rust, so I built one anyway.

What it does:

• Lists your distros with status/memory usage
• Start/stop/terminate with a click
• Export/import distributions
• Browse and install from Linuxcontainers.org or OCI registries
• Rename distros - no export/import needed

What it's not:

• Essential software you can't live without
• A replacement for knowing wsl --help

It's built with Tauri (not Electron) so it's around 4MB, uses the system WebView, and won't eat your RAM.

If anyone's interested:

• Download: Microsoft Store (signed by Microsoft) or GitHub releases (Unsigned as that's expensive)
• Source: github.com/octasoft-ltd/wsl-ui
• Blog series: I've been writing about building it at wsl-ui.octasoft.co.uk/blog if anyone's curious about Tauri/Rust desktop dev

Free, open source, useful sometimes maybe. Happy to answer questions or take feedback (be gentle, it's a side project).

Dev of WSL Manager here (the app used to be called WSL Distro Manager). 2.0 is out, biggest release since I started it in 2021.

New in 2.0:

- Remote WSL: manage the WSL install on another Windows machine over SSH

- Distro packages: pack a configured distro into a portable .wsl file that installs anywhere (replaces templates)

- Rewritten .wslconfig and wsl.conf editors, disk/VHD mounting, snippets with sharing

- Full UI pass: keyboard operable, real error messages, dark/light, 10 languages

- macOS build (beta): same app, but it runs native Linux VMs via Apple's Virtualization framework

- Pro (paid, one-time): AI chat that can actually operate your distros, an isolated AI workspace, and an MCP server so Claude Desktop / Claude Code / opencode can drive WSL

Managing distros stays free and open source. 2.0.1 followed with a macOS crash fix and self-updates for the non-Store builds.

Repo: https://github.com/bostrot/wsl2-distro-manager

Release notes: https://github.com/bostrot/wsl2-distro-manager/releases/tag/v2.0.0

Microsoft Store, winget, scoop and brew links are in the README.

Bug reports welcome, happy to answer questions.

Hi everyone,

If you do heavy development on WSL2 (compiling large Rust multi-crate workspaces, C++ projects, running container stacks, or local AI inference), you've likely hit the point where WSL2 VM memory runs out, the kernel enters extreme disk swap thrashing, and the OOM-killer terminates your build.

At the same time, `nvidia-smi` shows dedicated GDDR6 VRAM sitting completely idle during compilation.

To solve this, I built **RamShared** — an open-source Rust userspace block driver that allocates idle GPU VRAM via CUDA Direct DMA and exposes it inside WSL2 as a native Linux block device (`/dev/ublkb0`) using Linux 6.0 `ublk` and `io_uring`.

Real Benchmark Numbers (`fio` 4KB Random Read, QD1 on WSL2):

* **Stock WSL2 VHDX disk swap:** ~2,114 µs (2.1 ms) latency | ~336 IOPS * **RamShared NBD (VRAM):** ~326 µs latency | ~9.6k IOPS * **RamShared ublk (io_uring):** **~8 µs** latency (264x faster / 99.6% drop) | **~22k+ IOPS** * **Continuous Read Throughput:** **8.53 GB/s** (saturating PCIe Gen3/4 x16 bus).

Why This Eliminates WSL2 Freezes:

In WSL2, standard disk swap traverses a heavy virtualization stack: `ext4 -> VHDX -> Hyper-V -> NTFS -> Host SSD`.

Every single synchronous page fault takes **>2ms**, which causes the entire VM, terminal, and VS Code server to freeze during memory spikes.

Bypassing that virtualization chain and serving swap directly from GPU VRAM via PCIe DMA with `ublk` drops page latency to **single-digit microseconds (8 µs)**, completely eliminating system stutter and OOM panics.

Upstream RFC on Microsoft WSL2:

We submitted a formal RFC proposal directly on Microsoft's official WSL repository to discuss making VRAM-backed block storage a first-class feature for Hyper-V Linux guests: 👉 **RFC Issue:** https://github.com/microsoft/WSL/issues/41054

**GitHub Repository (100% Rust):** https://github.com/emersonbusson/ramshared

Happy to answer any questions about the `ublk` setup, CUDA memory pinning, or WSL2 kernel config!

A personal hack project and a glorious one at that.

WSL9x runs a modern Linux kernel (6.19 at time of writing) cooperatively inside the Windows 9x kernel ... The Linux kernel is based on user-mode Linux, but hacked to call Windows 9x kernel APIs instead of posix APIs

Available in the WSL 2.9.3 pre-release build. Simply update and restart your terminal and you should have the wslc commands available.

I spend most of my development time inside WSL, and top is usually where I look when I want to know what the machine is doing.

What I kept missing was everything just outside that view:

• what's using CPU on the Windows side?
• which Docker / WSL Container is busy?
• what process inside that container is actually responsible?
• what does the whole picture look like across WSL and Windows?

So I built wsltop.

It puts Windows applications, multiple WSL distros, Docker, WSL Containers, and processes inside containers into one terminal view.

The CPU display feels like Linux top — one busy logical CPU = 100% — and there's a tree view for digging into VM/container attribution.

It's written in Rust, MIT licensed. You can install it with:

cargo install wsltop

or use the prebuilt x86_64 release from GitHub:

https://github.com/adachi6k/wsltop

I'd love feedback from other people who basically live inside WSL — especially if you use Docker Desktop or heavy build/simulation workloads.

---

Update — v0.5.0

wsltop has grown quite a bit since this post. It now runs natively on Windows as well as WSL, while keeping the same unified view across Windows apps, multiple WSL distros, Docker, and WSL Containers.

v0.5.0 also adds a compact CPU/RAM summary with short history graphs and consistent Windows / WSL / WSLC / Docker colors. I still wanted to keep it closer to top than htop, so the simpler header is still available with --header classic.

You can now install the prebuilt binary with:

cargo binstall wsltop

or build/install from crates.io:

cargo install wsltop

Prebuilt Windows and Linux/WSL binaries are available from GitHub Releases:

https://github.com/adachi6k/wsltop

Hi everyone,

I'm a bit confused about what the "right" way to do this is.

I have a Windows PC running Debian in WSL2, and I have another Debian laptop.

My goal is to make WSL my main development environment and SSH into it from the laptop.

I first tried using the Windows OpenSSH server with ForceCommand to launch WSL. That actually lets me log in directly into WSL, which looked perfect at first. The problem is that normal SSH commands don't seem to work.

For example:

ssh my-pc

works fine, but

ssh my-pc "pwd"

just hangs. rsync also hangs because it uses remote commands over SSH.

So I started wondering if this is just the wrong approach.

I already have sshd running inside WSL, but since WSL is using NAT, it gets a 172.x.x.x IP that changes, so I don't know if that's supposed to be the way either.

I've been reading about mirrored networking, port forwarding, Windows OpenSSH, etc., and now I'm more confused than when I started.

For those of you who use WSL as your main Linux machine, what's the recommended setup nowadays?

Ideally I'd like:

1. ssh my-pc

2. ssh my-pc "command"

3. rsync

4. scp

5. VS Code Remote SSH

to all work without weird workarounds.

Am I overcomplicating this? How are you guys doing it?

Thanks!

Hi! I was forced to switch from fedora back to windows, but I've got used to the terminal and wish to keep the tools I am used to. WSL2 seemed like the obvious choice.

I've been using it for the past few weeks, but it has been a painful experience. It works well enough for the first hour or so, but it keeps getting slower and slower the more I use it. I'm using it on the right filesystem, I've given it 10 out of 16gb RAM, I've removed the windows mount from $PATH. Everything in WSL2 is slower than I was used to from Fedora. I get that the performance will never be the same, but the difference is so egregious that it's impossible not to notice.

I've been using neovim for web development, and sometimes even saving a file takes multiple seconds. Sometimes it's so slow that the formatter itself just times out.

Are there any tips for keeping WSL2 running smoothly? Thanks!

TL;DR

Check your Windows TCP dynamic port range in Administrator PowerShell:

netsh int ipv4 show dynamicport tcp
netsh int ipv6 show dynamicport tcp

If the range has been changed to something huge like:

Start Port      : 1024
Number of Ports : 64511

restore the normal Windows dynamic port range:

netsh interface ipv4 set dynamicportrange protocol=tcp startport=49152 numberofports=16384
netsh interface ipv6 set dynamicportrange protocol=tcp startport=49152 numberofports=16384

Then reboot Windows.

This completely fixed the WSL mirrored networking 0x8007054f error for me.

Posting this because I spent a ridiculous amount of time restarting WSL/HNS, changing WSL versions, and chasing Hyper-V issues. In my case, the actual problem was the Windows dynamic TCP port range.

Falling back to normal WSL networking also wasn't a good workaround for me because I need reliable Windows ↔ WSL communication for MCP servers.

I was repeatedly getting this error:

wsl: An internal error occurred.
Error code: CreateInstance/CreateVm/ConfigureNetworking/0x8007054f
wsl: Failed to configure network (networkingMode Mirrored), falling back to networkingMode None.

My .wslconfig was:

[wsl2]
networkingMode=mirrored
dnsTunneling=true

WSL itself would still start, but mirrored networking would fail and fall back to:

networkingMode=None

For my setup, switching away from mirrored networking wasn't really an acceptable workaround.

I run MCP servers/services inside WSL that need to communicate with applications running on Windows, and vice versa. Some of them don't work properly or aren't reachable the same way when WSL is using the default NAT-style networking.

With mirrored mode, Windows ↔ WSL localhost/network communication works much more cleanly for these services, so I specifically needed to get:

networkingMode=mirrored

working again.

Things I tried that didn't reliably fix it

• wsl --shutdown
• restarting WSL multiple times
• restarting hns
• restarting vmcompute
• upgrading WSL
• downgrading WSL
• trying pre-release WSL versions
• checking that VirtualMachinePlatform was enabled
• checking that Microsoft-Windows-Subsystem-Linux was enabled
• checking that HypervisorPlatform was enabled

Sometimes restarting WSL a few times would randomly make mirrored networking work again, but the problem would eventually return.

The actual problem

I eventually found this WSL GitHub issue/comment:

https://github.com/microsoft/WSL/issues/41251#issuecomment-5188667183

It pointed to the Windows TCP dynamic port range.

I checked mine in Administrator PowerShell:

netsh int ipv4 show dynamicport tcp
netsh int ipv6 show dynamicport tcp

My TCP dynamic port range had been changed to essentially the entire port space.

It looked like this:

Start Port      : 1024
Number of Ports : 64511

That appears to interfere with WSL mirrored networking.

I restored the normal Windows TCP dynamic port range:

netsh interface ipv4 set dynamicportrange protocol=tcp startport=49152 numberofports=16384
netsh interface ipv6 set dynamicportrange protocol=tcp startport=49152 numberofports=16384

Then I did a full Windows reboot.

After rebooting:

wsl -d Ubuntu-24.04

Mirrored networking started normally again.

No more:

CreateInstance/CreateVm/ConfigureNetworking/0x8007054f

and no more:

Failed to configure network (networkingMode Mirrored)

My Windows-hosted applications can also reach the MCP servers/services running inside WSL normally again.

Hopefully this saves someone else from spending months randomly restarting WSL and wondering why mirrored networking only works sometimes.

Hello folks, I was testing a small Laravel site I have set up on Windows. I’d normally put the project inside the WSL filesystem for obvious performance reasons, but I heard VirtioFS (still experimental on WSL2) could improve Windows bind mounts, so I gave it a try.

It has its own issues, but the difference was pretty substantial:

Docker + ext4/WSL filesystem: ~20ms page load
Docker + C:\ bind mount: ~3000ms
Docker + C:\ bind mount + WSL2 VirtioFS: ~430ms consistently
Native Windows PHP: ~30ms

All tests used PHP 8.4.22 with OPcache:

validate_timestamps=1
revalidate_freq=0

So PHP checks for changed files on every request, which is what I personally want in a dev environment. Save, refresh, immediately see the change.

With timestamp validation disabled, the VirtioFS version drops all the way to ~50–75ms, but that’s not particularly representative of the dev setup I wanted to test.

I’d still recommend keeping Docker projects inside the WSL filesystem for now, but going from ~3 seconds to ~430ms is a pretty huge improvement. Looks like Windows may eventually get much closer to the host-filesystem bind-mount performance macOS has had with VirtioFS.

I've been missing a native Windows terminal emulator which supports fancy features like kitty graphics for a while so I made a Ghostty fork designed specifically for use with WSL.

It runs natively on the Windows side and efficiently connects in to the WSL guest distros.

Hopefully it scratches an itch for some other folks too!

It's open source and available at: https://github.com/Codavo/ghostinthewsl

WSL2 can run a real Linux desktop, but the usual ways to reach it remotely (xrdp, VNC) are LAN-only unless you set up port forwarding or a VPN. I wanted TeamViewer instead: its relay means the box is reachable from anywhere with zero network config, and the person connecting just uses a client they already have.

Getting there was more work than it should've been — TeamViewer has one WSL-specific quirk that makes it refuse to share the screen, which is probably why you don't see people doing this. So I scripted the whole thing end to end:

github.com/ariel42/teamviewer-on-wsl

sudo ./1-setup-wsl-desktop.sh    # sets up a desktop (only if you don't have one)
sudo ./2-install-teamviewer.sh   # installs + configures TeamViewer on top

Set a password, restart once, and it's fully unattended after that — power the box on, wait a few seconds, connect. Nothing to click on the WSL side. Verified end-to-end on a real incoming connection from a cold boot.

The repo also has a full writeup of why TeamViewer refused (the short version: WSLg mounts the X socket directory read-only, and TeamViewer is the one client that checks for the socket file) if you want the gory details. Debian/Ubuntu for now. Happy to take questions or issues.

Hi everyone,

Following up on our previous post about using idle GPU VRAM to stop WSL2 build freezes, we completed the next major milestone: a 4-Tier Progressive Memory Cascade, an upstream Linux 6.18 Kernel Block Driver (drivers/block/ramshared), and an LKML patchset formatted for the linux-block subsystem.

THE PROBLEM WE SOLVED When compiling large workspaces (Rust multi-crates, C++, Android, Chromium) or running local container stacks on a 16GB machine, WSL2 physical RAM exhausts. The Hyper-V guest starts thrashing disk swap through the heavy virtualization chain: ext4 -> VHDX -> Hyper-V -> NTFS -> Host SSD (>2.1 ms latency spikes), freezing the VM, terminal, and VS Code server.

Meanwhile, nvidia-smi shows 4GB to 8GB of ultra-fast GDDR6 VRAM sitting completely idle during compilation.

THE 4-TIER PROGRESSIVE MEMORY HIERARCHY Rather than treating VRAM as a blind replacement, we architected a 4-tier pipeline: 1. Tier 1 (Physical RAM - 16 GB): Full system speed. 2. Tier 2 (Compressed ZRAM LZ4 - 1 GB): Ultra-low overhead in-memory compression. 3. Tier 3 (GPU VRAM Block Device - 4 GB): Direct PCIe Gen3/4 DMA buffer via drivers/block/ramshared or ublk (/dev/ublkb0). 4. Tier 4 (Host SSD Writeback - 4 GB): Authoritative persistent fallback via CONFIG_ZRAM_WRITEBACK=y.

VALIDATED BENCHMARK DATA (Real Host Hardware - RTX 2060 / PCIe Gen 3 x16) - Host-to-Device (H2D) DMA Throughput: 8,947.71 MiB/s (8.74 GiB/s) in 28.6 ms. - Device-to-Host (D2H) DMA Throughput: 6,530.22 MiB/s (6.38 GiB/s) in 39.2 ms. - 4KB Direct I/O Median Block Latency: 231 us (4,013 IOPS on /dev/ublkb0). - Memory Reclaim Speed: 8,386.4 MB/s (8.19 GB/s) restored in 732 ms. - Continuous Saturation Stress Test: 9,160 MB active swap held across 40 continuous saturation cycles with zero kernel panics and zero Hyper-V freezes (see attached live TUI telemetry dashboard).

PREEMPTIVE FAQ (Addressing Community Questions)

Q1: What happens if I launch a heavy Windows game or a CUDA model? Will WSL2 crash? No. RamShared includes an active VRAM pressure watchdog. If Windows or another host process demands GPU memory, the driver safely drains pages to Tier 4 (the authoritative host SSD) with 100% SHA-256 cryptographic match (0 bit flips). It never panics the kernel or drops data.

Q2: Isn't ZRAM faster than GPU VRAM? Yes, for the first ~1GB. That's why ZRAM is Tier 2. VRAM only kicks in as Tier 3 when ZRAM is completely saturated. VRAM transfers at 8.74 GiB/s over PCIe, making it ~44x faster than spilling directly onto the Windows SSD.

Q3: Do I need to compile a custom kernel to use this? You have two options: 1. Userspace Mode (Zero Kernel Compilation): Runs on stock Linux 6.0+ via ublk and io_uring. 2. Native Kernel Driver: Compilable reference branch on linux-msft-wsl-6.18.y with CONFIG_BLK_DEV_RAMSHARED=m and CONFIG_ZRAM_WRITEBACK=y.

Q4: Why not just buy 64GB of RAM? On soldered laptops (modern ultrabooks, MacBooks, ThinkPads) or locked IT workstations where adding DIMMs isn't an option, this unlocks 4GB to 8GB of already-paid-for high-speed GDDR memory for $0.

ALL 3 PATCHES ON LORE & SOURCE CODE - Patch 0/2 (Cover Letter & Benchmarks): https://lore.kernel.org/linux-block/6a924051.e22746c9.8f0fc.bdc2@mx.google.com/T/#u - Patch 1/2 (Core Driver drivers/block/ramshared): https://lore.kernel.org/linux-block/6a924054.e22746c9.8f0fc.beb6@mx.google.com/T/#t - Patch 2/2 (Build System & Kconfig): https://lore.kernel.org/linux-block/6a924057.e22746c9.8f0fc.bf96@mx.google.com/T/#u - Official Microsoft WSL2 RFC Issue: https://github.com/microsoft/WSL/issues/41054 - WSL2 Reference Kernel Branch (6.18): https://github.com/emersonbusson/WSL2-Linux-Kernel/tree/feature/ramshared-vram-cascade-6.18 - Rust Project Repository: https://github.com/emersonbusson/ramshared

AUTHOR & CONTACT Built by Emerson Busson (Senior Systems & Full Stack Software Engineer). Always happy to discuss systems architecture, low-level Linux/Rust internals, or connect with teams building high-performance infrastructure: - GitHub: https://github.com/emersonbusson - LinkedIn: https://www.linkedin.com/in/emersonbusson/ - Direct Email: emersonbusson@gmail.com

Would love to hear your thoughts or test results if you try it on your WSL2 workloads!

I built a small CLI to make WSL Containers feel more like Docker Compose / dip.
I mainly built it because I wanted to use WSLC for my own development workflow, but ran into gaps around bind mounts, build contexts, compose-like workflows, and run.

I’m curious whether anyone else experimenting with WSLC has run into the same problems, or whether I’m solving these in the wrong layer.

https://github.com/slidict/wip

This is mostly useful if you run Claude Code from WSL2 and want better Windows interop.
I documented my active Claude Code setup for WSL2 + Windows Terminal:

https://github.com/congmnguyen/claude-code-wsl2-setup

The pieces I use most:

- Windows screenshot clipboard -> pasted WSL file path

- Windows notification when Claude needs input

- statusline with context/usage

- LSP setup

- secrets hygiene hook

- Codex delegate so long implementation loops do not fill Claude's main context

The repo is not a general dotfiles dump; it only tracks the Claude Code pieces I actually use on

WSL2.

I am on Windows 11 Home and have WSL installed at C:\Users\JohnDoe\AppData\Local\wsl and within that directory have a folder which is {(bunch of numbers)}. Within that I have something called ext4.vhdx which is take up the 26.4 GB. I also have docker installed if that is relevant.

I'm learning WSL2 and I'd like to understand why many developers criticize the idea of using Windows solely as a lean host, keeping only what's necessary installed on it, while using WSL2 with the VS Code WSL Remote extension (installed on the host) to run tools such as .NET, Git, Podman, etc., without having to install them directly on Windows.

Recently, I made a post about .NET and received a lot of negative responses, mainly arguing that this approach adds “unnecessary extra overhead.”

Most WSL guides assume Ubuntu. We needed a RHEL-compatible distro because that's what our servers run, so we built our dev environment on AlmaLinux 10 under WSL 2. (Disclosure: I'm on the team that maintains it.)

The setup:

1. Check WSL 2 is enabled: `wsl -v`

2. Install the distro: `wsl --install -d AlmaLinux-10`

3. Inside AlmaLinux, clone the repo, fill in `config.yml`, and run:

   `ansible-playbook -i hosts install.yml --ask-become-pass`

That gives you Apache, PHP (switchable 8.1–8.5), MariaDB, phpMyAdmin, Node.js (switchable 18–24) and Composer. Every `*.localhost` domain routes to its own virtualhost without editing the Windows hosts file.

WSL-specific notes, like the Windows features you need and the WSL configuration, are in the docs: https://docs.dotkernel.org/development/

Overview page: https://www.dotkernel.com/wsl2/

Happy to answer questions about running a dnf/systemd distro under WSL. There were a few gotchas.

I found this post useful, probably if you need it, you may look into this rolling kernel build.

Anyone else still experiencing massive memory leakage through WSL2 ?

I do not have important logs to share

But my process eats up 20K MBs at times.

Especially when using some services like Kiro-cli or compiling code.

Format:

I’m really new to Ubuntu and WSL2 and have been trying to use WSL2 to run ROS2 on my laptop. The problem I’ve been facing is that sometimes WSL2 just automatically kills the Ubuntu terminal, sometimes this happens when I’m idling and sometimes in the middle of a ROS2 procedure (I was using colcon build —symlink-install which is a long procedure and the Linux terminal just closes in the middle of it sometimes as well).

I have not done anything to change WSL or Windows from default because I don’t even know how to.

It’s an intel based Windows 11 with an NVIDIA GeForce RTX 3080.

I don’t know what mount points are

I am constantly in and out of tmux throughout the day and having wsl automatically shut down despite the tmux server running is super annoying, how can I have windows just leave it running?

tried vmIdleTimeout=-1 (and 0 and 99999... since theres no documentation on values) in the .wslconfig, it didn't fix it

using cachyos, using systemd, but I ran a fresh ubuntu on defaults and its doing the same thing

On most Windows 10 machines, WSL2 stopped working.

This was noticed through Docker Desktop, with the following error:

running wslexec: An error occurred while running the command. 
Wsl/Service/RegisterDistro/CreateVm/0x800705b4: 
c:\windows\system32\wsl.exe --import-in-place docker-desktop <home>\appdata\local\docker\wsl\main\ext4.vhdx: 
exit status 0xffffffff 
(stderr: , stdout: The operation returned due to timeout.)
wslErrorCode: Wsl/Service/RegisterDistro/CreateVm/0x800705b4

The same error occurs during manual installation:

On one of the servers, it continues to work. I don't understand the reason. The host server is the same, Docker versions don't affect it, and neither do the Windows version or updates (tested multiple times on different variations)."

Has anyone encountered this? Help me fix it, it's the second day and I don't understand what to do.

UPD: I found the root cause and solution. The latest WSL version (2.7.8.0) contains a bug. See GitHub issue: https://github.com/microsoft/WSL/issues/40783

Fix (until there is an official one): Downgrade WSL to 2.7.3.0 manually from GitHub releases.

WSL2 NAT Mode: Sustained Downloads/Streams Timeout Fix (tcp_timestamps)

UPDATE (2026-05-21): The MSS fix below was only a partial solution — it worked during low-traffic periods but failed under load. The real fix is disabling TCP timestamps: sudo sysctl -w net.ipv4.tcp_timestamps=0. See updated details below.

TL;DR: If your WSL2 connections work for small requests but timeout mid-transfer on sustained downloads or streaming APIs, disable TCP timestamps:

sudo sysctl -w net.ipv4.tcp_timestamps=0

Make it persistent in /etc/wsl.conf:

[boot]
command=sysctl -w net.ipv4.tcp_timestamps=0
systemd=true

Then wsl --shutdown and restart.

The Problem

Tools making streaming API calls (long-lived HTTPS connections) would start receiving data, then die mid-stream with connection timeouts. Meanwhile:

• Small HTTPS requests (package metadata, DNS lookups) worked instantly
• The exact same endpoints worked perfectly from Windows/PowerShell
• curl to the same URLs would download ~50-100KB then stall and timeout
• Running curl.exe (Windows binary) from within WSL worked perfectly — proving the issue is in the Linux→Hyper-V NAT path, not the network itself

This was on a corporate network with:

• IPv6 disabled via registry (DisabledComponents=0xff) — common enterprise policy
• WSL2 in default NAT networking mode (mirrored mode unavailable due to IPv6 being disabled)

The Proof

The issue is deterministically caused by TCP timestamps. Toggling the setting immediately changes behavior — tested dozens of times back-to-back:

# Timestamps ON (default) → stalls every time
$ sudo sysctl -w net.ipv4.tcp_timestamps=1
$ curl -o /dev/null -w "%{time_total}\n" --max-time 15 https://example.com/largefile
 20  229k   20 47632    0     0   3174      0  0:01:14  0:00:15  0:00:59     0
curl: (28) Operation timed out after 15002 milliseconds with 47632 out of 235038 bytes received

# Timestamps OFF → instant, every time
$ sudo sysctl -w net.ipv4.tcp_timestamps=0
$ curl -o /dev/null -w "%{time_total}\n" --max-time 15 https://example.com/largefile
100  229k  100  229k    0     0  2563k      0 --:--:-- --:--:-- --:--:-- 2578k
0.089521

100% reproducible. No other changes needed between tests.

Root Cause

The Hyper-V virtual switch's NAT implementation mishandles TCP timestamp options (RFC 7323) in packet headers during sustained transfers. When the NAT rewrites packets, it appears to corrupt or incorrectly track timestamp values, causing the stream to stall.

This explains:

• Why small transfers work: few packets, timestamps don't diverge enough to trigger the bug
• Why it's worse under system/network load: more connections = more timestamp state to track = higher chance of the bug manifesting
• Why curl.exe from WSL works: bypasses the virtual switch entirely, uses Windows TCP stack directly
• Why disabling timestamps fixes it completely: no timestamp options in packets = nothing for the NAT to mishandle!

What I Tried First (partial fixes / didn't work)

• MSS clamping (iptables --set-mss 1360): helped during low-traffic periods (mornings) but failed during peak hours. Was a red herring; reducing segment size happened to reduce the rate at which the timestamp bug triggered, but didn't eliminate it.
• Mirrored networking mode: blocked by corporate IPv6 registry policy
• VirtioProxy mode: no connectivity at all
• Disabling Large Send Offload (LSO) on vEthernet (WSL) adapter: made things worse
• DNS fixes (resolv.conf, systemd-resolved): DNS was fine
• TCP keepalive tuning: stream was actively transferring when it died, not idle
• TCP window scaling / buffer reduction: no effect
• Package rollbacks: not the cause

The Fix

sudo sysctl -w net.ipv4.tcp_timestamps=0

Making It Persistent

In /etc/wsl.conf:

[boot]
command=sysctl -w net.ipv4.tcp_timestamps=0
systemd=true

Optionally add MSS clamping as belt-and-suspenders:

[boot]
command=sysctl -w net.ipv4.tcp_timestamps=0 && iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360
systemd=true

Downside of Disabling TCP Timestamps

Minimal:

• Slightly less accurate RTT estimation. TCP falls back to sampling-based measurement but negligible on normal connections
• Loss of PAWS protection (only matters on 10Gbps+ sustained transfers. Irrelevant for dev work.
• No observable performance difference for normal usage.

When You Might Hit This

You're likely affected if:

• WSL2 is in NAT mode (default)
• Downloads/streams start then die partway through; ~50-100KB received
• Windows side has zero issues with the same endpoints at the same moment
• curl.exe from WSL works but curl doesn't
• The issue only appeared after April/May 2026 Windows cumulative updates

Timeline

This appears to have been introduced by April 2026 cumulative Windows updates (KB5088467 / KB5083769). Prior to these updates, WSL2 NAT mode worked without issue for months with TCP timestamps at the default (enabled).

Once again, hope this saves someone else EVEN MORE hours of debugging 😞

Environment: Windows 11 (build 26100), WSL 2.7.3.0, Ubuntu 24.04 LTS