Inhaltsverzeichnis

WSL2 für Webentwicklung 2025: Warum es der Standard ist
WSL2 Performance: Dateisystem, 9P und Best Practices
Node.js unter WSL2 verwalten: Versionen ohne sudo
PHP unter WSL2: Mehrere Versionen professionell nutzen
WSL2 Networking & VPN: Häufige Probleme und Lösungen
WSL2 Wartung: Updates, Cleanup und Stabilität
WSL2 Setup verstehen: Vom Bastelprojekt zur Entwicklungsumgebung
Ausblick: Webserver, Datenbanken & SSL unter WSL2

Einleitung: Vom Vorgeplänkel zur Produktionsreife

Während du noch auf dein npm install wartest, erreicht PHP 8.1 gerade sein Lebensende. Die bisherigen Teile dieser Serie waren nur das Fundament. Jetzt bauen wir das eigentliche Triebwerk: eine Entwicklungsumgebung, die sich exakt wie ein nativer Linux-Produktionsserver verhält.
Keine Abweichungen mehr zwischen lokalem Setup und Cloud-Umgebung. Keine Überraschungen beim Deployment.

Das Performance-Axiom: Warum 9P dein Feind ist

Das Kernproblem von `/mnt/c`

Projekte unter /mnt/c zu speichern wirkt praktisch, ist aber technisch fatal. Ursache ist das 9P-Protokoll, das WSL2 für den Zugriff auf das Windows-Dateisystem nutzt. Der dabei entstehende Overhead zerstört jede I/O-intensive Workflow-Performance.

Benchmarks aus der Praxis

npm install (React-App)
– /mnt/c: ca. 63 Sekunden
– natives ext4 (~): ca. 5,8 Sekunden
Symfony- und Laravel-Projekte
– auf NTFS: hohe Latenzen, potenzielle Timeouts
– auf ext4: nahezu native Linux-Performance

Klare Empfehlung für Projektpfade

Arbeite konsequent in Verzeichnissen wie ~/projects/. Moderne IDEs wie VS Code unterstützen diesen Workflow vollständig – dein Dateisystem wird es dir danken.

Node.js Management: Flexibilität ohne Sudo-Frust

Warum `apt install nodejs` ein strategischer Fehler ist

Die Versionen in den Ubuntu-Repositories sind oft veraltet. Zusätzlich erzwingen globale Pakete den Einsatz von sudo, was langfristig zu beschädigten Berechtigungen und schwer nachvollziehbaren Fehlern führt.

NVM als professioneller Standard

Der Node Version Manager (NVM) installiert Node.js versionsisoliert im Home-Verzeichnis. Dadurch entfällt sudo vollständig und mehrere Projekte mit unterschiedlichen Anforderungen lassen sich parallel betreiben.

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash

Shell neu laden (je nach Shell):

source ~/.bashrc
# oder bei ZSHsource ~/.zshrc

Installation prüfen:

command -v nvm
nvm --version

Sicherheits- und Versionsstrategie für 2025

Im Dezember 2025 wurden kritische Sicherheitslücken in Node.js entdeckt (u. a. HTTP/2, fs). Für eine sichere Entwicklungsumgebung sind aktuelle LTS-Versionen Pflicht, z. B.:

Node.js 22.12.0 (LTS)
Node.js 20.18.1

Mit NVM ist der Wechsel zwischen diesen Versionen trivial und risikoarm.

Aktuelle LTS-Version (empfohlen für neue Projekte):

nvm install 22.12.0nvm use 22.12.0

Alternative LTS-Version für Legacy-Projekte:

nvm install 20.18.1

Zwischen Versionen wechseln:

nvm use 20.18.1nvm use 22.12.0

Standard-Version festlegen:

nvm alias default 22.12.0

Verifikation:

node -v
npm -v

Das PHP-Ökosystem: Professioneller Multi-Version-Support

PHP unter WSL2 statt Windows-Binaries

PHP auf Windows war lange ein Kompromiss. WSL2 beendet dieses Kapitel vollständig und ermöglicht einen echten Linux-Stack ohne Abweichungen zur Produktion.

Repository von Ondřej Surý hinzufügen

sudo apt update
sudo apt install -y software-properties-common ca-certificates lsb-release apt-transport-https
sudo add-apt-repository ppa:ondrej/php
sudo apt update

PHP-Lifecycle und EOL-Fakten

PHP 8.1 hat am 31.12.2025 offiziell sein Lebensende erreicht. Moderne Hoster setzen inzwischen auf PHP 8.4 oder 8.5. Wer heute neu entwickelt, sollte diese Realität abbilden.

Mehrere PHP-Versionen parallel betreiben

Mit dem Repository von Ondřej Surý lassen sich mehrere PHP-Versionen sauber installieren und parallel nutzen:

