Varnish Cache & Nginx Reverse Proxy Architektur für DACH-Enterprise-Websites

Große Verlagsportale, B2B-Kataloge und stark frequentierte E-Commerce-Plattformen im deutschsprachigen Raum stoßen bei rein dynamischer PHP-Verarbeitung selbst auf leistungsstarken Dedicated Servern schnell an Grenzen. Wenn Hunderte parallele Nutzer gleichzeitig Produktseiten abrufen, steigen CPU-Last und TTFB steil an.

Die bewährte Enterprise-Lösung: Varnish Cache als In-Memory HTTP-Beschleuniger, flankiert von Nginx für TLS-Offloading und statische Assets.

1. Die Architektur: Port-Aufteilung & Datenfluss

Da Varnish nativ kein HTTPS unterstützt, fungiert Nginx als doppelter Partner:

1. Frontend Nginx (Port 443): Nimmt verschlüsselte HTTPS-Anfragen entgegen, terminiert SSL/TLS mit HTTP/2 und leitet sie unverschlüsselt an Varnish weiter.
2. Varnish Cache (Port 6081): Liefert gecachte HTML-Inhalte blitzschnell aus dem RAM (sub-15ms). Bei Cache-Miss Weiterleitung an Backend.
3. Backend Nginx + PHP-FPM (Port 8080): Führt dynamische PHP-Skripte aus und setzt Cache-Header.

Browser ──[HTTPS:443]──► Nginx (SSL Termination) ──[HTTP:6081]──► Varnish Cache
                                                                       │
                                                            (Cache Miss auf Port 8080)
                                                                       ▼
                                                             Nginx Backend + PHP-FPM

2. Nginx SSL-Termination Konfiguration

# /etc/nginx/sites-available/frontend-ssl.conf
server {
    listen 443 ssl http2;
    server_name www.ihre-domain.de;

    ssl_certificate /etc/letsencrypt/live/ihre-domain.de/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ihre-domain.de/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:6081; # Weiterleitung an Varnish
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }
}

3. Varnish VCL Konfiguration in /etc/varnish/default.vcl

Im VCL (Varnish Configuration Language) steuern wir das intelligente Caching von HTML-Dokumenten bei gleichzeitigem Schutz sensibler Session-Cookies:

vcl 4.1;

backend default {
    .host = "127.0.0.1";
    .port = "8080"; # Backend Webserver
    .first_byte_timeout = 60s;
}

sub vcl_recv {
    # 1. Bereinigung von Tracking-Parametern zur Maximierung der Hit-Rate
    if (req.url ~ "(\?|&)(utm_source|utm_medium|utm_campaign|gclid|fbclid)=") {
        set req.url = regsuball(req.url, "&(utm_[a-z]+|gclid|fbclid)=[^&#]*", "");
        set req.url = regsub(req.url, "\?(utm_[a-z]+|gclid|fbclid)=[^&#]*(&|$)", "?");
        set req.url = regsub(req.url, "\?$", "");
    }

    # 2. Niemals Admin- oder Login-Bereiche cachen
    if (req.url ~ "^/(wp-admin|admin|checkout|warenkorb|account)") {
        return (pass);
    }

    # 3. Wenn keine Session-Cookies vorhanden sind, Cookies entfernen für Caching
    if (req.http.Cookie !~ "(session|logged_in|PHPSESSID)") {
        unset req.http.Cookie;
    }

    return (hash);
}

sub vcl_backend_response {
    # 4. Standard Cache-Dauer auf 24 Stunden, wenn Backend 200 OK liefert
    if (beresp.status == 200) {
        set beresp.ttl = 24h;
        set beresp.grace = 1h; # Stale-while-revalidate bei Traffic-Spitzen
    }
}

sub vcl_deliver {
    # Debug-Header zur Verifikation
    if (obj.hits > 0) {
        set resp.http.X-Cache = "HIT (" + obj.hits + ")";
    } else {
        set resp.http.X-Cache = "MISS";
    }
}

4. Testen & Verifikation im Terminal

Starten Sie Varnish und testen Sie mit curl:

sudo systemctl restart varnish
sudo systemctl restart nginx

# Erster Aufruf: Cache-Miss
curl -I https://www.ihre-domain.de/
# Header: X-Cache: MISS

# Zweiter Aufruf: Sofortiger In-Memory Cache-Hit
curl -I https://www.ihre-domain.de/
# Header: X-Cache: HIT (1)

Mit dieser Architektur sinkt der TTFB von vormals 650ms auf sensationelle 11ms, während die CPU-Auslastung des Ursprungsservers selbst unter Spitzenlast nahe dem Leerlauf bleibt.

🔗 Zusammenhängende Systemdiagnosen & Infrastruktur-Geflecht:

Server- und Performance-Engpässe treten selten isoliert auf. Origin-Server-Latenzen, Datenbankstrukturen und Frontend-Metriken greifen direkt ineinander:

• Shopware 6 Performance Triage & Latenz-Beseitigung: Datenbank-Overhead und Cache-Invalidierung im deutschen E-Commerce lösen.
• Cloudflare Edge Caching & Tiered Cache DSGVO-konform einrichten: EU Data Localization und Origin-Schutz vor Bot-Crawls vereinen.
• Schema.org für GmbH & AG: Handelsregister im Knowledge Graph: Offizielle Unternehmensdaten und Zertifikate semantisch für Google verknüpfen.