Vergleich Nginx vs Caddy für Reverse‑Proxy und Webhosting: Einrichtung, HTTPS, Konfigurationen, Performance, Erweiterungen und Empfehlungen, wann welches Tool sinnvoll ist.
Nginx und Caddy sind beides Webserver, die Sie auf Ihrer eigenen Maschine (VM, Bare‑Metal‑Server oder Container) betreiben, um eine Website oder App ins Internet zu stellen.
Auf hoher Ebene werden sie häufig für folgende Aufgaben eingesetzt:
Die meisten Vergleiche laufen auf einen Trade‑off hinaus: wie schnell Sie zu einer sicheren, funktionierenden Einrichtung kommen versus wie viel Kontrolle Sie über jedes Detail haben.
Caddy wird häufig gewählt, wenn Sie einen geradlinigen Weg zu modernen Defaults — insbesondere rund um HTTPS — möchten, ohne viel Zeit in die Konfiguration zu investieren.
Nginx wird häufig gewählt, wenn Sie einen sehr ausgereiften, weit verbreiteten Server wollen, dessen Konfigurationsstil nach Einarbeitung extrem flexibel ist.
Dieser Leitfaden richtet sich an Personen, die alles von einer kleinen persönlichen Site bis zu produktiven Web‑Apps betreiben — Entwickler, Gründer und ops‑orientierte Teams, die eine praktische Entscheidung wollen, keine Theorie.
Wir konzentrieren uns auf reale Deployment‑Belange: Konfigurations‑Ergonomie, HTTPS und Zertifikate, Reverse‑Proxy‑Verhalten, Performance‑Grundlagen, Sicherheits‑Defaults und Betrieb.
Wir geben keine anbieter‑spezifischen Versprechen oder Benchmark‑Aussagen, die stark von Cloud, CDN oder Hosting‑Umgebung abhängen. Stattdessen erhalten Sie Kriterien, die Sie auf Ihr eigenes Setup anwenden können.
Nginx ist überall breit verfügbar (Linux‑Repos, Container, Managed Hosts). Nach der Installation bekommen Sie typischerweise eine „Welcome to nginx!“‑Seite, die aus einem distributionsspezifischen Verzeichnis ausgeliefert wird. Die erste echte Site online zu bekommen bedeutet normalerweise, eine Server‑Block‑Datei zu erstellen, zu aktivieren, die Konfiguration zu testen und anschließend neu zu laden.
Caddy ist ebenfalls einfach zu installieren (Pakete, einzelne Binärdatei, Docker), aber die Erstinstallation ist eher „batteries included“. Eine minimale Caddyfile kann Ihnen in Minuten eine Site oder einen Reverse‑Proxy bereitstellen, und die Defaults sind auf sicheres, modernes HTTPS ausgelegt.
Die Nginx‑Konfiguration ist mächtig, aber Einsteiger stolpern oft über:
location‑Präzedenz)nginx -t vor einem ReloadCaddys Caddyfile liest sich mehr wie eine Absichtserklärung („proxy das zu dem“), was typische Stolperfallen reduziert. Der Trade‑off ist, dass Sie bei sehr spezifischem Verhalten möglicherweise Caddys zugrundeliegende JSON‑Konfiguration oder Modulkonzepte lernen müssen.
Mit Caddy ist HTTPS für eine öffentliche Domain oft eine Einzeiligeinstellung: Site‑Adresse setzen, DNS zeigen lassen, Caddy starten — Zertifikate werden automatisch beantragt und erneuert.
Bei Nginx erfordert HTTPS meist die Wahl eines Zertifikats‑Verfahrens (z. B. Certbot), das Einrichten von Dateipfaden und das Konfigurieren von Erneuerungen. Es ist nicht kompliziert, aber es sind mehr Schritte und mehr mögliche Fehlerquellen.
Für lokale Entwicklung kann Caddy lokale Zertifikate erzeugen und vertrauen lassen (caddy trust), wodurch https://localhost näher an der Produktion liegt.
Mit Nginx ist lokales HTTPS typischerweise manuell (selbstsigniertes Zertifikat, konfigurieren, dann Browserwarnungen akzeptieren oder eine lokale CA installieren). Viele Teams verzichten lokal auf HTTPS, was Cookie‑, Redirect‑ und Mixed‑Content‑Probleme bis später verschleiert.
Konfiguration ist der Punkt, an dem sich Nginx und Caddy am deutlichsten unterscheiden. Nginx bevorzugt eine explizite, verschachtelte Struktur und ein großes Vokabular an Direktiven. Caddy bevorzugt eine kleinere, gut lesbare „Intent‑first“‑Syntax, die sich besonders gut überblicken lässt — gerade wenn Sie nur ein paar Sites verwalten.
Nginx‑Konfiguration baut auf Contexts auf. Die meisten Web‑Apps haben ein oder mehrere server {}‑Blöcke (virtuelle Hosts) und darin mehrere location {}‑Blöcke, die Pfade matchen.
Diese Struktur ist mächtig, aber die Lesbarkeit leidet, wenn Regeln sich anhäufen (Regex‑Locations, mehrere if‑Anweisungen, lange Header‑Listen). Das wichtigste Wartbarkeitswerkzeug sind Includes: große Konfigurationen in kleinere Dateien aufteilen und ein konsistentes Layout pflegen.
Mehrere Sites auf einem Server bedeuten meist mehrere server {}‑Blöcke (oft eine Datei pro Site) plus gemeinsame Snippets:
# /etc/nginx/conf.d/example.conf
server {
listen 80;
server_name example.com www.example.com;
include /etc/nginx/snippets/security-headers.conf;
location / {
proxy_pass http://app_upstream;
include /etc/nginx/snippets/proxy.conf;
}
}
Eine praktische Regel: Behandeln Sie nginx.conf als „Root‑Wiring“ und halten Sie App/Site‑Spezifika in /etc/nginx/conf.d/ (oder sites‑available/sites‑enabled, je nach Distro).
Caddys Caddyfile liest sich eher wie eine Checkliste dessen, was passieren soll. Sie deklarieren einen Site‑Block (meist die Domain) und fügen Direktiven wie reverse_proxy, file_server oder encode hinzu.
Für viele Teams ist der Hauptgewinn, dass der „Happy Path“ kurz und übersichtlich bleibt — selbst wenn Sie gängige Features hinzufügen:
example.com {
reverse_proxy localhost:3000
encode zstd gzip
header {
Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
}
}
Mehrere Sites auf einem Server sind typischerweise einfach mehrere Site‑Blöcke in derselben Datei (oder importierte Dateien), was Reviews leicht scan‑bar macht.
import eingebunden wird.location‑Regel ist oft die schwerste zu debuggen. Caddy fördert einfachere Muster; wenn Sie diese überschreiten, dokumentieren Sie Ihre Absicht in Kommentaren.Wenn Ihnen Klarheit mit minimalem Zeremoniell wichtig ist, ist Caddys Caddyfile schwer zu schlagen. Wenn Sie feinkörnige Kontrolle brauchen und ein strukturierter, ausführlicher Stil in Ordnung ist, bleibt Nginx eine starke Wahl.
HTTPS ist der Bereich, in dem sich der Alltag zwischen Nginx und Caddy am stärksten unterscheidet. Beide können exzellentes TLS liefern; der Unterschied ist, wie viel Arbeit Sie machen müssen — und wie viele Stellen es für Konfigurationsdrift gibt.
Caddys Kernfeature ist automatische HTTPS‑Bereitstellung. Wenn Caddy Hostname und Erreichbarkeit feststellen kann, wird es typischerweise:
In der Praxis konfigurieren Sie eine Site, starten Caddy — und HTTPS „geschieht“ bei gängigen öffentlichen Domains. Caddy handhabt in den meisten Setups auch HTTP→HTTPS‑Redirects automatisch, was eine häufige Fehlerquelle eliminiert.
Nginx erwartet, dass Sie TLS selbst verdrahten. Sie müssen:
ssl_certificate und ssl_certificate_key verweisen lassenDas ist sehr flexibel, aber es ist leichter, einen Schritt zu vergessen — insbesondere bei Automatisierung und Reloads.
Ein klassischer Stolperstein sind falsch gehandhabte Redirects:
Caddy reduziert solche Fehler durch sinnvolle Defaults. Bei Nginx müssen Sie explizit sein und das Verhalten Ende‑zu‑Ende verifizieren.
Für eigene Zertifikate (kommerziell, Wildcard, private CA) funktionieren beide Server gut:
Die meisten Teams wählen einen Webserver nicht für „Hello World“. Sie wählen ihn für die alltäglichen Proxy‑Aufgaben: Client‑Details korrekt durchreichen, Langzeitverbindungen unterstützen und Apps stabil halten bei unperfektem Traffic.
Beide, Nginx und Caddy, können vor Ihre App gesetzt werden und Requests sauber weiterleiten, aber die Details spielen eine Rolle.
Eine gute Reverse‑Proxy‑Konfiguration stellt sicher:
Host, X-Forwarded-Proto und X-Forwarded-For, damit Ihre App korrekte Redirects und Logs erstellen kann.Upgrade/Connection‑Headern; bei Caddy wird das beim Proxying normalerweise automatisch gehandhabt.Wenn Sie mehrere App‑Instanzen haben, können beide Server Traffic über Upstreams verteilen. Nginx hat langjährige Muster für gewichtetes Balancing und granulare Kontrolle, während Caddys Load‑Balancing für gängige Setups unkompliziert ist.
Operational gesehen sind Health‑Checks der eigentliche Differenzierer: Sie wollen, dass ungesunde Instanzen schnell entfernt werden und Timeouts so getunt sind, dass Nutzer nicht auf toten Backends warten.
Reale Apps treffen auf Edge‑Fälle: langsame Clients, lange API‑Aufrufe, Server‑Sent Events und große Uploads.
Achten Sie auf:
Keiner der beiden Server ist standardmäßig eine komplette WAF, aber beide helfen mit praktischen Schutzmaßnahmen: IP‑basierte Request‑Limits, Verbindungs‑Caps und einfache Header‑Sanity‑Checks. Wenn Sie die Sicherheitslage vergleichen, koppeln Sie das mit Ihrer breiteren Checkliste in /blog/nginx-vs-caddy-security.
Performance ist nicht nur „Requests per second“. Es geht auch darum, wie schnell Nutzer etwas Sinnvolles sehen, wie effizient Sie statische Assets ausliefern und wie modern Ihr Protokoll‑Stack standardmäßig ist.
Für statisches Hosting (CSS, JS, Bilder) sind sowohl Nginx als auch Caddy sehr schnell, wenn sie richtig konfiguriert sind.
Nginx gibt Ihnen feinkörnige Kontrolle über Caching‑Header (z. B. langes Caching für gehashte Assets und kürzeres für HTML). Caddy kann das Gleiche leisten, aber Sie greifen vielleicht auf Snippets oder Route‑Matcher zurück, um die gleiche Absicht auszudrücken.
Kompression ist ein Abwägen:
Für kleine Sites schadet Brotli selten und kann Seiten flotter wirken lassen. Bei großen Sites mit hohem Traffic messen Sie CPU‑Headroom und erwägen Vor‑Kompression oder Auslagerung an Edge/CDN.
HTTP/2 ist Baseline für moderne Browser und verbessert das Laden vieler kleiner Assets über eine Verbindung. Beide Server unterstützen es.
HTTP/3 (über QUIC) kann auf mobilen, fehleranfälligen Netzen Vorteile bringen, weil es Paketverlust und Handshakes unempfindlicher macht. Caddy vereinfacht das Ausprobieren von HTTP/3 tendenziell, während Nginx‑Support je nach Build variiert und spezielle Pakete erfordern kann.
Wenn Sie eine Single‑Page‑App ausliefern, brauchen Sie typischerweise „versuche Datei, sonst /index.html“. Beides kann sauber umgesetzt werden, prüfen Sie aber, dass API‑Routen nicht versehentlich auf die SPA zurückfallen und echte 404s verschleiern.
Beide Server können gut gehärtet werden, starten aber mit unterschiedlichen Defaults.
Caddy ist in vielen gängigen Deployments „secure‑by‑default“: modernes TLS, automatische Zertifikats‑Erneuerung und ein HTTPS‑freundliches Setup. Nginx ist flexibel und weit verbreitet, aber Sie müssen in der Regel TLS, Header und Zugriffskontrollen explizit setzen.
Schützen Sie interne Tools (Metriken, Admin‑Panels, Previews) mit Auth und/oder IP‑Allowlists.
Beispiel (Caddy):
admin.example.com {
basicauth {
admin $2a$10$..............................................
}
reverse_proxy 127.0.0.1:9000
}
Bei Nginx nutzen Sie auth_basic oder allow/deny an den exakten Location‑Blöcken, die sensible Routen öffnen.
Beginnen Sie mit Headern, die häufige Risiken reduzieren:
Strict-Transport-Security: max-age=31536000; includeSubDomainsX-Frame-Options: DENY (oder SAMEORIGIN, wenn nötig)X-Content-Type-Options: nosniffHärten heißt weniger, die „perfekte“ Konfiguration zu finden, sondern diese Kontrollen konsistent auf alle Apps und Endpunkte anzuwenden.
Ihre langfristige Erfahrung mit einem Webserver wird oft weniger durch Kernfeatures bestimmt als durch das Umfeld: Module, kopierbare Beispiele und wie schmerzhaft Erweiterungen sind, wenn sich Anforderungen verändern.
Nginx hat ein tiefes Ökosystem über viele Jahre aufgebaut. Es gibt viele offizielle und Drittanbieter‑Module sowie eine enorme Menge an Community‑Konfigurationen (Blogs, GitHub‑Gists, Vendor‑Docs). Das ist ein echter Vorteil, wenn Sie eine spezifische Fähigkeit brauchen — Advanced Caching, nuanciertes Load Balancing oder Integrationsmuster für populäre Apps — denn jemand hat das meist schon gelöst.
Der Nachteil: Nicht jedes gefundene Beispiel ist aktuell oder sicher. Prüfen Sie immer gegen offizielle Docs und moderne TLS‑Empfehlungen.
Caddys Kern deckt viel ab (insbesondere HTTPS und Reverse‑Proxying), aber Sie greifen zu Extensions, wenn Sie nicht‑standardmäßige Auth‑Methoden, ungewöhnliche Upstream‑Discovery oder kundenspezifische Request‑Verarbeitung brauchen.
Wie eine Extension bewerten:
Auf ungewöhnliche Plugins zu setzen erhöht das Upgrade‑Risiko: API‑Brüche oder aufgegebene Wartung können Sie an eine alte Version binden. Um flexibel zu bleiben, bevorzugen Sie Funktionen aus dem Kern, halten Konfiguration portierbar (Absicht dokumentieren, nicht nur Syntax) und kapseln Spezialfunktionen hinter klaren Schnittstellen (z. B. Auth in einem dedizierten Service). Im Zweifel: Prototypen Sie beide Server mit Ihrer realen App, bevor Sie sich festlegen.
Einen Webserver zu betreiben heißt nicht „einrichten und vergessen“. Die Day‑Two‑Arbeit — Logs, Metriken und sichere Änderungen — ist es, wo Nginx und Caddy sich unterschiedlich anfühlen.
Nginx schreibt typischerweise separate Access‑ und Error‑Logs mit sehr anpassbaren Formaten:
Sie passen log_format an, um in Ihr Incident‑Workflow zu passen (z. B. Upstream‑Timings hinzufügen) und debuggen oft, indem Sie Zugriffs‑ und Error‑Logs korrelieren.
Caddy nutzt standardmäßig strukturiertes Logging (häufig JSON), was in Log‑Aggregatoren gut funktioniert, weil Felder konsistent und maschinenlesbar sind. Wenn Sie traditionelle Textlogs bevorzugen, können Sie das einstellen, aber viele Teams nutzen strukturierte Logs für schnelleres Filtern.
Nginx verwendet häufig eingebaute Status‑Endpoints (oder kommerzielle Features, je nach Edition) plus Exporter/Agenten für Prometheus und Dashboards.
Caddy kann Betriebsinformationen über seine Admin‑API ausliefern und lässt sich in gängige Observability‑Stacks integrieren; Teams fügen oft ein Metrics‑Modul/Exporter hinzu, wenn Prometheus‑Scraping gewünscht ist.
Unabhängig vom Server streben Sie einen konsistenten Workflow an: validieren, dann neu laden.
Nginx hat einen bekannten Prozess:
nginx -tnginx -s reload (oder systemctl reload nginx)Caddy unterstützt sichere Updates über Reload‑Mechanismen und Konfigurations‑Validierungsworkflows (besonders, wenn Sie JSON‑Konfiguration generieren). Die Gewohnheit zählt: Eingaben validieren und Änderungen reversibel gestalten.
Behandeln Sie Konfiguration wie Code:
Produktionssetups konvergieren oft zu einigen Mustern, unabhängig davon, ob Sie Nginx oder Caddy wählen. Die größten Unterschiede sind Defaults (Caddys automatische HTTPS) und wie sehr Sie explizite Konfiguration gegenüber „einfach laufen lassen“ bevorzugen.
Auf einer VM oder Bare‑Metal werden beide typischerweise von systemd verwaltet. Wichtig ist Least Privilege: Führen Sie den Server als dedizierten, unprivilegierten User, halten Sie Konfigurationsdateien root‑owned und beschränken Sie Schreibzugriffe auf das Nötigste.
Bei Nginx bedeutet das meist ein root‑owned Master‑Process, der Ports 80/443 bindet, und Worker‑Prozesse, die als www-data (oder ähnlich) laufen. Bei Caddy laufen Sie oft mit einem einzelnen Service‑Account und geben nur minimale Fähigkeiten zum Binden niedriger Ports. In beiden Fällen behandeln Sie TLS‑Private‑Keys und Umgebungsdateien als Secrets mit strengen Berechtigungen.
Im Container ist der „Service“ der Container selbst. Typisch ist:
Planen Sie auch das Netzwerk: Der Reverse‑Proxy sollte im selben Docker‑Netz wie Ihre App‑Container sein und Service‑Namen statt harter IPs verwenden.
Halten Sie getrennte Konfigurationen (oder templatisierte Variablen) für dev/stage/prod, damit Sie nicht „in place“ editieren. Für Zero‑Downtime sind gängige Muster:
Beide Server unterstützen sichere Reloads; kombinieren Sie das mit Health‑Checks, damit nur gesunde Backends Traffic erhalten.
Die Wahl zwischen Nginx und Caddy dreht sich weniger um „wer ist besser“ und mehr darum, was Sie liefern wollen — und wer es betreibt.
Für Blog, Portfolio oder Docs ist Caddy meist der einfachste Weg. Eine minimale Caddyfile kann ein Verzeichnis serven und automatisch HTTPS für eine echte Domain aktivieren — mit sehr wenig Zeremoniell. Das reduziert Einrichtungszeit und die Anzahl der beweglichen Teile.
Beide funktionieren gut; der Entscheid hängt oft davon ab, wer es pflegt.
Für ein typisches „Frontend + API“‑Deployment kann jeder Server TLS terminieren und an App‑Server weiterleiten.
Hier werden die Trade‑offs klarer:
Wenn Sie unsicher sind, standardisieren Sie auf Caddy für Geschwindigkeit und Einfachheit und Nginx für maximale Vorhersehbarkeit in etablierten Produktionsumgebungen.
Wenn Ihre größere Herausforderung das schnelle Ausliefern einer App ist (nicht nur die Wahl eines Proxys), ziehen Sie in Erwägung, den Loop zwischen Entwickeln und Deployen zu verkürzen. Zum Beispiel erlaubt Koder.ai, Web‑, Backend‑ und Mobile‑Apps aus einem Chat‑Interface zu erstellen (React fürs Web, Go + PostgreSQL fürs Backend, Flutter fürs Mobile), dann Quellcode zu exportieren und hinter Caddy oder Nginx zu deployen. In der Praxis können Sie so schnell iterieren und trotzdem eine konventionelle, auditierbare Edge‑Schicht in Produktion behalten.
Eine Migration zwischen Nginx und Caddy bedeutet meist nicht „alles neu schreiben“, sondern einige Schlüsselverhalten übersetzen: Routing, Header, TLS und wie Ihre App Client‑Details sieht.
Wählen Sie Caddy, wenn Sie einfachere Konfigurationen, automatische HTTPS‑Erneuerung und weniger bewegliche Teile im Tagesbetrieb möchten. Es passt gut zu kleinen Teams, vielen kleinen Sites und Projekten, bei denen Sie lieber Absichten ausdrücken ("proxy das", "serve das") als eine große Menge an Direktiven zu pflegen.
Bleiben Sie bei Nginx, wenn Sie stark angepasste Setups (Advanced Caching, komplexe Rewrites, maßgeschneiderte Module) benötigen, bereits Nginx über Fleets standardisiert ist oder Verhalten über Jahre getunt und dokumentiert wurde.
Starten Sie mit einer Inventur: listen Sie alle Server‑Blöcke/Sites, Upstreams, TLS‑Terminierungspunkte, Redirects, Custom‑Header, Ratenbegrenzungen und spezielle Locations (z. B. /api, /assets). Dann:
Achten Sie auf Header‑Unterschiede (Host, X-Forwarded-For, X-Forwarded-Proto), WebSocket‑Proxying, Redirect‑Semantik (Trailing Slashes und 301 vs 302) und Pfadbehandlung (Nginx location‑Matching vs Caddy‑Matcher). Bestätigen Sie außerdem, dass Ihre App den Proxy‑Headern vertraut, damit sie nicht das falsche Schema/URL‑Generation erzeugt.
Die Wahl zwischen Nginx und Caddy hängt vor allem davon ab, was Ihnen am ersten Tag wichtig ist gegenüber der langfristigen Kontrolle. Beide können Websites und Apps gut bedienen; die „beste“ Wahl passt zu den Fähigkeiten und dem Betriebskomfort Ihres Teams.
Nutzen Sie diese Checkliste, um die Entscheidung zu erden:
Caddy bietet tendenziell: einfachere Konfiguration, automatische HTTPS‑Flows und ein freundliches Day‑One‑Erlebnis.
Nginx bietet tendenziell: eine lange Produktions‑Historie, breites Community‑Wissen und viele Stellschrauben für spezialisierte Setups.
Wenn Sie noch unschlüssig sind: Wählen Sie den Server, den Sie um 2 Uhr morgens zuverlässig betreiben können — und überprüfen Sie die Entscheidung erneut, wenn Anforderungen (Traffic, Teams, Compliance) klarer werden.
Wählen Sie Caddy, wenn Sie automatische HTTPS‑Zertifikate, eine kurze, lesbare Konfiguration und schnelle Time‑to‑Live für kleine/mittlere Deployments wollen.
Wählen Sie Nginx, wenn Sie maximale Flexibilität benötigen, bereits ein Nginx‑Standard in Ihrer Organisation/bei Ihrem Hoster existiert oder Sie stark auf ausgereifte Muster für komplexes Routing/Caching/Tuning setzen.
Für eine öffentliche Domain kann Caddy oft mit nur einer Site‑Adresse und einer reverse_proxy/file_server‑Direktive ausreichen. Sobald die DNS auf Ihren Server zeigt, holt Caddy in der Regel Zertifikate und erneuert sie automatisch.
Bei Nginx sollten Sie mit einem ACME‑Client (z. B. Certbot) planen, ssl_certificate/ssl_certificate_key konfigurieren und sicherstellen, dass Erneuerungen einen Reload auslösen.
Häufige Nginx‑Fehler von Einsteigern sind:
location‑Matching/Präzedenz (insbesondere Regex und sich überlappende Regeln)nginx -t)/ umleiten) oder Redirect‑Loops hinter einem anderen Proxy/CDNDie Caddyfile bleibt so lange einfach, bis Sie sehr spezifisches Verhalten brauchen. Dann benötigen Sie möglicherweise:
location‑Szenarien zu spiegeln)Wenn Ihr Setup ungewöhnlich ist, frühzeitig prototypisieren, damit Grenzen nicht mitten in der Migration auffallen.
Caddy hat starke Unterstützung für lokale HTTPS‑Workflows. Sie können lokale Zertifikate erzeugen und vertrauen (z. B. mit caddy trust), wodurch https://localhost näher an der Produktionsumgebung ist und Sie HTTPS‑Probleme früh entdecken.
Bei Nginx ist lokales HTTPS meist manuell (selbstsignierte Zertifikate + Browserwarnungen oder Installation einer lokalen CA), sodass Teams es oft überspringen und Probleme später finden.
Beide können korrekt als Reverse Proxy arbeiten, prüfen Sie in beiden Fällen:
Host, X-Forwarded-Proto, X-Forwarded-ForBeide können Lastverteilung leisten, aber operativ sollten Sie sich auf folgende Punkte konzentrieren:
Für sehr granulare oder etablierte Muster gibt es oft mehr Nginx‑Rezepte; für einfache Multi‑Upstream‑Szenarien ist Caddy schnell eingerichtet.
Achten Sie unabhängig vom Server auf diese Einstellungen:
Führen Sie vor dem Produktionsbetrieb reale Tests durch: große Datei hochladen, lange Requests offenhalten und sicherstellen, dass Proxy‑ und Upstream‑Timeouts zueinander passen.
Beide können sicher betrieben werden, ihre Defaults unterscheiden sich jedoch.
Praktische Basis:
Für eine tiefere Checkliste: /blog/nginx-vs-caddy-security
Verwenden Sie einen „validieren → neu laden“‑Workflow und behandeln Sie Konfiguration wie Code.
nginx -t dann systemctl reload nginx (oder nginx -s reload)In beiden Fällen: Konfigurationen in Git, Rollout über CI/CD mit Dry‑Run‑Validierung und einen schnellen Rollback‑Pfad bereithalten.
Upgrade/Connection; Caddy handhabt das beim Proxying meist automatisch)Testen Sie nach Änderungen Login‑Flows und absolute Redirects, damit Ihre App das richtige Schema und Host sieht.