Reverse Proxy Benchmark 2026: Caddy, Traefik, Nginx Proxy Manager und Zoraxy im Vergleich

Welchen Reverse Proxy du nimmst, entscheidest du meistens nach Bedienung: Weboberfläche, Textdatei oder Docker-Labels. Die Geschwindigkeit spielt selten eine Rolle, und das ist auch gut so. Trotzdem wollte ich wissen, wie viel Last diese vier Proxys auf einem kleinen VPS wirklich tragen und wo sie anfangen zu stolpern. Dazu habe ich Caddy, Traefik, Nginx Proxy Manager (NPM) und Zoraxy auf Servern gegeneinander laufen lassen, mit echtem HTTPS und mit Standardeinstellungen.

Ich frage nicht nach der maximalen Anfragerate, sondern wie viele Nutzer ein Server noch trägt, wenn die Antworten schnell genug bleiben. Ergänzt habe ich das durch Tests mit realistischer, fester Last, weil die Spitzenwerte allein nicht viel über den Alltag aussagen.

Ergebnis in Kürze

• Bei normaler Last sind alle vier gleich schnell. Bei 1.500 Anfragen pro Sekunde (entspricht etwa 15.000 gleichzeitigen Nutzern) antworten Caddy, NPM und Zoraxy auf einem 1-vCPU-Server im P95 in unter 2 ms.
• Bei den Spitzenwerten liegt Traefik vorn, Zoraxy dahinter, Caddy bei etwa der Hälfte von Traefik.
• Bei neuen TLS-Verbindungen entscheidet vor allem der Schlüsseltyp des Zertifikats. Die Standardwerte reichen von ECDSA P-256 (Caddy) bis RSA 4096 (Traefik) und verfälschen den Vergleich um bis zu Faktor 10.
• NPM hat in der Standardinstallation eine harte Grenze bei etwa 430 Anfragen pro Sekunde, weil es keine Verbindungen zum Backend wiederverwendet. Eine Zeile in der Compose-Datei hebt sie um den Faktor 20 an.
• Beim Speicher liegen zwischen Caddy (13 MB im Leerlauf) und Zoraxy (104 MB) fast Faktor 8.

Wie ich getestet habe

Server und Aufbau

Alle Server standen in Falkenstein im selben privaten Netzwerk, damit das Internet nicht mitmisst:

Den Proxy-Server habe ich zwischen den Läufen hochskaliert. Auf dem Server lief immer genau ein Proxy, die anderen waren gestoppt. Die Reihenfolge war NPM, Zoraxy, Traefik, Caddy. Schwankende Nachbarlast bei Hetzner kann ich deshalb nicht ausschließen.

Das Backend liefert zwei statische Dateien: eine JSON-Antwort mit 1 KB und eine Datei mit 1 MB. Ein langsames Backend würde den Proxy kaum noch sichtbar machen, deshalb habe ich es absichtlich trivial gehalten.

Die Proxys

Jeder Proxy lief als Docker-Container mit dem Image in fester Version und mit den Standardeinstellungen. Alle bekamen ein echtes Let’s-Encrypt-Zertifikat für ihre Domain und leiten per HTTPS an das Backend weiter:

Vor jedem Lauf prüft mein Skript, ob alle vier byte-genau dieselben Dateien ausliefern.

Lastgenerator und Kennzahlen

Die Last kommt von vegeta. Der Generator sendet mit konstanter Rate und wartet nicht auf langsame Antworten ab. So sehen wir auch, wenn ein Proxy in Rückstand gerät. Die Last verteilt sich auf zwei bis vier Lastgeneratoren, damit nicht der Generator zum Engpass wird.

Ein simulierter Nutzer erzeugt im Mittel 0,1 Anfragen pro Sekunde. 1.000 Anfragen pro Sekunde entsprechen also 10.000 Nutzern. Das ist eine Umrechnung und kein simuliertes Nutzerverhalten mit Wartezeiten.

Ein Test gilt als bestanden, wenn alle drei Bedingungen erfüllt sind:

• Die P95-Latenz liegt unter 500 ms.
• Die P99-Latenz liegt unter 1 Sekunde.
• Die Fehlerrate liegt unter 1 %.

