Nginx vs. Caddy vs. Traefik: Welcher Proxy passt?

Nginx vs. Caddy vs. Traefik: die kurze Antwort

Nginx, Caddy und Traefik übernehmen als Reverse Proxy dieselbe Aufgabe: Sie lauschen an Port 443, lesen den Hostnamen jeder Anfrage und leiten sie an den richtigen Dienst auf Ihrem VPS weiter. Mit jedem der drei Produkte können Sie vier selbst gehostete Anwendungen hinter einer öffentlichen IP-Adresse betreiben. Alle sind schnell genug, sodass Ihre Anwendungen der langsamere Teil sein werden. Unterschiede gibt es bei der Beschaffung von TLS-Zertifikaten (Transport Layer Security) und beim Konfigurationsaufwand für jede zusätzliche Anwendung. Der andere Unterschied zeigt sich später, wenn Sie etwas benötigen, das die üblichen Tutorials auslassen.

Wählen Sie Caddy, wenn HTTPS für Sie verwaltet werden soll und es sich bei Ihren Diensten um gewöhnliche Webanwendungen handelt. Wählen Sie Traefik, wenn alles in Docker Compose läuft und Sie alle paar Wochen einen neuen Dienst hinzufügen. Wählen Sie Nginx, wenn Sie es bereits einsetzen oder wenn Sie Response-Caching, Client-Zertifikate, die Weiterleitung von unmodifiziertem TCP oder eine umfangreiche bestehende Konfiguration benötigen, die Sie nicht neu schreiben möchten.

Wie erhält jede Lösung ein TLS-Zertifikat?

Diese Achse entscheidet bei den meisten, beginnen Sie daher hier. Am Ende verwenden alle drei dasselbe Zertifikat derselben Zertifizierungsstelle. Der Weg dorthin ist jedoch unterschiedlich.

Caddy fordert das Zertifikat an, weil Sie einen Hostnamen angegeben haben. Tragen Sie app.example.com als Site-Adresse ein. Caddy fordert dann über ACME (automatic certificate management environment) ein Zertifikat von Let's Encrypt an, wechselt bei einem Fehler zu ZeroSSL, stellt die Weiterleitung von HTTP auf HTTPS über Port 80 bereit und erneuert das Zertifikat selbstständig. Sie benötigen kein zweites Tool und keinen Timer zur Prüfung. Zertifikate liegen bei einer Paketinstallation im Datenverzeichnis des Benutzers caddy, /var/lib/caddy/.local/share/caddy. Nehmen Sie diesen Pfad daher in Ihre Backups auf oder akzeptieren Sie nach einer Neuinstallation eine neue Ausstellung. Für einen Hostnamen, der nicht öffentlich erreichbar ist, signiert tls internal stattdessen mit Caddys eigener lokaler Zertifizierungsstelle. Das entspricht dem Erstellen eines selbstsignierten Zertifikats unter Ubuntu, wobei die Erneuerung automatisch erfolgt.

Nginx verfügt über keinen ACME-Client. Certbot beschafft das Zertifikat. Sein --nginx-Plugin schreibt Ihren Server-Block um und ergänzt den Listener für Port 443 sowie die Weiterleitung. Die Erneuerung wird über einen systemd-Timer ausgeführt, den das Paket installiert. Damit gibt es zwei beteiligte Komponenten und zwei Dinge, die Sie prüfen müssen: systemctl list-timers | grep certbot zeigt, dass der Timer vorhanden ist, und sudo certbot renew --dry-run bestätigt, dass der Erneuerungsablauf weiterhin funktioniert. Die einzelnen Schritte finden Sie unter Certbot unter Ubuntu 24.04 mit Nginx. Dasselbe Tool unterstützt auch ein Wildcard-Zertifikat über die DNS-01-Challenge, wenn Sie mehr Subdomains haben, als Sie auflisten möchten.

