WSL2-Tuning — Arbeitsspeicher, systemd, DNS, I/O in einem Durchgang

Wer WSL2 über die Windows-Ersteinrichtung installiert hat, führt als Nächstes das Tuning durch. Mit Standardeinstellungen zu laufen führt zu unkontrolliertem Arbeitsspeicherverbrauch, defektem DNS nach dem Neustart, aufgeblähter Festplatte und fehlendem systemd. Dieser Leitfaden deckt sieben Tuning-Schritte in einem Durchgang ab — einmal anwenden, täglich profitieren.

Zielgruppe: Windows 11 (22H2+) + WSL2 + Ubuntu (oder eine systemd-basierte Distro).

TL;DR

Voraussetzungen

• Windows 11 22H2 oder neuer (einige Funktionen bevorzugen 23H2+)
• WSL2 installiert + mindestens eine systemd-fähige Distro (Ubuntu usw.)
  • Nicht installiert: in Admin-PowerShell wsl --install
• Administratorrechte für wsl --shutdown empfohlen (.wslconfig selbst ist im Benutzerprofil)

1. .wslconfig — RAM/CPU/Swap-Limits

Standardmäßig kann WSL2 bis zu ~50 % des Windows-RAM belegen — ein großer Node-Build kann Windows selbst in den Swap treiben. Explizite Limits setzen.

1.1 Vorlage

# PowerShell
Invoke-WebRequest -Uri https://devalice.jaceclub.com/assets/windows/wsl-tuning/wslconfig-template.txt -OutFile $env:USERPROFILE\.wslconfig
Get-FileHash $env:USERPROFILE\.wslconfig -Algorithm SHA256
# erwartet: BFBDAF7AE486916D8AA4E792F9845416E1B6B6EA535F84E1BBCCA2BE9ACCB3C4
# (kleinschreibung: bfbdaf7ae486916d8aa4e792f9845416e1b6b6ea535f84e1bbcca2be9accb3c4)

1.2 Wichtige Einstellungen

# %USERPROFILE%\.wslconfig
[wsl2]
memory=8GB             # 50–75 % des Host-RAM
swap=4GB               # Festplatten-Swap (0 = deaktiviert)
localhostForwarding=true
guiApplications=true   # Linux-GUI-Apps (Win11-Standard)
# processors=8         # explizites CPU-Limit (optional)

1.3 Anwenden

wsl --shutdown   # alle WSL-Instanzen stoppen
wsl              # beim nächsten Start wird .wslconfig geladen

1.4 Prüfen

Innerhalb von WSL:

free -h          # Arbeitsspeicher-Limit passt (z. B. 8GB)
nproc            # CPU-Anzahl
swapon --show    # Swap aktiv

Eine 16-GB-Hostmaschine funktioniert gut mit memory=10GB. Eine 32-GB-Maschine: memory=16GB.

2. systemd aktivieren — /etc/wsl.conf

WSL2's Standard-Init ist kein systemd. Moderne Pakete (docker, snap, postgresql-Dienst usw.) erwarten es.

2.1 Aktivieren

# innerhalb von WSL (sudo erforderlich)
sudo nano /etc/wsl.conf

Inhalt:

[boot]
systemd=true
 
[user]
default=me          # Standardbenutzer (optional)

Speichern, dann:

# Windows PowerShell
wsl --shutdown
wsl

2.2 Prüfen

ps -p 1            # PID 1 == systemd → Erfolg
systemctl status   # systemd-Info angezeigt → OK

Jetzt funktionieren sudo systemctl start docker und Ähnliches ordnungsgemäß.

Die Boot-Zeit wächst um 1–3 Sekunden; dafür erhält man einen echten Dienst-Manager, Journal-Protokollierung und Tab-Vervollständigung.

3. DNS-Stabilität

WSL2's Standard-DNS läuft über eine Windows-NAT-Brücke, die oft nach VPN-Verbinden/-Trennen oder Neustart ausfällt. Symptom: curl github.com funktioniert, aber apt update nicht, oder umgekehrt.

3.1 Option A — Auto-DNS deaktivieren + statische Resolver

sudo nano /etc/wsl.conf