Zusätzlich muss der Proxy mindestens 97 % der angeforderten Rate tatsächlich schaffen.

Die Suche nach dem Limit läuft als Binärsuche: Ich beginne mit einer niedrigen Rate und verdopple, bis ein Schritt scheitert, dann halbiere ich das Intervall bis auf 8 % Genauigkeit. Jeder Schritt dauert 30 Sekunden, die ersten 6 werden verworfen. Danach muss die gefundene Rate dreimal hintereinander für je 75 Sekunden bestehen. Scheitert ein Lauf, gehe ich 8 % herunter und beginne von vorn. Nach jedem gescheiterten Schritt warte ich 100 Sekunden, damit Ports und Verbindungstabellen sich leeren. Ohne diese Pause verfälscht ein überlasteter Schritt den nächsten.

Die drei Szenarien:

1. Kleine Antwort, Verbindungen bleiben offen. Der Normalfall: Browser halten Verbindungen offen, TLS wird nur einmal ausgehandelt.
2. Neue TLS-Verbindung pro Anfrage. Der Gegenpol: Jede Anfrage baut Verbindung und TLS-Handshake neu auf. Das ist hart, aber es zeigt, was passiert, wenn viele neue Besucher gleichzeitig kommen.
3. Eine 1-MB-Datei. Hier zählt der Durchsatz.

Szenario 1: Kleine Antwort über HTTPS

Alle Werte sind Anfragen pro Sekunde. Der Median ist die typische Antwortzeit genau bei dieser Rate. Mal zehn ergibt die Rate die Nutzer-Äquivalente. Traefik schafft auf 4 vCPU also bis zu 237.000 Nutzer-Äquivalente, Caddy etwa die Hälfte.

Ich habe zwei Beobachtungen, die ich dazuschreiben möchte:

• Traefik und Zoraxy stehen an ihrem Limit schon in der Warteschlange. Auf dem kleinen Server lag der Median dort bei 149 bzw. 229 ms, bei Caddy und NPM bei 1 ms (siehe Tabelle). Die Spitzenrate ist bei den beiden also ein Grenzwert, in dem der Proxy gerade noch besteht, und kein bequemer Dauerbetrieb.
• Caddy bricht am Limit abrupt ein. Bei 11.960 Anfragen pro Sekunde war der Server nur zu etwa 52 % ausgelastet, bei 14.000 fiel der Durchsatz plötzlich auf unter 2.000. Die Ursache habe ich nicht untersucht. Mein Verdacht ist ein Engpass beim Verbindungsaufbau zum Backend, bei dem Caddy in der Standardeinstellung nur wenige Verbindungen offen hält. Das habe ich nicht gemessen und gebe es deshalb als Vermutung an.

Szenario 2: Neue TLS-Verbindung pro Anfrage

Hier wirkt Traefik plötzlich schwach: 132 statt 6.440. Die Erklärung liegt nicht im Proxy, sondern im Zertifikat. Jeder Proxy stellt mit seinen Standardwerten einen anderen Schlüsseltyp aus:

Einen RSA-Schlüssel muss der Server bei jedem Handshake mit einer deutlich teureren Rechnung signieren als einen ECDSA-Schlüssel. RSA 4096 ist dabei deutlich langsamer als RSA 2048, das zeigen auch die Werte oben: Zoraxy (RSA 2048) schaffte 1.932, Traefik (RSA 4096) 600. Deshalb habe ich den Test mit demselben P-256-Zertifikat für alle vier wiederholt, und zwar mit einem selbst signierten Zertifikat, das ich in jedem Proxy hinterlegt habe:

Mit gleichem Zertifikat liegen alle vier eng zusammen. Für NPM habe ich hier tcp_tw_reuse gesetzt, weil sonst die Verbindungsgrenze aus dem nächsten Abschnitt den Vergleich verfälscht hätte.

Was heißt das für dich? Wenn ein Proxy bei dir beim Verbindungsaufbau langsam wirkt, prüfe zuerst den Schlüsseltyp. Traefik lässt sich in der Resolver-Konfiguration auf einen anderen Typ stellen (laut Dokumentation mit keyType: EC256). Das habe ich nicht getestet. Bei Caddy musst du nichts tun, dort ist ECDSA P-256 schon der Standard.

Szenario 3: Große Datei