PHP 8.3 für Bestandsprojekte
PHP 8.5 für neue Entwicklungen

Über update-alternatives steuerst du gezielt, welche Version in der CLI aktiv ist.

PHP 8.5 installieren (modernes Zielsystem)

sudo apt install -y \
php8.5 \
php8.5-fpm \
php8.5-cli \
php8.5-common \
php8.5-mbstring \
php8.5-curl \
php8.5-xml \
php8.5-zip \
php8.5-gd \
php8.5-intl \
php8.5-bcmath \
php8.5-opcache

PHP-Version prüfen:

php -v

Parallele PHP-Version (z. B. PHP 8.3 für Bestandsprojekte)

sudo apt install -y php8.3 php8.3-fpm

Aktive CLI-Version auswählen:

sudo update-alternatives --config php

Optional auch für Composer relevant:

sudo update-alternatives --config php-config
sudo update-alternatives --config phpize

Composer-Performance richtig absichern

Installiere zwingend unzip und git. Fehlen diese Tools, greift Composer auf langsame PHP-Fallbacks zurück – mit spürbaren Performance-Einbußen bei jedem Install- oder Update-Vorgang.

Composer sauber und performant installieren

Notwendige Tools (sehr wichtig):

sudo apt install -y git unzip curl

Composer installieren (offizieller Weg):

php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"php composer-setup.php
php -r "unlink('composer-setup.php');"sudo mv composer.phar /usr/local/bin/composer

Verifikation:

composer --version

Advanced Networking: Wenn das VPN den Workflow blockiert

Typische Probleme mit Corporate VPNs

VPN-Lösungen wie Cisco AnyConnect verändern das Routing aggressiv. Die Folge: WSL2 verliert plötzlich den Internetzugang oder DNS-Anfragen hängen.

Mirrored Networking Mode unter Windows 11

Der Mirrored Networking Mode ersetzt das klassische NAT-Setup und spiegelt die IP-Adresse des Windows-Hosts in WSL2.
Vorteile:

deutlich bessere VPN-Kompatibilität
stabile DNS-Auflösung
vollständige IPv6-Unterstützung

`.wslconfig` erstellen oder bearbeiten (Windows-Seite)

PowerShell (kein Admin nötig):

notepad $env:USERPROFILE\.wslconfig

Inhalt:

[wsl2]
networkingMode=mirrored

WSL vollständig neu starten:

wsl --shutdown

Danach WSL neu öffnen und testen:

ip addrping -c 3 google.com

Wartung und System-Hygiene

VHDX-Wachstum verstehen

WSL2-Festplatten wachsen dynamisch, schrumpfen aber nicht automatisch. Gelöschte node_modules reduzieren nicht die Größe der VHDX-Datei.

Regelmäßige Optimierung

WSL vollständig beenden (wsl --shutdown)
VHDX-Dateien mit Optimize-VHD komprimieren

WSL-Festplatte optimieren

WSL beenden:

wsl --shutdown

VHDX-Dateien finden:

Get-ChildItem "$env:LOCALAPPDATA\Packages" -Recurse -Filter ext4.vhdx

Optimieren (Admin-PowerShell):

Optimize-VHD -Path "C:\Pfad\zu\ext4.vhdx" -Mode Full

Defender-Ausschlüsse für Entwicklungsumgebungen

Schließe Projektverzeichnisse und VHDX-Dateien von der Windows Defender Echtzeitüberwachung aus. Jeder Dateiscan während composer install oder npm install kostet messbare Performance.

Defender-Ausschlüsse setzen (empfohlen)

Projektverzeichnis ausschließen:

Add-MpPreference -ExclusionPath "\\wsl$\Ubuntu\home\deinuser\projects"

VHDX-Datei ausschließen:

Add-MpPreference -ExclusionPath "C:\Users\DEINNAME\AppData\Local\Packages"

Status prüfen:

Get-MpPreference | Select-Object -ExpandProperty ExclusionPath

Zusammenfassende Performance-Metriken

npm install: Faktor ~10 schneller
Dateizugriffe bei 100k Dateien: Faktor >400
Symfony Cache Warmup: stabil und produktionsnah

Die Werkstatt-Analogie: Warum Details entscheidend sind

Ein WSL2-System ist wie ein Hochleistungsmotor. Setzt du ihn in das falsche Umfeld (NTFS, schlechtes Networking), wird er ausgebremst. Erst mit ext4-Dateisystem, sauberem Networking und regelmäßiger Wartung entfaltet er sein volles Potenzial.

Ausblick: Teil 5 der Serie

Im nächsten Teil geht es um das Drumherum:

Webserver mit Nginx
MySQL & PostgreSQL
lokale SSL-Zertifikate ohne Browser-Warnungen

#php

PHP & Node.js auf WSL2: Das Triebwerk für professionelle Workflows 2025