Traefik enthält einen eigenen ACME-Client. Konfigurieren Sie einen Zertifikats-Resolver in der statischen Konfiguration. Danach kann jeder Router diesen Resolver verwenden. Der gesamte Status, einschließlich Account-Key und Zertifikaten, liegt in einer einzigen acme.json-Datei. Traefik verweigert die Verwendung dieser Datei, wenn sie für andere Benutzer als den Eigentümer lesbar ist. Es meldet dies, bevor es den Resolver verwirft:

The ACME resolver "le" is skipped from the resolvers list because: unable to get ACME account: permissions 660 for /letsencrypt/acme.json are too open, please use 600

Binden Sie ein Verzeichnis ein und lassen Sie Traefik die Datei selbst erstellen. Erstellen Sie das Verzeichnis zunächst mit touch. Dabei wird Ihre umask übernommen, wodurch die meisten Benutzer diese Meldung vermeiden.

Eine Sache gilt für alle drei Lösungen. Die HTTP-01-Challenge benötigt Port 80, der aus dem Internet erreichbar sein muss, weil die Zertifizierungsstelle eine Verbindung dorthin herstellt. Wenn Sie nur Port 443 öffnen, schlägt die Ausstellung fehl und der Fehler wirkt wie ein DNS-Problem.

Dieselbe Routing-Aufgabe für zwei Anwendungen in drei Konfigurationen

Die Aufgabe: app.example.com wird an einen Dienst auf 127.0.0.1:8080 weitergeleitet, files.example.com an einen Dienst auf 127.0.0.1:8081. Beide Verbindungen verwenden HTTPS. Hier sehen Sie die vollständige Konfiguration für jeden Proxy. Dadurch wird der Unterschied im Umfang sichtbar und nicht nur behauptet.

Nginx

# /etc/nginx/sites-available/app.example.com
server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        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 $scheme;
    }
}

Verknüpfen Sie die Konfiguration anschließend, testen Sie sie, laden Sie Nginx neu und fügen Sie das Zertifikat hinzu.

sudo ln -s /etc/nginx/sites-available/app.example.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx
sudo certbot --nginx -d app.example.com

nginx -t, das syntax is ok und test is successful ausgibt, ist die Prüfung, die Sie vor jedem Reload ausführen sollten. Die zweite Anwendung verwendet denselben Block, wobei Hostname und Port angepasst werden. Die Zeilen mit proxy_set_header sind nicht bloße Dekoration: Wenn proxy_pass einen Hostnamen angibt, sendet nginx standardmäßig Host: 127.0.0.1:8080 an das Backend. Eine Anwendung, die absolute URLs aus dem Host-Header erzeugt, würde Ihre Benutzer dadurch an localhost weiterleiten. Welche Funktion die vier Header haben und warum ein abschließender Schrägstrich bei proxy_pass den Pfad, den Ihre Anwendung empfängt, unbemerkt ändert, wird in dieser Erläuterung eines nginx-Serverblocks Direktive für Direktive erklärt.

Caddy

app.example.com {
	reverse_proxy 127.0.0.1:8080
}

files.example.com {
	reverse_proxy 127.0.0.1:8081
}

sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy

Das ist die vollständige Datei. reverse_proxy setzt X-Forwarded-For, X-Forwarded-Proto und X-Forwarded-Host selbst. Standardmäßig ignoriert es die Werte, die der Client in diesen Headern gesendet hat. Eine Anfrage kann dem Backend daher nicht vortäuschen, von welcher Adresse sie stammt. Zertifikate, die Weiterleitung von Port 80 und die Erneuerung ergeben sich aus den beiden Site-Adressen. Keine weitere Einstellung in der Datei fordert diese Funktionen an.

Traefik

Traefik benötigt eine statische Konfiguration, bevor es Anfragen weiterleiten kann. Als Compose-Dienst mit dem im August 2026 aktuellen Image-Tag sieht sie so aus:

services:
  traefik:
    image: traefik:v3.7
    command:
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      - "--certificatesresolvers.le.acme.email=you@example.com"
      - "--certificatesresolvers.le.acme.storage=/letsencrypt/acme.json"
      - "--certificatesresolvers.le.acme.httpchallenge.entrypoint=web"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./letsencrypt:/letsencrypt