Hinzufügen:

[network]
generateResolvConf=false

Speichern → wsl --shutdown → Neustart.

Jetzt hört WSL auf, /etc/resolv.conf neu zu schreiben. Manuell setzen:

sudo nano /etc/resolv.conf

nameserver 1.1.1.1
nameserver 8.8.8.8

Im Unternehmensnetzwerk/VPN den internen DNS der IT hinzufügen.

3.2 Option B — Gespiegeltes Netzwerk (Win11 22H2+, empfohlen)

Abschnitt 7 lässt WSL Windows' DNS automatisch teilen. Am stabilsten im Unternehmens-VPN.

4. I/O-Leistung — wo man die Arbeit ablegt

Das am häufigsten übersehene Tuning. Die Leistung unterscheidet sich deutlich:

Regel: WSL-Arbeit lebt innerhalb der WSL-Festplatte. Wenn Windows dieselben Dateien braucht, VS Code Remote-WSL (§6) oder Syncthing (siehe Dateisync) verwenden, um Kopien auf beiden Seiten zu halten.

4.1 Gutes Muster

# innerhalb von WSL
mkdir -p ~/work
cd ~/work
git clone git@github.com:org/repo.git
cd repo
npm install              # schnell

4.2 Anti-Muster

# unter Windows klonen, über WSL bauen
cd /mnt/c/Users/me/Documents/project   # Cross-Mount
npm install                             # langsam (zehn Minuten)

4.3 Wenn Cross-Mount nötig ist

• Ein Windows-only-Tool muss denselben Ordner öffnen (Photoshop usw. — selten)
• Bearbeitung aus Windows-IDE — mit VS Code Remote-WSL lösbar

5. Festplattengröße — vhdx-Komprimierung

WSL's .vhdx-Festplatte verkleinert sich nie automatisch. Einen 30-GB-Cache bauen, löschen — die Datei bleibt bei 30 GB.

5.1 Aktuelle Größe prüfen

# PowerShell
Get-ChildItem -Path "$env:LOCALAPPDATA\Packages" -Recurse -Filter "ext4.vhdx" | ForEach-Object {
  "{0,-60} {1:N2} GB" -f $_.Directory.Name, ($_.Length / 1GB)
}

5.2 Option A — Sparse VHD (Win11 22H2+)

In .wslconfig (bereits auskommentiert in der §1.1-Vorlage):

[experimental]
sparseVhd=true

wsl --shutdown aktiviert es. Ungenutzter Platz wird schrittweise freigegeben.

5.3 Option B — manuelle Komprimierung (diskpart)

Während WSL heruntergefahren ist:

wsl --shutdown
 
diskpart
# diskpart>
select vdisk file="C:\Users\me\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu_*\LocalState\ext4.vhdx"
attach vdisk readonly
compact vdisk
detach vdisk
exit

Etliche GB wiedergewinnbar. Langsam — über Nacht laufen lassen.

5.4 Option C — Export/Import (am saubersten)

Vollständiges Backup + Neuerstellen. Die neue vhdx beginnt in optimaler Größe.

wsl --shutdown
wsl --export Ubuntu C:\backup\ubuntu.tar
wsl --unregister Ubuntu
wsl --import Ubuntu C:\WSL\Ubuntu C:\backup\ubuntu.tar

Option C ist am effektivsten, aber Instanz-ID / Installationsmetadaten werden neu erstellt. systemd-Konfiguration, Standardbenutzer usw. neu anwenden. Am besten während einer geplanten Migration.

6. VS Code Remote-WSL

WSL-Dateien aus Windows VS Code in nativer Geschwindigkeit bearbeiten. Die Standardantwort auf das Cross-Mount-Problem.

6.1 Installation

Im Windows VS Code Marketplace:

• Remote - WSL (ms-vscode-remote.remote-wsl)

Oder über die Befehlszeile:

code --install-extension ms-vscode-remote.remote-wsl

6.2 Verwendung

Innerhalb von WSL:

cd ~/work/repo
code .

→ Windows VS Code öffnet sich, unten links erscheint WSL: Ubuntu. Dateisystem, Terminal und Erweiterungen laufen alle innerhalb von WSL.

