Webserver & Datenbanken unter WSL2 (Apache, Nginx, MySQL, PostgreSQL)

Inhaltsverzeichnis

• Webserver & Datenbanken unter WSL2 verstehen

• WSL2 Performance-Falle: NTFS vs. ext4

• Nginx & Apache unter WSL2 installieren

• systemd aktivieren für produktionsnahen Betrieb

• MySQL unter WSL2 sicher konfigurieren

• PostgreSQL extern erreichbar machen

• Redis unter WSL2

• Lokale SSL-Zertifikate ohne Browser-Warnungen

• Mirrored Networking für stabile Verbindungen

• RAM- und Ressourcenmanagement in WSL2

• VPN- und DNS-Probleme zuverlässig lösen

• Fazit: Produktionsnahe Entwicklung unter Windows

Webserver & Datenbanken unter WSL2 verstehen

Warum dein lokaler Webserver unter Windows bisher wahrscheinlich lahmt – und wie wir das heute mit WSL2, echtem Mirrored Networking und einem High-Performance-Setup für Nginx, Apache, MySQL und PostgreSQL dauerhaft lösen.

Willkommen zu Teil 5 der Serie.
Jetzt geht es ans Herzstück deiner Entwicklungsumgebung. Vergiss XAMPP und WAMP. Wir bauen einen Stack, der sich so nah an der Produktion verhält, dass „It works on my machine“ endgültig Geschichte ist.

Die Performance-Falle: Warum dein Code auf /mnt/c/ stirbt

Bevor wir auch nur ein Paket installieren, müssen wir über das Filesystem sprechen.

Was mich am Anfang fast in den Wahnsinn getrieben hat:
Ich dachte, es sei clever, den Code unter C:\Users\Name\Projects zu lassen, damit Windows-Tools direkten Zugriff haben.

Ehrlich gesagt: Das ist technischer Selbstmord.

WSL2 greift auf Windows-Laufwerke über das Plan9-Protokoll (9P) zu. Bei vielen kleinen Dateioperationen – npm install, Composer, Datenbank-Migrationen – führt das zu massiven Verzögerungen (oft Faktor 20).

Klare Regel:

• Projektcode gehört immer ins native Linux-Dateisystem
  → /home/user/projects

• Zugriff von Windows aus über
  → \\wsl$\

Nur dort bekommst du echte ext4-Performance – und erst dann macht WSL2 wirklich Sinn.

Webserver unter WSL2: Nginx & Apache ohne Port-Lotto

Installation der Webserver

sudo apt update
sudo apt install nginx
sudo apt install apache2

Beide Server sind in Sekunden einsatzbereit.

Der klassische Stolperstein: Port 80 unter Windows

Wenn ein Dienst nicht startet, liegt das häufig nicht an Linux, sondern an Windows.
Der IIS („World Wide Web Publishing Service“) blockiert Port 80.

Prüfen unter Windows:

netstat -ano | findstr :80

Beende oder deaktiviere IIS – danach starten Nginx und Apache problemlos.

systemd aktivieren: WSL2 wie einen echten Server betreiben

Ein echtes Power-Feature, das viele übersehen.

Voraussetzungen prüfen

wsl.exe --version

Erforderlich: WSL ≥ 0.67.6

systemd aktivieren

# /etc/wsl.conf[boot]systemd=true

Danach WSL neu starten:

wsl.exe --shutdown

Ab jetzt verhält sich dein WSL wie ein echter Linux-Server:

• Dienste starten automatisch

• systemctl funktioniert wie erwartet

• kein Bastel-Setup mehr

Datenbanken unter WSL2: MySQL & PostgreSQL praxisnah einrichten

MySQL installieren und absichern

sudo apt install mysql-server
sudo mysql_secure_installation

Das Passwort-Dilemma

Moderne MySQL-Versionen nutzen caching_sha2_password.
Viele Windows-GUI-Tools (DBeaver, HeidiSQL) haben damit Probleme.

Praxislösung:

ALTER USER 'root'@'localhost' 
IDENTIFIED WITH mysql_native_password
BY 'secure_password';

Stabil, kompatibel, nervenschonend.

PostgreSQL installieren und extern erreichbar machen

sudo apt install postgresql

In der postgresql.conf:

listen_addresses = '*'

In der pg_hba.conf (Postgres ≥ 13):

host all all 172.0.0.0/8 scram-sha-256

Danach:

sudo systemctl restart postgresql

Jetzt können Windows-Tools sauber auf PostgreSQL zugreifen – ohne Sicherheitskompromisse.

Redis unter WSL2: Warum moderne Stacks ohne Cache lahmen

Was Redis ist – und warum du es brauchst

Redis ist eine In-Memory-Datenbank.
Im Gegensatz zu MySQL oder PostgreSQL liegt der Fokus nicht auf komplexen Abfragen, sondern auf extrem schnellen Lese- und Schreibzugriffen.

Typische Einsatzfälle in modernen Webprojekten:

• Cache für Datenbankabfragen

• Session-Storage (Symfony, Laravel)

• Queue-Backend (Jobs, Worker, Events)

• Rate Limiting

• Locking (z. B. bei parallelen Prozessen)

Real Talk:
Ohne Redis fühlt sich selbst ein sauberer PHP-Stack träge an. Mit Redis reagiert dieselbe Anwendung plötzlich „instant“.

Redis unter WSL2 installieren

sudo apt update
sudo apt install redis-server

Status prüfen:

sudo systemctl status redis

Test:

redis-cli ping

Erwartete Antwort:

PONG

Redis für lokale Entwicklung sinnvoll konfigurieren

Standardmäßig lauscht Redis nur auf 127.0.0.1.
Für lokale Entwicklung ist das richtig und sicher.

Wichtige Einstellungen in der redis.conf:

sudo nano /etc/redis/redis.conf

Empfohlene Defaults:

supervised systemd
maxmemory 256mb
maxmemory-policy allkeys-lru

Danach Redis neu starten:

sudo systemctl restart redis

Redis in PHP-Frameworks nutzen (Kurzüberblick)

Symfony:

• Cache

• Messenger

• Lock

• Session Handler

Laravel:

• Cache

• Queue

• Session

• Horizon

WSL2 + Redis = Produktionsparität, kein Mock-Setup.

Lokale SSL-Zertifikate ohne Browser-Warnungen

Warum HTTP heute keine Option mehr ist

Moderne Browser, APIs und Frameworks erwarten HTTPS.
HTTP-only-Setups führen zu:

• CORS-Problemen

• deaktivierten APIs (z. B. Geolocation, Service Worker)

• Browser-Warnungen

• unrealistischen Testbedingungen

Ziel:
Lokales HTTPS, ohne „Unsichere Verbindung“-Meldungen.

Die saubere Lösung: mkcert

Warum mkcert?

• Erstellt eine lokale Root-CA

• Zertifikate werden vom Browser vollständig vertraut

• Kein Self-Signed-Gefrickel

• Plattformübergreifend

mkcert unter WSL2 installieren

sudo apt install libnss3-tools

Binary laden:

curl -L https://github.com/FiloSottile/mkcert/releases/latest/download/mkcert-linux-amd64 \
-o mkcert
chmod +x mkcert
sudo mv mkcert /usr/local/bin/

Root-CA installieren:

mkcert -install

Lokales Zertifikat erstellen

mkcert myproject.local localhost 127.0.0.1 ::1

Erzeugt u. a.:

• myproject.local.pem

• myproject.local-key.pem

SSL mit Nginx unter WSL2 konfigurieren

Beispiel-VHost:

server {
    listen 443 ssl;
    server_name myproject.local;

    ssl_certificate     /home/user/certs/myproject.local.pem;
    ssl_certificate_key /home/user/certs/myproject.local-key.pem;

    root /home/user/projects/myproject/public;
    index index.php;

    location / {
        try_files $uri /index.php$is_args$args;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.5-fpm.sock;
    }
}

Nginx neu laden:

sudo nginx -t
sudo systemctl reload nginx

Windows-Seite: Domain auflösen

notepad C:\Windows\System32\drivers\etc\hosts

Eintrag:

127.0.0.1 myproject.local

Browser neu starten → grünes Schloss, keine Warnung.

Warum das wichtig ist (und oft vergessen wird)

Mit Redis + lokalem HTTPS erreichst du:

• realistische Performance

• identisches Verhalten wie in der Produktion

• weniger Überraschungen beim Deployment

• saubere API-Tests

• entspannte Browser-Sessions

Kurz gesagt:
Das ist kein „Nice-to-have“, sondern der Unterschied zwischen Bastel-Setup und Profi-Stack.

Networking unter WSL2: Schluss mit IP-Adressen-Bingo

Standardmäßig nutzt WSL2 NAT.
Ergebnis: wechselnde IPs, hostname -I, kaputte Tool-Konfigurationen.

Mirrored Networking aktivieren (Windows 11)

# %UserProfile%\.wslconfig
[wsl2]
networkingMode=mirrored
firewall=true

Hyper-V Firewall freigeben (Admin PowerShell)

Set-NetFirewallHyperVVMSetting `
-Name '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}' `
-DefaultInboundAction Allow

Ergebnis:
Webserver und Datenbanken sind stabil über localhost erreichbar – jedes Mal.

Das „vmmem“-Monster zähmen

Viele sehen im Taskmanager einen RAM-fressenden Prozess: vmmem.
Das ist der Linux Page Cache – technisch korrekt, praktisch nervig.

RAM begrenzen und automatisch freigeben

# .wslconfig
[wsl2]
memory=4GB

[experimental]
autoMemoryReclaim=dropCache

Damit bleibt Windows flüssig, selbst bei laufenden Datenbanken und Webservern.

VPN-Probleme unter WSL2 zuverlässig lösen

Corporate VPNs zerstören gerne die DNS-Auflösung in WSL2.

Lösung: resolv.conf manuell setzen

# /etc/wsl.conf
[network]
generateResolvConf=false

sudo nano /etc/resolv.conf

nameserver 8.8.8.8

Unschön, aber effektiv – und oft arbeitsrettend.

Produktivitäts-Boost: Sinnvolle Aliase

alias start-db='sudo systemctl start mysql'
alias stop-db='sudo systemctl stop mysql'
alias start-web='sudo systemctl start nginx'

Einmal in die .bashrc, und dein Alltag wird messbar entspannter.

Fazit: WSL2 richtig genutzt ist ein Formel-1-Motor

WSL2 ist wie ein Hochleistungsmotor.
Setzt du ihn auf NTFS-Reifen, verlierst du jedes Rennen.
Mit ext4, Mirrored Networking, systemd und sauberem Ressourcen-Limit hast du jedoch die potenteste Dev-Umgebung, die derzeit unter Windows möglich ist.