Anschließend erhält jede Anwendung ihre eigene Routing-Konfiguration über Labels in der jeweiligen Compose-Datei:

    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.app.rule=Host(`app.example.com`)"
      - "traefik.http.routers.app.entrypoints=websecure"
      - "traefik.http.routers.app.tls.certresolver=le"
      - "traefik.http.services.app.loadbalancer.server.port=8080"

loadbalancer.server.port ist der Port innerhalb des Containers und kein veröffentlichter Port, weil Traefik den Container über ein gemeinsames Docker-Netzwerk erreicht. Die Anwendung benötigt überhaupt keine Zeile mit ports:. Genau darin liegt der entscheidende Vorteil: Nur Traefik wird veröffentlicht. Die vollständige Einrichtung einschließlich des gemeinsamen Netzwerks und der Redirect-Middleware finden Sie unter Mehrere Anwendungen mit Traefik und Docker Compose weiterleiten.

Wie viel Konfiguration kostet jede zusätzliche Anwendung?

[
  {
    "tool": "Nginx",
    "proxy_setup_lines": 0,
    "lines_per_app": 11
  },
  {
    "tool": "Caddy",
    "proxy_setup_lines": 0,
    "lines_per_app": 3
  },
  {
    "tool": "Traefik",
    "proxy_setup_lines": 17,
    "lines_per_app": 5
  }
]

Aus den obigen Blöcken ergibt sich: Der Nginx-Server-Block umfasst 11 nicht leere Zeilen. Sie schreiben ihn für jeden Hostnamen erneut. Der Caddy-Site-Block umfasst 3 Zeilen. Traefik benötigt 17 Zeilen statischer Konfiguration, bevor es die erste Anfrage verarbeitet. Danach sind pro Anwendung 5 Labels erforderlich.

Betrachten Sie die Unterschiede, nicht nur den Sieger. Traefik verursacht vor der ersten Anwendung den größten Aufwand und danach pro zusätzlicher Anwendung den geringsten. Die beiden Summen gleichen sich ungefähr bei der dritten Site aus. Unterhalb davon ist die statische Konfiguration zusätzlicher Aufwand, den Sie nicht benötigen. Oberhalb davon liegen die Labels vorn und bauen ihren Vorsprung weiter aus, weil die Routing-Konfiguration neben dem Dienst liegt, auf den sie angewendet wird. Löschen Sie den Dienst, verschwindet auch seine Route. Genau das lässt sich mit einer zentralen Konfigurationsdatei schlecht abbilden: veraltete Server-Blöcke für Anwendungen, die seit Monaten nicht mehr existieren.

Die Zeilenzahl begünstigt Nginx außerdem. Für jeden dieser Blöcke benötigen Sie einen Symlink, ein nginx -t, einen Reload und einen certbot-Aufruf. Für eine Änderung an Caddy ist nur ein Reload erforderlich, bei Traefik ist überhaupt kein Befehl notwendig. Alle drei laden ihre Konfiguration neu, ohne bestehende Verbindungen zu trennen. Der Unterschied liegt in der Anzahl der einzelnen Schritte, an die Sie sich um ein Uhr morgens erinnern müssen.

Was weiß über Ihre Container Bescheid?

Traefik überwacht den Docker-Socket und erstellt Router anhand von Container-Labels, sobald Container gestartet oder beendet werden. Kein anderer der hier genannten Proxy-Server erledigt das. Nginx und Caddy benötigen beide eine Konfigurationsänderung und einen Reload, wenn ein neuer Container erscheint. Außerdem benötigen sie eine erreichbare Adresse: entweder einen auf Loopback veröffentlichten Port oder ein gemeinsames Docker-Netzwerk, mit dem der Proxy verbunden ist.

