Caddy oder NGINX: Automatisches HTTPS gewinnt nicht jeden Lasttest

Für kleine, selbst betriebene Dienste ist Caddy meist die einfachere Wahl: Es verbindet die Proxy-Konfiguration mit der Verwaltung öffentlich vertrauenswürdiger TLS-Zertifikate. Wer dagegen viele statische Dateien ausliefert oder bei einem stark genutzten API-Gateway eine enge p99-Latenz braucht, hat einen guten Grund, NGINX zu prüfen. Ein Lasttest zeigte Vorteile für beide Server – je nachdem, ob neue TLS-Verbindungen, Dateien oder Proxy-Anfragen gemessen wurden.

Der HTTPS-Schnellstart von Caddy zeigt einen Reverse Proxy, bei dem Domainname und Backend-Adresse genügen, damit Caddy ein Zertifikat bereitstellt. Die NGINX-Anleitung zur TLS-Terminierung setzt in ihrer Grundkonfiguration Zertifikat und privaten Schlüssel ausdrücklich voraus; Protokolle und Cipher Suites lassen sich gezielt einstellen. Der Unterschied betrifft damit vor allem die Einrichtung und Pflege der gewählten Konfiguration. Über den Durchsatz entscheidet zusätzlich die Last, die der Server tatsächlich verarbeitet.

Was der Lasttest tatsächlich vergleicht

Die Messreihe von SumGuy auf zwei CPU-Kernen testete NGINX 1.31.6 und Caddy 2.11.6 auf einem Rechner mit Docker-Bridge-Netzwerk. Sie verwendete HTTP/1.1, dasselbe selbst signierte TLS-Zertifikat und abgeschaltete Zugriffslogs. Caddys automatische Zertifikatsverwaltung war für den Versuch deaktiviert. Die Werte beschreiben also die Leistung dieser Konfigurationen, während der Aufwand für die Zertifikatsverwaltung gesondert zu beurteilen ist.

Bei einer neuen vollständigen TLS-1.3-Verbindung pro Anfrage erreichte Caddy 4.274 erfolgreiche Anfragen pro Sekunde, NGINX 3.531 – ein Vorsprung von rund 21 Prozent für Caddy. Gleichzeitig lag die p99-Latenz bei NGINX mit 32,1 Millisekunden unter Caddys 44,9 Millisekunden. Durchsatz und Antwortzeit am langen Ende der Verteilung benennen hier unterschiedliche Ergebnisse desselben Versuchs.

Bei einer kleinen Datei über HTTPS und wiederverwendeten Client-Verbindungen kehrte sich die Reihenfolge um: NGINX erreichte 79.169 erfolgreiche Anfragen pro Sekunde, Caddy 29.449. Bei der größeren getesteten Datei lagen die Werte mit 14.998 und 12.785 deutlich näher beieinander. Für den Reverse Proxy erfasste die Messreihe außerdem einen längeren Lauf sowie einen Versuch mit fest vorgegebener Anfragerate; dessen Ergebnisse hängen stark von der Wiederverwendung der Verbindungen zum Backend ab.

Die Dateiversuche liefen jeweils kurz und wurden mehrfach wiederholt, der längere Proxy-Lauf dagegen nur einmal je Konfiguration. HTTP/2, HTTP/3, Kompression und eine reale Netzwerkkarte gehörten nicht zum Test. Eine allgemeine Rangliste für jeden Produktionsserver lässt sich aus diesen Bedingungen nicht ableiten; für die drei Nutzungsprofile sind aber unterschiedliche Engpässe sichtbar.

Kleine Dienste: Wo Caddy Betriebsarbeit spart

Wenn eine öffentlich erreichbare Anwendung hinter einem Reverse Proxy stehen soll, nimmt Caddy einen wiederkehrenden Teil der TLS-Arbeit ab. Die Dokumentation zu Automatic HTTPS beschreibt die Beschaffung und Erneuerung geeigneter Zertifikate sowie die Weiterleitung von HTTP auf HTTPS. Dafür müssen unter anderem die DNS-Einträge zum Server zeigen, die benötigten Ports erreichbar sein und der Datenspeicher für Zertifikate dauerhaft beschreibbar bleiben. Die Automatik beseitigt diese Voraussetzungen nicht, bündelt aber ihre laufende Umsetzung im Webserver.

Das ist besonders bei mehreren kleinen Anwendungen nützlich: Kommt ein Hostname hinzu, muss die TLS-Bereitstellung nicht als eigener Ablauf neben der Proxy-Route gepflegt werden. Für lokale Namen stellt Caddy ebenfalls HTTPS bereit, verwendet dafür aber eine eigene Zertifizierungsstelle. Andere Geräte vertrauen deren Zertifikaten erst, wenn sie dem Stammzertifikat vertrauen. Ein lokal erfolgreicher HTTPS-Aufruf sagt deshalb noch nichts darüber aus, ob eine öffentliche Domain ein allgemein vertrauenswürdiges Zertifikat erhält.

NGINX ist dabei nicht auf manuelle Zertifikate festgelegt. Das offizielle ACME-Modul für NGINX ermöglicht automatisierte Ausstellung und Erneuerung, verlangt aber die Installation und Konfiguration des Moduls samt Aussteller und Zertifikatszuordnung. Bei einer bestehenden NGINX-Umgebung kann sich dieser zusätzliche Konfigurationsschritt anbieten. Für einen neuen kleinen Dienst bleibt Caddys direkt integrierte Automatik der kürzere Weg.