Die Zahlen sind Anfragen pro Sekunde für die 1-MB-Datei. Für Heimserver ist das akademisch: Deine Leitung ist langsamer als jeder dieser Werte. Es zeigt aber, dass beim Durchreichen großer Antworten die Kernzahl zählt und Traefik auf einem einzelnen Kern nur etwa die Hälfte von Caddy schafft.

Skalierung von 1 auf 4 Kerne

Caddy, Traefik und Zoraxy skalieren bei kleiner Antwort fast linear: Mit vier Kernen schaffen sie das 3,7- bis 3,9-fache. Ein Upgrade von 1 auf 4 vCPU bringt dir bei diesen dreien also fast den vierfachen Durchsatz. Bei NPM bringt es in der Standardinstallation gar nichts, im Gegenteil, und dazu kommt der nächste Abschnitt.

Der NPM-Sonderfall: 430 Anfragen pro Sekunde

NPM schaffte auf dem kleinen Server 2.625 Anfragen pro Sekunde, auf dem großen nur noch 433, mit 502 Bad Gateway und diesem Eintrag im Fehlerlog:

connect() to 10.0.0.2:80 failed (99: Cannot assign requested address) while connecting to upstream

Die Ursache: NPM baut für jede Anfrage eine neue Verbindung zum Backend auf, statt Verbindungen wiederzuverwenden. Jede geschlossene Verbindung bleibt 60 Sekunden im Zustand TIME_WAIT und belegt einen der etwa 28.000 freien Ports des Containers. 28.000 Ports geteilt durch 60 Sekunden ergibt rund 470 neue Verbindungen pro Sekunde. Darüber gehen die Ports aus.

Dass der kleine Server trotzdem 2.625 schaffte, liegt an einer Eigenheit des Kerns: Linux erlaubt nur so viele TIME_WAIT-Einträge, wie der Arbeitsspeicher zulässt (tcp_max_tw_buckets). Bei 2 GB sind das 8.192, bei 8 GB sind es 32.768. Beim kleinen Server verwirft der Kern die Einträge deshalb sofort, und die Ports werden schnell wieder frei. Beim großen Server bleiben alle 60 Sekunden lang belegt.

Die Abhilfe ist eine Zeile in der Compose-Datei. Mit tcp_tw_reuse darf der Kern Ports aus TIME_WAIT wiederverwenden:

services:
  npm:
    image: jc21/nginx-proxy-manager:2.16.0
    sysctls:
      - net.ipv4.tcp_tw_reuse=1
    ports:
      - "80:80"
      - "443:443"
      - "81:81"

Damit stieg NPM auf dem großen Server von 433 auf 9.000 Anfragen pro Sekunde bei JSON und von 428 auf 3.864 bei neuen Verbindungen.

Realistische Last: Was verbrauchen die Proxys im Alltag?

Spitzenwerte sagen wenig über den Alltag. Deshalb habe ich jeden Proxy zusätzlich mit fester, moderater Last betrieben: 1.500 Anfragen pro Sekunde (15.000 Nutzer-Äquivalente) für je 2 Minuten, zweimal. Auf dem großen Server kamen 5.000 Anfragen pro Sekunde dazu.

Bei 1.500 Anfragen pro Sekunde und 1 vCPU:

Bei 4 vCPU und 1.500 Anfragen pro Sekunde:

Bei 5.000 Anfragen pro Sekunde auf 4 vCPU bleibt Caddy bei 29 % CPU und 29 MB RAM. Zoraxy braucht dann 46 % CPU und etwa 430 MB, Traefik 34 % CPU und etwa 610 MB. Bei NPM ohne die Einstellung scheitert die Hälfte der Anfragen.

Drei Dinge fallen auf:

• Bei alltäglicher Last gibt es keine echten Unterschiede. Alle vier antworten im Median in etwa einer Millisekunde.
• Der Speicherbedarf unterscheidet sich stark. Im Leerlauf belegen Caddy 13 MB, Traefik 22 MB, NPM 71 bis 74 MB und Zoraxy 104 MB. Unter Last wächst vor allem Traefik: bei 5.000 Anfragen pro Sekunde auf etwa 610 MB. Auf einem VPS mit 2 GB ist das spürbar, auf einem Server mit 8 GB egal.
• Traefik zeigt auf einem einzelnen Kern einen auffälligen P95 von rund 140 ms, obwohl der Median bei 1 ms liegt. Das trat bei 500 und 1.500 Anfragen pro Sekunde in allen vier Läufen auf. Auf 4 vCPU verschwindet es bei 1.500, bei 5.000 gab es im ersten Lauf noch einmal 118 ms. Ich habe die Ursache nicht gefunden. Wenn du Traefik auf einem Ein-Kern-Server betreibst, solltest du das im Blick behalten.

Was der Test nicht zeigt

• Das Backend ist absichtlich trivial. Mit einer echten Anwendung ist der Proxy fast nie der Engpass.
• Alles läuft in Docker mit Bridge-Netzwerk. Das kostet bei allen vier gleich viel, aber es ist nicht dasselbe wie ein Proxy direkt auf dem Host.
• Standardeinstellungen. Jeder der vier lässt sich abstimmen, ich habe nichts angepasst. Die zwei Ausnahmen sind das P-256-Zertifikat in einem Teil des Handshake-Tests und tcp_tw_reuse bei NPM.
• Eine Messung pro Größe und Proxy. Dazu kommen die drei Bestätigungsläufe. Ich rechne mit etwa 10 % Rauschen. Kleine Abstände zwischen den Proxys solltest du nicht überbewerten.
• Nicht gemessen habe ich HTTP/3, WebSockets, Neuladen der Konfiguration unter Last und mehrere Backends.
• Die Lastgeneratoren waren bei den meisten Läufen unter 40 % CPU. Beim Handshake-Test mit P-256-Zertifikat kamen sie auf bis zu 78 %. Dafür habe ich weitere Generatoren ergänzt.

Einen früheren Benchmark mit NPM, NPM+ und Zoraxy findest du im Beitrag Reverse Proxy Benchmark 2025. Er nutzt andere Werkzeuge und ein anderes Szenario, die Zahlen sind deshalb nicht direkt vergleichbar.

Was ich daraus mitnehme

Geschwindigkeit sollte bei dir selten den Ausschlag geben. Alle vier schaffen auf einem kleinen VPS ein Vielfaches dessen, was ein Heimserver oder eine kleine Webseite braucht. Wichtiger sind diese Punkte:

• Caddy ist mein Favorit, wenn du eine kurze Textdatei und wenig Speicherbedarf willst. Die Einrichtung steht im Beitrag Caddy Reverse Proxy mit Docker. Bei sehr hoher Last war Caddy in diesem Test langsamer als Traefik und Zoraxy, aber das merkst du erst bei Zehntausenden Nutzern.
• Traefik passt, wenn du Docker-Container automatisch erkennen lassen willst. Die Anleitung steht im Beitrag Traefik mit Docker. Plane etwas mehr Arbeitsspeicher ein und ändere bei Bedarf den Schlüsseltyp.
• Nginx Proxy Manager ist weiter die einfachste Wahl mit Oberfläche. Setze bei viel Last die sysctls-Zeile aus diesem Beitrag.
• Zoraxy ist schnell und hat eine Oberfläche, braucht aber im Leerlauf mehr Speicher als die anderen.

Wenn du keine eigene öffentliche IPv4-Adresse hast, hilft dir statt eines dieser Proxys ein Tunnel, zum Beispiel mit Pangolin.

Fazit

Die Geschwindigkeit ist bei diesen vier Reverse Proxys kein Auswahlkriterium für einen Homeserver. Selbst ein Server mit einem einzigen Kern trägt ein Vielfaches dessen, was du brauchst. Die echten Unterschiede liegen woanders: Caddy kommt mit am wenigsten Speicher aus, Traefik schafft die höchste Rate bei offenen Verbindungen, und bei NPM sollte jeder, der viele Anfragen erwartet, eine einzige Zeile in der Compose-Datei ergänzen. Die Werte beim TLS-Handshake zeigen vor allem, wie stark ein Standardwert wie der Schlüsseltyp eine Messung verändern kann.

Nutze den Proxy, dessen Bedienung dir liegt. Wenn du magst, schreib mir in die Kommentare, welchen du einsetzt und ob du bei dir schon einmal an eine dieser Grenzen gestoßen bist.