Alternativ in Windows VS Code: Befehlspalette → WSL: Connect to WSL → Ordner auswählen.

6.3 Erweiterungen, die auf der WSL-Seite installiert werden

Bei der ersten Verbindung fragen einige Erweiterungen „Auf WSL installieren?". Empfohlene Bestätigungen:

• ESLint / Prettier
• Python / Pylance
• Go / Rust-Analyzer
• Docker

7. Gespiegeltes Netzwerk (Win11 22H2+)

Eine elegantere Lösung als §3. WSL spiegelt Windows' Netzwerkinterface direkt — VPN, Unternehmensnetzwerk, DNS und localhost verhalten sich identisch zum Host.

7.1 Aktivieren

In .wslconfig:

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

wsl --shutdown und neu starten.

7.2 Wirkungen

• VPN — WSL geht automatisch durch das VPN
• Unternehmens-Proxy — Windows' IE/Edge-Proxy wird automatisch übernommen
• localhost — Windows ↔ WSL ist bidirektional (kein localhostForwarding nötig)
• DNS — wie Windows, am stabilsten

7.3 Einschränkungen

• Konflikte mit einigen Docker Desktop-Builds — vorübergehend deaktivieren bei Problemen
• Einige erweiterte Container-Netzwerkszenarien verhalten sich anders — verifizieren bei tiefgehender Container-Arbeit

Überprüfung

Die fünf Prüfungen:

1. Innerhalb von WSL zeigt free -h das Limit aus .wslconfig (z. B. 8,0 Gi)
2. ps -p 1 zeigt systemd
3. curl -sS https://www.google.com -o /dev/null && echo OK → OK (DNS/Netzwerk)
4. Sowohl cd ~ && touch test.txt && ls als auch cd /mnt/c/Users/$USER && touch test.txt && ls funktionieren (nur die Geschwindigkeit unterscheidet sich)
5. Aus VS Code zeigt code . WSL: Ubuntu unten links

Fehlerbehebung

.wslconfig-Änderungen werden nicht angewendet

• wsl --shutdown vergessen. Alle WSL-Instanzen müssen vollständig stoppen, bevor beim nächsten Start die Datei gelesen wird.
• Ort muss %USERPROFILE%\.wslconfig sein (eigenes Benutzer-Home), nicht %LOCALAPPDATA%.
• Dateiname muss .wslconfig sein (führender Punkt, keine Erweiterung).

Boot schlägt nach Aktivierung von systemd fehl

• Häufige Ursache: Syntaxfehler in /etc/wsl.conf (z. B. fehlender [boot]-Header).
• Wiederherstellung: aus PowerShell wsl -u root -d Ubuntu als Root betreten und /etc/wsl.conf reparieren.

apt update gibt DNS-Fehler zurück

• §3.1 anwenden (manuelle /etc/resolv.conf), oder zu §7 gespiegeltem Netzwerk wechseln.
• Im VPN sicherstellen, dass der Unternehmens-DNS hinzugefügt ist.

npm install ist unerträglich langsam

• §4 — man arbeitet aus /mnt/c/.... Zu ~/work wechseln.

VS Code Remote-WSL verbindet nicht

• code nicht im PATH. VS Code unter Windows einmal öffnen → Befehlspalette → Shell Command: Install 'code' command in PATH.
• Mit code -v innerhalb von WSL prüfen.

Docker Desktop bricht nach gespiegeltem Netzwerk

• Docker Desktop hat NAT-Modus angenommen. WSL-Integration neu konfigurieren, oder gespiegelten Modus bei Docker-Nutzung deaktivieren.

vhdx verkleinert sich nicht (§5)

• diskparts compact vdisk wird durch Fragmentierung begrenzt. Option C (Export/Import) ist am saubersten.

Referenzen

• Windows-Ersteinrichtung — WSL2 zuerst installieren
• Microsoft WSL — Konfiguration
• WSL-Ankündigung zum gespiegelten Netzwerk
• Sparse VHD-Ankündigung

Changelog

• 2026-05-12 — Erste deutsche Übersetzung (devAlice M2 i18n Seed)