Der hohe Dateidurchsatz von NGINX aus dem Lasttest ist für dieses Profil nur dann ein Auswahlargument, wenn der Dienst selbst entsprechend viele Dateien ausliefert. Leitet er überwiegend gelegentliche Anfragen an eine Anwendung weiter, wiegen Einrichtung, Zertifikatserneuerung und zuverlässiger Betrieb häufig schwerer als seine theoretische Leistungsgrenze. Das ist eine Abwägung nach Aufgabenprofil, keine Aussage über die Geschwindigkeit jeder einzelnen Installation.

API-Gateway: Die Verbindung zum Backend wird entscheidend

Bei einem öffentlichen API-Gateway kann eine scheinbar einfache Proxy-Regel unter anhaltender Last zum Engpass werden. Im längeren Versuch eröffnete die direkte NGINX-Weiterleitung für Anfragen immer neue Backend-Verbindungen; nachdem lokale Ports belegt waren, lieferte diese getestete Konfiguration zahlreiche Fehler. Caddy verwendete Backend-Verbindungen wieder, hielt in der Standardkonfiguration jedoch nur einen begrenzten Pool freier Verbindungen. Unter der hohen Parallelität des Versuchs sank auch dort der Durchsatz, und es traten einige Fehler auf.

Erst die angepassten Routen erlauben den sinnvollen Vergleich der dort gemessenen Proxy-Leistung. Mit einem NGINX-Upstream, der Backend-Verbindungen wiederverwendete, erreichte der längere Lauf 22.153 erfolgreiche Anfragen pro Sekunde; mit vergrößertem Pool freier Verbindungen erreichte Caddy 18.048. Das Ergebnis gehört jeweils zur Verbindung aus Server, Proxy-Konfiguration und Test-Backend. Beim NGINX-Lauf begrenzte das Backend den erreichbaren Wert, sodass die Zahl keine allgemeine Obergrenze für NGINX darstellt.

Für Anforderungen an gleichmäßige Antwortzeiten ist der getrennte Versuch mit fester Anfragerate aufschlussreicher als der maximale Durchsatz. Dort lag die p99-Latenz des funktionsfähigen NGINX-Upstreams bei 0,68 Millisekunden, die der Caddy-Standardroute bei 2,52 Millisekunden. Der Testautor beobachtete allerdings Schwankungen in Caddys p99-Wert zwischen verschiedenen Sitzungen auf demselben Rechner. Wer für ein Gateway eine enge Latenzgrenze zusagt, sollte diese Streuung mit dem eigenen Backend und dem tatsächlichen Anfragemix berücksichtigen.

Eine hohe Zahl neuer TLS-Verbindungen zum Client beantwortet eine andere Frage als die Zahl wiederverwendeter Verbindungen zur Anwendung. Das erklärt, weshalb Caddys Vorsprung beim vollständigen Handshake nicht automatisch einen Vorteil als API-Proxy ergibt. Für dieses Profil zählen erfolgreiche Antworten, Fehler und p99-Latenz unter dauerhaftem Verkehr zusammen; ein Spitzenwert allein verdeckt mögliche Verbindungsprobleme.

Statische Dateien: Größe und Transport ändern den Abstand

Wer Dateien direkt vom Webserver ausliefert, findet in den Dateiversuchen die passendsten Vergleichswerte. NGINX lag über HTTPS bei beiden getesteten Größen vorn, doch der Vorsprung war bei der kleinen Datei erheblich größer. Viele kurze Assets auf begrenzter Rechenleistung sind deshalb ein konkreter Fall, in dem NGINX besonders interessant ist. Für größere Downloads lässt sich der Abstand der kleinen Datei nicht einfach fortschreiben.

Ein Teil der unterschiedlichen Ergebnisse hängt mit dem Transportweg zusammen. Im Test nutzte NGINX bei unverschlüsseltem HTTP für größere Dateien sendfile, das Daten aus dem Seitencache über den Kernel zum Socket bewegt. Bei der getesteten HTTPS-Auslieferung ohne Kernel-TLS musste der Server die Datei dagegen für die Verschlüsselung im Userspace verarbeiten; der Abstand zu Caddy schrumpfte. Diese Beobachtung erklärt die Richtung der gemessenen Werte besser als ein pauschaler Geschwindigkeitsvergleich der beiden Produkte.

Für eine stark belastete statische Auslieferung bleibt NGINX nach diesen Messungen der naheliegende Leistungskandidat. Wie groß sein Vorteil im Betrieb ausfällt, hängt jedoch von Dateigrößen, offenen Verbindungen und Funktionen wie Kompression ab, die der Versuch nicht abdeckte. Steht ein CDN vor dem Server, zählt außerdem die Last, die nach dessen Cache überhaupt noch beim Ursprung ankommt. Bei einem kleinen Reverse Proxy mit wenig Dateiverkehr kann dagegen die integrierte HTTPS-Verwaltung den Ausschlag für Caddy geben.

Lesen Sie auch:

• ChatGPT und Claude fielen zugleich aus – ein zweiter Anbieter genügt nicht
• OBS Studio oder Streamlabs: Im Test war der Leistungsvorteil gering
• Podcastwerbung zählt nicht mehr jeden YouTube-View gleich