Diese Funktion hat einen Preis, der klar benannt werden sollte. Traefik liest /var/run/docker.sock. Jeder, der auf diesen Socket zugreifen kann, kann einen Container mit eingebundenem Host-Dateisystem starten. Damit erhält er root-Zugriff auf dem Host. Eine schreibgeschützte Einbindung verringert das Risiko, beseitigt es aber nicht. Wenn das für Ihr Bedrohungsmodell relevant ist, schalten Sie einen Socket-Proxy dazwischen. Dieser darf nur die Endpunkte für die Containerliste bereitstellen, die Traefik benötigt.

Caddy kann die Erkennung anhand von Labels über ein Community-Plugin durchführen. Caddy-Plugins werden jedoch einkompiliert. Sie müssen daher mit xcaddy eine eigene Binary oder ein eigenes Image erstellen und anschließend selbst für dessen Pflege und Updates sorgen. Bei drei oder vier Diensten ist das Bearbeiten einer Caddyfile weniger aufwendig.

WebSockets und Streaming: Was fehlschlägt und warum

Nginx benötigt dabei zusätzliche Konfiguration. Eine WebSocket-Verbindung beginnt als HTTP-Anfrage mit Upgrade: websocket. Nginx leitet Hop-by-Hop-Header jedoch nicht an das Upstream-System weiter, sofern Sie dies nicht ausdrücklich konfigurieren.

# /etc/nginx/conf.d/upgrade-map.conf
map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

Fügen Sie anschließend im Block location drei Zeilen ein. Alle drei müssen vorhanden sein:

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;

Wenn Sie diese Zeilen weglassen, zeigt die Browserkonsole WebSocket connection to 'wss://app.example.com/ws' failed an, während das Backend-Log eine gewöhnliche GET-Anfrage protokolliert. map ist erforderlich, weil ein fest gesetztes Connection: upgrade bei jeder Anfrage gesendet würde, auch bei gewöhnlichen Anfragen, die close enthalten sollten.

Zwei weitere Nginx-Standardeinstellungen können Probleme verursachen. proxy_read_timeout beträgt 60 Sekunden und gilt nach dem Upgrade auch für den Tunnel. Ein WebSocket ohne Datenverkehr wird daher nach einer Minute vom Proxy geschlossen. Server-Sent Events treffen verspätet oder in Bursts ein, bis Sie für diesen Location-Block proxy_buffering off; setzen. Nginx hält die Antwort in seinem Puffer zurück, während die Seite darauf wartet.

Caddy führt das Upgrade durch und wechselt ohne zusätzliche Direktiven zu einem bidirektionalen Tunnel. Außerdem leert Caddy den Puffer sofort, wenn die Antwort text/event-stream ist oder keine bekannte Länge hat. Dadurch funktioniert Streaming ohne weitere Anpassungen. Traefik leitet Upgrades weiter und puffert Antworten nicht, sofern Sie nicht selbst seine buffering-Middleware hinzufügen. Wenn Ihre Dienste Chat, ein Webterminal, Log-Tailing oder Live-Dashboards umfassen, macht das einen praktischen Unterschied beim Umfang der Konfiguration und der Fehlersuche.

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    listen 80;
    server_name app.example.com;
    client_max_body_size 64m;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        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 $scheme;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_read_timeout 3600s;
        proxy_buffering off;
    }
}

Was geschieht, wenn Sie etwas Ungewöhnliches benötigen?

Hier spielt Nginx seine zusätzlichen Konfigurationszeilen aus.

