Caddy vs Nginx: Benchmark und Praxis mit 139 Websites (2026)

Caddy vs Nginx ist die Frage, die sich fast jeder stellt, der einen eigenen Server aufsetzt und davor einen Webserver oder Reverse Proxy braucht. Die Kurzfassung: Nginx ist schneller, sparsamer und seit zwanzig Jahren der Industriestandard. Caddy ist deutlich einfacher, holt HTTPS-Zertifikate komplett allein und hat die sichereren Voreinstellungen. Welcher der beiden besser ist, hängt fast nie an der Geschwindigkeit, sondern daran, wie viele Sites du betreibst und wie viel Zeit du in Konfiguration stecken willst.

Wir haben dazu eine ungewöhnlich gute Ausgangslage: Unser eigener Server läuft seit Monaten komplett auf Caddy, mit 139 Sites in einer einzigen Haupt-Konfigurationsdatei und knapp tausend automatisch verwalteten Zertifikatsdateien. Nginx kennen wir aus Jahren mit Shops und Kundenservern. Für diesen Artikel haben wir beide 2026 auf derselben Maschine nebeneinander gestellt und gemessen, statt Benchmarks von anderen abzuschreiben. Das Ergebnis ist eindeutiger, als uns als Caddy-Nutzern lieb war, und trotzdem bleiben wir bei Caddy. Warum, steht unten.

Das Video von HomeSec Explorer vergleicht Caddy, Nginx Proxy Manager und Traefik aus Homelab-Sicht mit echten Let’s-Encrypt-Zertifikaten. Ein guter Überblick, bevor wir in die Zahlen gehen.

Caddy vs Nginx: Die kurze Antwort

Wenn du nur einen Absatz lesen willst:

• Nimm Caddy, wenn du mehrere kleine bis mittlere Dienste unter vielen Domains betreibst, HTTPS ohne Nachdenken willst und die Konfiguration auch in einem Jahr noch verstehen möchtest. Für Selfhosting, Homelabs, Agentur-Server mit vielen Kundenseiten und Side-Projects ist Caddy die entspanntere Wahl.
• Nimm Nginx, wenn Leistung pro Euro wirklich zählt (sehr viel Traffic, sehr viele statische Dateien), wenn dein Team Nginx ohnehin kennt, wenn du ein Modul brauchst, das es nur für Nginx gibt, oder wenn Hoster, Framework-Dokumentation und Monitoring-Werkzeuge alle Nginx voraussetzen.
• Beides ist produktionsreif. Die Zeit, in der Caddy als Spielzeug galt, ist lange vorbei. Diese Seite hier wird gerade von Caddy ausgeliefert.

Falls du noch einen Schritt früher stehst und dich fragst, was ein Reverse Proxy überhaupt macht: Unser Artikel Was ist ein Reverse Proxy? erklärt das Prinzip von Grund auf. Und wer eigentlich zwischen den beiden Klassikern schwankt, findet in Apache vs. Nginx den passenden Vergleich.

Was Caddy und Nginx eigentlich sind

Nginx (ausgesprochen „Engine-X“) wurde Anfang der 2000er von Igor Sysoev geschrieben, um das sogenannte C10k-Problem zu lösen: zehntausend gleichzeitige Verbindungen auf einem Server, ohne für jede einen eigenen Prozess zu starten. Nginx ist in C geschrieben und arbeitet ereignisgesteuert: Ein Master-Prozess verwaltet mehrere Worker-Prozesse, meist einen pro CPU-Kern, und jeder Worker bedient tausende Verbindungen gleichzeitig. Heute gehört Nginx zu F5, es gibt eine freie Open-Source-Version und das kommerzielle Nginx Plus.

Caddy ist deutlich jünger. Matt Holt hat es 2015 veröffentlicht, die heutige Version 2 erschien 2020 als kompletter Neubau. Caddy ist in Go geschrieben und hatte von Anfang an ein Ziel, das damals radikal war: HTTPS als Standard, nicht als Zusatzaufgabe. Sobald du in der Konfiguration einen Domainnamen einträgst, besorgt Caddy selbst ein Zertifikat, verlängert es rechtzeitig und leitet HTTP auf HTTPS um. Es gibt kein Certbot, keinen Cronjob und keine Erneuerung, die man vergessen kann.

