WSL 2 Webserver einrichten: Apache, Nginx & Datenbanken unter Windows

Dieser Artikel ist Teil unserer Serie zur modernen WSL 2 Webentwicklung.

WSL 2 Webserver einrichten: Apache, Nginx & Datenbanken verstehen

Kennst du dieses frustrierende Gefühl? Du sitzt an deinem Windows-Rechner, aber die Webentwicklung fühlt sich an wie ein Kampf gegen Windmühlen. Pfade stimmen nicht, Tools fehlen, die Konsole bockt. Es gibt einen Ausweg: Wir werden gemeinsam einen sauberen WSL 2 Webserver einrichten, der die Performance von Linux mit dem Komfort von Windows vereint.

Warum dein lokaler Webserver unter Windows bisher wahrscheinlich lahmt – und wie wir das heute mit WSL 2, 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.

WSL 2 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 WSL 2: 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: WSL 2 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 WSL 2: 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 WSL 2: 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 WSL 2 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

Praxis-Tipp: Lokale SSL-Zertifikate ohne Browser-Warnungen mit mkcert

Moderne Webentwicklung ohne HTTPS ist heute praktisch nicht mehr realistisch. Viele APIs, Browser-Features und Frameworks setzen eine sichere Verbindung voraus. Wer lokal noch mit HTTP arbeitet, testet an der Realität vorbei.

Mit mkcert erstellst du in wenigen Minuten eine eigene lokale Root-CA und kannst echte, vom Browser akzeptierte HTTPS-Zertifikate für deine Entwicklungsumgebung erzeugen.

Sauber, sicher, professionell.

Ziel dieses Setups

• HTTPS lokal ohne Warnmeldungen

• Keine „Unsichere Verbindung“

• Keine CORS-Sonderfälle

• Realistische Produktionsbedingungen

• Einmal einrichten, dauerhaft nutzen

Schritt 1: Voraussetzungen installieren

Zuerst stellen wir sicher, dass dein System alles hat, was mkcert benötigt:

sudo apt update
sudo apt install -y curl libnss3-tools

libnss3-tools ist wichtig, damit mkcert die CA auch direkt in Firefox eintragen kann.

Schritt 2: In das Home-Verzeichnis wechseln

Ganz wichtig: niemals direkt in /usr/local/bin herunterladen.

cd ~

Schritt 3: mkcert herunterladen (aktuelle Version)

curl -fL -J -O "https://dl.filippo.io/mkcert/latest?for=linux/amd64"

Jetzt prüfen:

ls -lh mkcert*

Die Datei muss ca. 6–8 MB groß sein, z. B.:

mkcert-v1.4.4-linux-amd64   7.2M

Wenn sie nur ein paar Bytes groß ist, war der Download nicht erfolgreich.

Schritt 4: Binary installieren

chmod +x mkcert-v*-linux-amd64
sudo mv mkcert-v*-linux-amd64 /usr/local/bin/mkcert

Test:

mkcert --version

Erwartete Ausgabe z. B.:

mkcert v1.4.4

Schritt 5: Lokale Root-CA erzeugen und installieren

Jetzt kommt der wichtigste Schritt:

mkcert -install

Dabei passiert:

• mkcert erstellt deine eigene Root-CA

• installiert sie ins System

• installiert sie in Chrome/Chromium

• installiert sie in Firefox

Ausgabe in etwa:

Created a new local CA 💥
The local CA is now installed in the system trust store! ⚡️
The local CA is now installed in the Firefox trust store! 🦊

Ab jetzt vertraut dein System allen Zertifikaten, die du mit mkcert erzeugst.

Schritt 6: Zertifikate für deine Projekte erzeugen

Wechsle in dein Projektverzeichnis oder in einen zentralen certs/-Ordner:

cd ~/projects/meinprojekt

Beispiele:

Nur localhost

mkcert localhost 127.0.0.1 ::1

Eigene Dev-Domain

mkcert meineapp.local api.meineapp.local

Ergebnis:

meineapp.local+2.pem       → Zertifikat
meineapp.local+2-key.pem   → Private Key

Diese beiden Dateien brauchst du im Webserver.

Schritt 7: Verwendung im Webserver (Beispiel: nginx)

Beispiel-VHost:

1server {
2    listen 443 ssl;
3    server_name myproject.local;
4
5    ssl_certificate     /home/user/certs/myproject.local.pem;
6    ssl_certificate_key /home/user/certs/myproject.local-key.pem;
7
8    root /home/user/projects/myproject/public;
9    index index.php;
10
11    location / {
12        try_files $uri /index.php$is_args$args;
13    }
14
15    location ~ \.php$ {
16        include snippets/fastcgi-php.conf;
17        fastcgi_pass unix:/run/php/php8.5-fpm.sock;
18    }
19}

Nginx neu laden:

sudo nginx -t
sudo systemctl reload nginx

Bonus: Wo liegt meine CA?

mkcert -CAROOT

Dort findest du:

• rootCA.pem

• rootCA-key.pem

Nützlich für Docker, Node.js oder CI-Setups.

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 WSL 2: 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 WSL 2 zuverlässig lösen

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

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: WSL 2 richtig genutzt ist ein Formel-1-Motor

WSL 2 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, wenn du einen WSL 2 Webserver einrichten möchtest.