• Client-Zertifikate, auch mTLS (mutual TLS) genannt, bei denen der Client ebenfalls ein Zertifikat vorlegen muss. Nginx erwartet ssl_client_certificate /etc/ssl/ca.pem; und ssl_verify_client on; im server-Block. Caddy erwartet einen client_auth-Block innerhalb von tls. Mit Traefik-Labels lässt sich das überhaupt nicht ausdrücken: Sie definieren eine TLS-Option in einem File Provider und verweisen mit traefik.http.routers.app.tls.options=mtls@file vom Router darauf. Das Modell, bei dem alles über Labels erfolgt, erhält eine Ausnahme, sobald Sie diese Funktion benötigen.
• Große Uploads. Nginx begrenzt Request-Bodies standardmäßig auf 1 MB. Ein größerer Upload liefert 413 Request Entity Too Large, und das Error-Log enthält client intended to send too large body. Erhöhen Sie client_max_body_size. Caddy und Traefik setzen standardmäßig kein Body-Limit. Deshalb erreicht der Request Ihre Anwendung, und das anwendungseigene Limit entscheidet.
• Caching von Responses. Nginx verfügt über proxy_cache, und diese Funktion ist ausgereift. Für Caddy muss ein Plugin einkompiliert werden. Der Open-Source-Build von Traefik verfügt überhaupt nicht über einen HTTP-Cache. Das überrascht Anwender, die davon ausgehen, dass jeder Proxy cached.
• Unverarbeitetes TCP oder UDP, etwa für einen Datenbank-Port oder einen Gameserver. Nginx verfügt über das stream-Modul. Traefik hat eigene TCP- und UDP-Router auf separaten EntryPoints. Für Caddy wird ein weiteres Plugin benötigt, also ein weiterer individueller Build.
• Ein Webserver, der bereits hinter dem Proxy läuft. Wenn der Dienst eine klassische PHP-Anwendung ist, enthält ein LAMP-Stack auf Ubuntu 24.04 bereits Apache. Wenn Sie davor zusätzlich einen Proxy schalten, gibt es zwei Stellen, die Header setzen, und zwei Stellen, die eine URL umschreiben können. Entscheiden Sie, welcher Dienst TLS terminiert. Betreiben Sie den anderen anschließend über unverschlüsseltes HTTP, gebunden an Loopback.

Die folgende Firewall-Falle ergibt sich aus dieser Auswahl

Der Zweck eines Reverse Proxy besteht darin, nur Port 80 und 443 zu öffnen. Docker hebelt diese Einschränkung unbemerkt aus. Das Veröffentlichen eines Ports mit -p 8080:80 schreibt eine DNAT-Regel in die nat-Tabelle. Diese Regel wird vor den INPUT-Regeln ausgewertet, die ufw verwaltet. Deshalb blockiert ufw deny 8080 den Zugriff nicht. Ihre Anwendung ist dann neben dem sorgfältig konfigurierten Proxy direkt aus dem öffentlichen Internet erreichbar. Binden Sie veröffentlichte Ports mit 127.0.0.1:8080:80 an das Loopback-Interface. Alternativ können Sie ports: vollständig weglassen und den Proxy über ein Docker-Netzwerk auf den Container zugreifen lassen. Genau so funktioniert das Traefik-Beispiel weiter oben. Die Funktionsweise und die Lösung finden Sie unter warum von Docker veröffentlichte Ports ufw umgehen.

Testen Sie dies von einem Rechner, der nicht der VPS ist. Eine Prüfung, die direkt auf dem Server ausgeführt wird, ist immer erfolgreich:

curl --max-time 5 http://your.server.address:8080

Connection refused oder ein Timeout ist das erwartete Ergebnis. Eine HTTP-Antwort bedeutet, dass die Anwendung ohne Ihren Proxy erreichbar ist. Dann sind alle zuvor vorgenommenen Konfigurationen wirkungslos.

Welchen Proxy sollten Sie wählen?

Überwiegend statische Websites und zusätzlich ein oder zwei Anwendungen: Caddy. Automatisches HTTPS beseitigt die größte regelmäßig anfallende Aufgabe. Die Konfiguration bleibt kurz genug, um sie auf einem Bildschirm zu lesen, und eine statische Website besteht innerhalb desselben Site-Blocks aus einer root-Zeile und einer file_server-Zeile. Der Nachteil ist eine kleinere Auswahl an Antworten zum Kopieren und Einfügen, wenn etwas Unerwartetes ausfällt.

Ein docker-compose-Homelab, das Sie laufend erweitern: Traefik. Ab dem dritten Dienst verursachen Labels weniger Arbeit als die Bearbeitung einer zentralen Datei, und ein gelöschter Dienst nimmt seine Route mit. Planen Sie für die erste Einrichtung einen Nachmittag ein, da Entrypoints, Router, Services und Middlewares zunächst neue Begriffe sind. Ein Tippfehler in einem Label führt in der Regel zu einem 404 von Traefik und nicht dazu, dass der Dienststart fehlschlägt. Lesen Sie daher docker logs traefik auf den Parse-Fehler, bevor Sie annehmen, dass die Anwendung defekt ist.