Beide können dasselbe Grundhandwerk: statische Dateien ausliefern, als Reverse Proxy Anfragen an Anwendungen weiterreichen, Last auf mehrere Backends verteilen, Antworten komprimieren und PHP über FastCGI anbinden. Der Unterschied liegt nicht darin, was sie können, sondern darin, wie viel du selbst dafür tun musst und was es kostet.

Unser Setup: Warum wir überhaupt Caddy einsetzen

Wir betreiben auf einem einzigen VPS eine Menge kleiner Dienste: diese Website, Tools, Dashboards, Testumgebungen, APIs für eigene Apps, einige statische Projektseiten. Jeder davon bekommt eine eigene Subdomain. Gezählt am Tag dieses Artikels:

• 1.027 Zeilen Caddyfile, davon 824 mit echtem Inhalt (ohne Leerzeilen und Kommentare)
• 139 Site-Blöcke, also Domains oder Subdomains
• 100 reverse_proxy-Anweisungen
• 991 Zertifikatsdateien unter /var/lib/caddy
• 85 erfolgreich ausgestellte oder erneuerte Zertifikate in den letzten 30 Tagen laut Journal
• 28 Tage am Stück ohne Neustart des Caddy-Prozesses, bei rund 100 MB Arbeitsspeicher

Diese 85 Zertifikate im Monat haben wir nicht angefasst. Keine einzige Zeile Certbot, kein Cronjob, keine Mail „Ihr Zertifikat läuft ab“. Bei Nginx wäre jede dieser 139 Sites ein eigener server-Block mit eigenen ssl_certificate-Zeilen, und Certbot müsste jede einzelne Domain kennen. Das geht, Tausende Server laufen so, aber es ist Arbeit, die bei jeder neuen Subdomain wieder anfällt.

Das ist der ehrliche Grund für unsere Wahl: Nicht Geschwindigkeit, sondern die Zahl der Domains. Bei einer einzigen großen Anwendung wäre der Vorteil klein. Bei 139 ist er der Unterschied zwischen „neue Subdomain in zwei Minuten“ und „neue Subdomain plus Zertifikatsverwaltung“.

Konfiguration: Caddyfile vs nginx.conf

Der sichtbarste Unterschied zwischen Caddy und Nginx ist die Konfiguration. Hier ein vollständiger Reverse Proxy mit HTTPS für eine Node-Anwendung auf Port 3000. Erst Caddy:

app.example.com {
	reverse_proxy 127.0.0.1:3000
}

Das sind drei Zeilen, und sie enthalten bereits: Zertifikat von Let’s Encrypt oder ZeroSSL, automatische Erneuerung, Umleitung von HTTP auf HTTPS, HTTP/2 und HTTP/3 sowie sinnvolle X-Forwarded-*-Header.

Das Gleiche mit Nginx, auf dem Stand, den man in der Praxis tatsächlich braucht:

server {
    listen 80;
    server_name app.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    http2 on;
    server_name app.example.com;

    ssl_certificate     /etc/letsencrypt/live/app.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;

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

Dazu kommt einmalig certbot --nginx -d app.example.com und die Kontrolle, ob der Erneuerungs-Timer läuft. Rund zwanzig Zeilen statt drei. Wichtig dabei: Die Nginx-Fassung ist nicht schlechter, sie ist nur expliziter. Jede Zeile steht da, weil du sie bewusst gewollt hast. Das ist Stärke und Schwäche zugleich. Du siehst genau, was passiert, aber du musst auch genau wissen, was fehlt.

Für unseren Benchmark unten brauchten wir eine identische Aufgabe für beide: ein Pfad für statische Dateien, alles andere als Reverse Proxy zu einem Backend. Ohne HTTPS, damit TLS das Ergebnis nicht überlagert. Die Caddy-Konfiguration hatte 12 Zeilen, davon fünf nur für den globalen Block, der die Admin-API und das automatische HTTPS für den Test ausschaltet. Die Nginx-Konfiguration hatte 22 Zeilen, obwohl wir sie so knapp wie möglich gehalten haben. Das Verhältnis von grob eins zu zwei zieht sich nach unserer Erfahrung durch fast alle Setups.

Die JSON-API von Caddy

Was im Vergleich oft untergeht: Das Caddyfile ist bei Caddy nur eine bequeme Oberfläche. Intern wird alles in JSON übersetzt, und Caddy hat eine Admin-API (standardmäßig nur auf localhost:2019), über die du die Konfiguration im laufenden Betrieb lesen und ändern kannst, ohne Neustart und ohne Verbindungsabbrüche. Für Plattformen, die automatisch Kunden-Domains anlegen, ist das ein echter Vorteil. Bei Nginx schreibst du Dateien und löst einen Reload aus. Das ist ebenfalls unterbrechungsfrei, aber eben ein Umweg über das Dateisystem.

Caddy vs Nginx im Benchmark: Unsere eigenen Messungen

Die meisten Benchmarks im Netz sind entweder Jahre alt oder stammen von jemandem, der eines der beiden Produkte verkauft. Wir haben deshalb selbst gemessen. Zuerst die Bedingungen, denn ohne sie sind Zahlen wertlos.

So haben wir gemessen

• Maschine: unser Entwicklungs-VPS mit 12 vCPUs und 23 GB RAM, auf dem nebenher der normale Betrieb weiterlief (Load um 2 vor dem Test)
• Versionen: Caddy v2.10.2, Nginx 1.24.0 aus den Ubuntu-Paketquellen
• Lastgenerator: wrk mit 4 Threads, 100 gleichzeitigen Verbindungen, 10 Sekunden pro Lauf, drei Durchgänge pro Szenario
• Szenario 1, statisch: eine 27 KB große Textdatei direkt vom Webserver
• Szenario 2, Reverse Proxy: eine winzige Node.js-Anwendung, die ein JSON-Objekt zurückgibt
• Alles über Loopback, ohne TLS, beide Server gleichzeitig laufend auf eigenen Ports
• Nginx mit worker_processes auto (12 Worker), sendfile on und einem Upstream mit keepalive 64, also so, wie man es für einen Proxy sinnvollerweise einrichtet
• Caddy in der Standardeinstellung, ohne jedes Tuning

Die Node-Anwendung schaffte direkt, ganz ohne Proxy davor, 38.341 Anfragen pro Sekunde. Das ist der Bezugspunkt für Szenario 2.

Die Ergebnisse

Die Durchgänge liegen jeweils eng beieinander, die Ergebnisse sind also kein Zufall. Bei den Latenzen dasselbe Bild: statisch im Mittel rund 0,5 ms bei Nginx gegen 1,6 ms bei Caddy, als Proxy 2,4 ms gegen 4 bis 5 ms.

Was die Zahlen bedeuten

Bei statischen Dateien ist Nginx rund doppelt so schnell. Das ist kein kleiner Vorsprung, das ist eine andere Liga. Nginx ist genau dafür gebaut, und zwanzig Jahre Optimierung in C merkt man.

Als Reverse Proxy schrumpft der Abstand auf etwa 30 Prozent. Hier verbringt die Anfrage ohnehin die meiste Zeit in der Anwendung, der Proxy ist nur ein Teil der Strecke. Auffällig und ehrlich gesagt überraschend: Nginx als Proxy war schneller als die Anwendung direkt (etwa 44.000 gegen 38.000). Unsere Vermutung: Nginx bündelt die 100 Client-Verbindungen auf maximal 64 dauerhaft offene Verbindungen zum Backend, und die einfädige Node-Anwendung kommt mit weniger gleichzeitigen Verbindungen besser zurecht. Beweisen konnten wir das in diesem Test nicht, deshalb steht es hier als Vermutung.

Wir haben in einem zusätzlichen Durchgang auch gemessen, wie viel CPU-Zeit die Server dafür verbrauchen. Das ist oft die wichtigere Zahl, weil sie bestimmt, wie viel vom Server für deine eigentliche Anwendung übrig bleibt:

Die Werte sind grob, weil ps die CPU-Zeit nur auf Sekunden genau ausgibt, aber die Größenordnung ist klar: Nginx braucht für dieselbe Arbeit etwa ein Drittel bis ein Viertel der CPU.

Speicher

Nach den Lasttests belegte der Test-Caddy rund 56 MB Arbeitsspeicher (PSS). Alle 13 Nginx-Prozesse zusammen, also Master plus 12 Worker, kamen auf rund 29 MB. Unser Produktions-Caddy mit 139 Sites und fast tausend Zertifikatsdateien liegt bei rund 100 MB. Für einen Server mit 4 GB RAM ist beides kein Thema. Auf einem sehr kleinen VPS mit 512 MB oder 1 GB wären die 50 bis 70 MB Unterschied spürbar, aber nicht entscheidend. Wie du den RAM-Bedarf deines Servers insgesamt einschätzt, beschreiben wir in Wie viel RAM braucht ein Server?.

Was wir bewusst nicht behaupten

• Kein TLS im Test. Im echten Betrieb kommt die Verschlüsselung dazu. Sie kostet beide Server Rechenzeit und verkleinert den relativen Abstand eher, messen konnten wir das hier aber nicht sauber.
• Lastgenerator und Server auf derselben Maschine. wrk hat sich die CPU mit den Servern geteilt. Absolute Zahlen sind deshalb niedriger als auf getrennter Hardware; die Verhältnisse zwischen Caddy und Nginx sind aber vergleichbar, weil beide dieselben Bedingungen hatten.
• Nginx 1.24 statt der neuesten Version. Wir haben genommen, was Ubuntu ausliefert, weil das auch die meisten Leser installieren werden.
• Kein Tuning bei Caddy. Nginx hatte eine sinnvoll eingerichtete Upstream-Verbindung, Caddy lief mit Standardwerten. Das bildet ab, wie beide typischerweise betrieben werden, ist aber kein Wettbewerb mit gleichen Waffen.

Und was heißt das für deine Website?

Die wichtigste Zahl ist nicht das Verhältnis, sondern die absolute Größe. Caddy lieferte über 67.000 statische Dateien pro Sekunde aus. Das sind rund 5,8 Milliarden Anfragen am Tag, auf einem Teil eines geteilten VPS. Eine normale Firmenwebsite, ein Blog oder ein kleiner Shop haben vielleicht ein paar Anfragen pro Sekunde, zu Spitzenzeiten ein paar Hundert. Der Webserver ist dort praktisch nie der Engpass, sondern die Datenbank, PHP oder die Anwendung dahinter.

Anders gesagt: Der Geschwindigkeitsunterschied ist echt, aber für die allermeisten Projekte irrelevant. Er wird relevant, wenn du ein CDN-ähnliches Setup mit sehr vielen statischen Dateien betreibst, wenn du tausende Anfragen pro Sekunde über einen Proxy schickst oder wenn Serverkosten bei großem Traffic eine echte Budgetzeile sind.

Cloud Codes zeigt den Umstieg von Nginx mit Certbot auf Caddy aus Sicht eines Entwicklers. Die Begeisterung teilen wir, die Leistungsfrage sieht nach unseren Messungen differenzierter aus.

Sicherheit: Wo Caddy die besseren Voreinstellungen hat

Beim Benchmark haben wir nebenbei geprüft, welche Header beim Backend ankommen. Wir haben dazu absichtlich einen gefälschten Header mitgeschickt: X-Forwarded-For: 6.6.6.6, so als würde ein Angreifer behaupten, er käme von dieser Adresse.

Bei Caddy kam im Backend "xff": "::1" an, also die tatsächliche Adresse des Clients. Caddy hat den gefälschten Wert ersetzt. Zusätzlich setzt Caddy den Header Via: 1.1 Caddy.

Bei Nginx mit der meistkopierten Zeile des Internets, proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;, kam "xff": "6.6.6.6, 127.0.0.1" an. Nginx hat den gefälschten Wert übernommen und die echte Adresse nur angehängt.

Das ist kein Nginx-Fehler, das Verhalten ist dokumentiert und bei Proxy-Ketten gewollt. Gefährlich wird es, wenn deine Anwendung einfach den ersten Eintrag der Liste als Client-IP nimmt. Dann kann jeder Besucher behaupten, er käme von einer beliebigen Adresse, und damit zum Beispiel ein IP-basiertes Rate-Limit oder eine IP-Sperre umgehen. Bei Nginx musst du das mit proxy_set_header X-Forwarded-For $remote_addr; oder dem realip-Modul bewusst lösen. Bei Caddy ist die sichere Variante die Voreinstellung; vertrauenswürdige Proxys davor (zum Beispiel ein CDN) trägst du mit trusted_proxies ausdrücklich ein.

Ein zweiter, kleinerer Unterschied: Caddy reichte den Host-Header unverändert samt Port weiter (localhost:18082), Nginx mit $host ohne Port (localhost). Wenn deine Anwendung absolute URLs aus dem Host-Header baut, kann das den Unterschied zwischen funktionierenden und kaputten Links machen.

Weitere Punkte zur Sicherheit:

• Speichersicherheit: Caddy ist in Go geschrieben, damit sind ganze Fehlerklassen wie Pufferüberläufe praktisch ausgeschlossen. Nginx ist in C geschrieben und hat eine sehr gute Sicherheitshistorie, aber eben mit dem Risiko, das C grundsätzlich mitbringt.
• TLS-Voreinstellungen: Caddy nutzt nur moderne Protokolle und Cipher, ohne dass du etwas einstellen musst. Bei Nginx hängt die TLS-Qualität davon ab, welche Vorlage du kopiert hast.
• Zertifikate laufen nicht ab: Das klingt banal, ist aber einer der häufigsten Gründe für Ausfälle. Caddy erneuert rund 30 Tage vor Ablauf und versucht es bei Fehlern automatisch erneut.
• Admin-API: Caddys Admin-API lauscht standardmäßig nur auf localhost. Das ist in Ordnung, aber du solltest wissen, dass es sie gibt. In unserem Benchmark haben wir sie mit admin off abgeschaltet.

Eine Firewall ersetzt keiner der beiden. Ein Reverse Proxy verringert die Zahl der offenen Türen, verriegelt aber nicht die anderen. Wie du einen Server von Anfang an sauber aufsetzt, zeigen wir in Linux-Server einrichten.

Ein Stolperstein aus dem Test: Wer liest eigentlich deine Dateien?

Beim ersten Versuch lieferte Nginx unsere Testdatei gar nicht aus, sondern antwortete mit 403 Forbidden. Caddy lieferte dieselbe Datei aus demselben Ordner problemlos. Das Fehlerlog sagte: open() "/tmp/bench/www/test.txt" failed (13: Permission denied).

Die Ursache war lehrreich: Wir hatten beide Server als root gestartet. Der Caddy-Prozess lief dann komplett als root. Nginx dagegen startet nur den Master-Prozess als root und lässt die Worker, die tatsächlich die Dateien lesen, als unprivilegierten Benutzer laufen, ohne user-Anweisung als nobody. Unser /tmp-Verzeichnis ist auf diesem Server nur für root lesbar, also durfte nobody die Datei nicht öffnen.

Zwei Lehren daraus:

1. Ein 403 bei Nginx ist fast immer ein Rechteproblem, nicht ein Konfigurationsfehler. Prüfe mit namei -l /pfad/zur/datei, ob der Worker-Benutzer jeden Ordner auf dem Weg betreten darf.
2. Die Rechtetrennung von Nginx ist ein Sicherheitsmerkmal. Caddy sollte man genauso wenig als root laufen lassen. Die offiziellen Pakete richten dafür einen eigenen Benutzer caddy ein, so läuft auch unser Produktionsserver. Unser Test-Caddy als root war bequem, aber für den Produktivbetrieb falsch.

PHP, WordPress und Shopware: Caddy vs Nginx bei klassischen Anwendungen

Viele Leser wollen keine Node-Anwendung, sondern WordPress, Shopware, Nextcloud oder Laravel betreiben. Beide Server binden PHP über PHP-FPM an. Bei Caddy ist das eine Zeile:

shop.example.com {
	root * /var/www/shop/public
	php_fastcgi unix//run/php/php8.3-fpm.sock
	file_server
	encode zstd gzip
}

php_fastcgi enthält bereits die typischen Umschreibregeln für Frameworks mit einem zentralen index.php. Bei Nginx schreibst du einen location ~ \.php$-Block mit fastcgi_pass, fastcgi_param SCRIPT_FILENAME und einer try_files-Regel. Das ist gut dokumentiert, aber auch eine klassische Fehlerquelle.

Ehrlich muss man sagen: Für Shopware, Magento und viele große PHP-Anwendungen liefern die Hersteller Nginx-Beispielkonfigurationen, selten Caddy-Varianten. Wer bei Problemen im Hersteller-Forum fragt, wird fast immer nach der Nginx-Konfiguration gefragt. Das ist ein echter Grund, bei solchen Anwendungen bei Nginx zu bleiben, vor allem wenn mehrere Menschen den Server betreuen. Bei unseren eigenen Shopware-Projekten nutzen wir deshalb Nginx, bei unseren eigenen Tools Caddy.

Docker: Caddy vs Nginx im Container

Beide gibt es als offizielle Docker-Images, beide funktionieren gut vor Containern. Der Unterschied liegt wieder im Aufwand:

• Caddy braucht im Container ein Volume für /data, damit Zertifikate einen Neustart überleben. Vergisst du das, holt Caddy bei jedem Neustart neue Zertifikate und läuft irgendwann in die Rate-Limits von Let’s Encrypt. Das ist die mit Abstand häufigste Caddy-Falle in Docker-Setups.
• Nginx braucht im Container einen zusätzlichen Weg für Zertifikate, meist einen Certbot-Container oder ein Volume mit Zertifikaten vom Host. Der beliebte Nginx Proxy Manager löst genau dieses Problem mit einer Weboberfläche.

Wenn deine Container ständig kommen und gehen, lohnt sich ein Blick auf Traefik, das Dienste über Docker-Labels selbst erkennt. Für ein paar feste Dienste in einer Compose-Datei ist Caddy meist am unkompliziertesten. Ein vollständiges Beispiel mit mehreren Diensten findest du in unserem Artikel zu Docker Compose.

Module und Erweiterungen

Nginx hat das größere Ökosystem: Lua über OpenResty, ModSecurity als Web Application Firewall, Brotli, GeoIP, RTMP für Streaming und viele mehr. Viele davon sind dynamische Module, die du nachladen kannst, manche musst du einkompilieren.

Caddy wird über Plugins erweitert, die mit dem Werkzeug xcaddy in die Binärdatei einkompiliert werden. Beliebt sind DNS-Provider-Module (für Wildcard-Zertifikate über die DNS-Challenge), Rate-Limiting, Coraza als WAF und Layer-4-Proxying. Der Download-Bereich der Caddy-Website baut dir auf Wunsch eine Binärdatei mit den gewünschten Plugins. Der Haken: Plugins bedeuten eine eigene Binärdatei, die du selbst aktualisieren musst, statt einfach das Paket aus den Quellen zu nehmen.

Ein Caddy-Merkmal ohne echtes Gegenstück bei Nginx ist On-Demand TLS: Caddy holt ein Zertifikat erst in dem Moment, in dem die erste Anfrage für eine unbekannte Domain eintrifft, nachdem es bei deiner Anwendung nachgefragt hat, ob die Domain erlaubt ist. Für SaaS-Plattformen, bei denen Kunden eigene Domains verbinden, spart das enorm viel Infrastruktur.

Betrieb im Alltag: Logs, Reload, Fehlersuche

Ein paar Dinge, die man erst nach einigen Monaten merkt:

• Reload: Beide laden Konfigurationsänderungen ohne Verbindungsabbruch neu (systemctl reload caddy bzw. nginx -s reload). Caddy prüft die neue Konfiguration dabei vollständig und behält bei Fehlern die alte. Bei Nginx solltest du vorher immer nginx -t laufen lassen.
• Formatierung: caddy fmt --overwrite formatiert das Caddyfile einheitlich. Bei 1.000 Zeilen ist das Gold wert.
• Logs: Nginx schreibt klassische Textlogs, die jedes Werkzeug versteht. Caddy schreibt standardmäßig strukturierte JSON-Logs. Die sind maschinell hervorragend auswertbar, mit bloßem Auge aber mühsamer. Wir werten unsere Caddy-Logs zum Beispiel aus, um zu sehen, welche KI-Crawler uns besuchen.
• Fehlersuche: Für nahezu jede Nginx-Fehlermeldung gibt es eine Antwort im Netz. Bei Caddy findest du oft eine gute Antwort im offiziellen Forum, aber seltener fünf verschiedene auf Stack Overflow.
• Eine große Datei oder viele kleine: Caddy unterstützt import, um das Caddyfile aufzuteilen. Wir nutzen es genau einmal, für eine separat gepflegte Domainliste; alles andere steht aus Bequemlichkeit in einer großen Datei. Mit 139 Sites ist das grenzwertig, aber mit einer guten Suche im Editor erstaunlich handhabbar.

Migration von Nginx zu Caddy

Wenn du umsteigen willst, gehe schrittweise vor:

1. Caddy auf anderen Ports testen. Stelle Caddy parallel neben Nginx, zum Beispiel auf Port 8080, und prüfe jede Site mit curl -H "Host: deine-domain.de" http://127.0.0.1:8080/.
2. Site für Site übersetzen. Die meisten server-Blöcke schrumpfen auf drei bis zehn Zeilen. Umschreibregeln (rewrite, try_files) brauchen am meisten Aufmerksamkeit.
3. Zertifikate bedenken. Caddy holt beim Umstieg für jede Domain ein neues Zertifikat. Bei sehr vielen Domains auf einmal kannst du die Rate-Limits der Zertifizierungsstelle treffen, deshalb lieber in Etappen umziehen.
4. Header prüfen. Wie oben gezeigt, reichen Caddy und Nginx Host und X-Forwarded-For unterschiedlich weiter. Teste Logins, Weiterleitungen und alles, was die Client-IP nutzt.
5. Ports tauschen. Nginx stoppen, Caddy auf 80 und 443 lauschen lassen, Nginx aber noch einige Tage installiert lassen, um schnell zurückzuwechseln.

Der umgekehrte Weg, von Caddy zu Nginx, ist genauso möglich. Der Hauptaufwand liegt dann in der Zertifikatsverwaltung, die du selbst einrichten musst.

Caddy vs Nginx: Entscheidungshilfe nach Szenario

Wenn du gerade erst einen Server mietest und noch nicht weißt, welche Art, hilft dir unser Vergleich VPS vs. Dedicated Server. Und für den ganz tiefen Einstieg in Nginx als Proxy haben wir den kompletten Nginx-Reverse-Proxy-Guide.

Fazit: Caddy vs Nginx

Unser Benchmark hat gezeigt, was viele vermuten, aber selten sauber belegen: Nginx ist schneller. Bei statischen Dateien etwa doppelt so schnell, als Reverse Proxy rund 30 Prozent, und das mit einem Drittel bis einem Viertel der CPU-Zeit und etwa halb so viel Arbeitsspeicher.

Und trotzdem betreiben wir unseren eigenen Server mit Caddy. Weil der Engpass bei uns nie der Webserver war, sondern unsere Zeit. 85 Zertifikate im Monat, um die sich niemand kümmern muss, 139 Sites in einer Datei, die man auch nach Monaten noch lesen kann, und Voreinstellungen, die gefälschte IP-Adressen verwerfen, ohne dass man daran denken muss: Das ist für uns mehr wert als Leistungsreserven, die wir nie abrufen.

Die ehrliche Regel lautet deshalb: Wähle Caddy, wenn deine Zeit knapper ist als deine CPU. Wähle Nginx, wenn es umgekehrt ist oder wenn das Ökosystem es verlangt. Beide sind ausgereift, beide sind kostenlos, und falls du dich falsch entscheidest, ist der Umstieg an einem Nachmittag erledigt.

Häufige Fragen zu Caddy vs Nginx

Ist Caddy schneller als Nginx?

Nein. In unserem Benchmark war Nginx bei statischen Dateien rund doppelt so schnell (etwa 142.000 gegen 70.000 Anfragen pro Sekunde) und als Reverse Proxy rund 30 Prozent schneller. Für die meisten Websites spielt das trotzdem keine Rolle, weil beide weit mehr Anfragen schaffen, als eine normale Seite je bekommt.

Ist Caddy produktionsreif?

Ja. Caddy läuft bei vielen Firmen im Produktivbetrieb, auch diese Website wird von Caddy ausgeliefert. Unser Produktionsprozess lief zum Zeitpunkt dieses Artikels 28 Tage ohne Neustart mit 139 Sites.

Braucht Caddy Certbot oder Let’s Encrypt extra?

Nein. Caddy holt Zertifikate von Let’s Encrypt oder ZeroSSL selbst, sobald du einen Domainnamen in die Konfiguration schreibst, und erneuert sie automatisch. Voraussetzung ist nur, dass die Domain auf deinen Server zeigt und die Ports 80 und 443 erreichbar sind.

Kann Caddy Nginx komplett ersetzen?

Für die meisten Einsätze ja: statische Dateien, Reverse Proxy, Load Balancing, PHP, WebSockets, Komprimierung. Grenzen gibt es bei sehr speziellen Nginx-Modulen (etwa Lua über OpenResty oder RTMP-Streaming) und bei Anwendungen, deren Hersteller nur Nginx-Konfigurationen unterstützt.

Wie viel Arbeitsspeicher braucht Caddy im Vergleich zu Nginx?

In unserem Test nach Last rund 56 MB für Caddy gegen rund 29 MB für alle Nginx-Prozesse zusammen. Unser Produktions-Caddy mit 139 Sites braucht rund 100 MB. Auf Servern ab 1 GB RAM ist der Unterschied praktisch egal.

Ist Caddy sicherer als Nginx?

Caddy hat die sichereren Voreinstellungen: automatisches HTTPS, moderne TLS-Einstellungen, und gefälschte X-Forwarded-For-Header werden standardmäßig ersetzt statt übernommen. Außerdem ist Go speichersicher. Nginx kann genauso sicher betrieben werden, du musst es aber selbst richtig konfigurieren.

Unterstützt Nginx HTTP/3?

Ja, offiziell seit Version 1.25. Viele Linux-Distributionen liefern aber noch ältere Versionen aus, Ubuntu zum Beispiel 1.24, und HTTP/3 muss zusätzlich pro Site aktiviert werden. Bei Caddy ist HTTP/3 standardmäßig an.

Was ist mit Nginx Proxy Manager?

Nginx Proxy Manager ist eine Weboberfläche, die Nginx mit automatischen Let’s-Encrypt-Zertifikaten kombiniert. Sie ist besonders im Homelab beliebt, weil man nichts in Konfigurationsdateien schreiben muss. Wer lieber mit einer Textdatei arbeitet, erreicht mit Caddy dasselbe mit weniger beweglichen Teilen.

Caddy vs Nginx vs Traefik: Welcher für Docker?

Für ein paar feste Container in einer Compose-Datei ist Caddy am einfachsten. Wenn Container ständig automatisch starten und stoppen, ist Traefik mit seiner Dienst-Erkennung über Labels die bessere Wahl. Nginx lohnt sich im Container vor allem, wenn du seine Leistung oder seine Module brauchst.

Sollte ich als Anfänger mit Caddy oder Nginx starten?

Wenn du schnell etwas Funktionierendes willst: Caddy. Wenn du Webserver beruflich lernen willst: Nginx, weil es in Stellenanzeigen, bei Hostern und in Dokumentationen fast überall vorausgesetzt wird. Am besten lernst du Nginx gründlich und nutzt Caddy dort, wo es dir Arbeit abnimmt.

Warum bekomme ich bei Nginx einen 403-Fehler, obwohl die Datei existiert?

Fast immer ein Rechteproblem. Nginx-Worker laufen als unprivilegierter Benutzer (unter Ubuntu www-data) und müssen jeden Ordner auf dem Pfad betreten dürfen. Genau das ist uns im Benchmark passiert. Mit namei -l /pfad/zur/datei siehst du sofort, welcher Ordner blockiert.