Eine vorhandene Nginx-Konfiguration oder eine der oben genannten Anforderungen: Nginx. Nginx bietet bereits Lösungen für Response-Caching und Client-Zertifikate, und fast jede Anleitung eines Drittanbieters setzt Nginx voraus. Der Nachteil ist, dass Sie Zertifikate und WebSocket-Unterstützung konfigurieren müssen, statt sie automatisch zu erhalten.

Eine Regel gilt unabhängig von Ihrer Wahl. Genau ein Prozess lauscht auf der öffentlichen Schnittstelle. Alle anderen Prozesse lauschen auf Loopback oder in einem privaten Docker-Netzwerk.

FAQ

Welcher Reverse Proxy ist für einige Docker-Anwendungen auf einem VPS am besten geeignet?

Bei drei oder vier Diensten, die Sie nur gelegentlich hinzufügen, macht sich Traefik bezahlt, weil jede Anwendung ihre eigenen Routing-Labels enthält und Sie keine zentrale Datei bearbeiten müssen. Wenn die Dienste stabil sind und HTTPS hauptsächlich keine zusätzliche Arbeit verursachen soll, müssen Sie bei Caddy weniger lernen und können weniger falsch konfigurieren. Wählen Sie Nginx, wenn Sie damit bereits vertraut sind oder eine Funktion benötigen, die die beiden anderen nicht bieten, beispielsweise Response-Caching oder einen einfachen TCP-Listener.

Benötigt Caddy wirklich keine Zertifikatkonfiguration?

Im Normalfall: ja. Wenn Sie einen öffentlichen Hostnamen als Site-Adresse angeben, ist die Konfiguration bereits vollständig: Caddy fordert das Zertifikat über ACME an, stellt die Weiterleitung von Port 80 bereit und erneuert das Zertifikat vor Ablauf. Zwei Voraussetzungen müssen trotzdem erfüllt sein. Port 80 muss aus dem Internet erreichbar sein, damit die HTTP-01-Challenge funktioniert. Außerdem muss der DNS-A- oder AAAA-Record des Hostnamens bereits auf den VPS zeigen, weil die Zertifizierungsstelle den Namen auflöst und eine Verbindung zu diesem Host herstellt.

Kann ich Nginx und Traefik auf demselben VPS ausführen?

Nicht auf denselben Ports. Der Proxy, der als Zweiter startet, kann den Port nicht binden. nginx meldet bind() to 0.0.0.0:443 failed (98: Address already in use), während Traefik einen ähnlichen Bind-Fehler protokolliert und beendet wird. Lassen Sie einen Proxy auf 80 und 443 laufen und platzieren Sie alle anderen Dienste dahinter. Wenn Sie migrieren, verschieben Sie die Hostnamen einzeln. Lassen Sie den vorgeschalteten Proxy zunächst über einen Loopback-Port an den alten Proxy weiterleiten, bis die letzte Site umgezogen ist.

Warum werden meine WebSockets hinter Nginx nach 60 Sekunden getrennt?

proxy_read_timeout ist standardmäßig auf 60 Sekunden gesetzt und gilt für den Tunnel, sobald das Upgrade abgeschlossen ist. Eine Verbindung ohne Datenverkehr wird daher nach einer Minute vom Proxy und nicht von Ihrer Anwendung geschlossen. Erhöhen Sie den Wert für diese Location mit proxy_read_timeout 3600s; oder lassen Sie die Anwendung alle 30 Sekunden einen Ping-Frame senden. Caddy und Traefik schließen inaktive, per Upgrade hergestellte Verbindungen nicht nach einem Timer von einer Minute. Deshalb kann dieselbe Anwendung hinter diesen Proxys stabil wirken, hinter Nginx jedoch instabil.