Caddy vs. Nginx auf einem VPS: Der Vergleich der Konfigurationsdateien

example.com {
    reverse_proxy localhost:3000
}

nginx.conf

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    location / {
        proxy_pass http://localhost:3000;
        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;
    }
}

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

Die TLS-Zeilen im Nginx-Block setzen voraus, dass Certbot bereits gelaufen ist. Für einen HTTP-Upstream wie den oben gezeigten reicht Caddy den eingehenden Host -Header durch und setzt X-Forwarded-For, X-Forwarded-Proto, und X-Forwarded-Host standardmäßig. Bei Nginx fügen Sie die Proxy-Header normalerweise explizit hinzu, wenn der Upstream den ursprünglichen Host, das Schema und die Client-Adresskette benötigt. Das ist der Kompromiss im Kleinen: Caddy liefert praxistaugliche Proxy-Standardwerte, während Nginx mehr von diesem Verhalten explizit macht.

Ausliefern statischer Dateien:

Caddyfile

example.com {
    root * /var/www
    file_server
}

nginx.conf

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    root /var/www;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
}

Basic Auth, alles hinter einem Benutzernamen und einem Passwort schützen:

Caddyfile

example.com {
    basic_auth {
        Bob $2a$14$Zkx19XLiW6VYouLHR5NmfOFU0z2GTNmpkT/5qqR7hx4IjWJPDhjvG
    }
    reverse_proxy localhost:3000
}

nginx.conf

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    auth_basic           "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
    location / {
        proxy_pass http://localhost:3000;
        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;
    }
}

Beide Werkzeuge hashen das Passwort außerhalb der Konfiguration. Caddy verwendet caddy hash-password; Nginx verwendet htpasswd , um die .htpasswd-Datei zu erstellen. Die Direktive lautet übrigens basic_auth im aktuellen Caddy. Sie hieß basicauth , bis v2.8.0 sie umbenannte, wie in den Caddy-basic_auth-Docs, vermerkt, und alte Tutorials bringen die Leute dabei noch immer durcheinander.

Profi-Tipp: Der Hash in der Caddyfile ist nicht das Passwort. Es ist die bcrypt-Ausgabe von caddy hash-password. Führen Sie den Befehl aus und fügen Sie ein, was er ausgibt. Caddy lehnt Klartext-Passwörter in der Konfiguration ab, was der richtige Standard und beim ersten Mal eine kleine Überraschung ist.

Die Konfigurationen sprechen für sich. Caddy fasst TLS, sinnvolle Proxy-Header und eine Weiterleitung in ein paar Zeilen zusammen; Nginx ist explizit und ausführlich und gibt Ihnen jeden Regler in die Hand. Wenn Sie jahrelang mit Nginx gearbeitet haben, ist die Ausführlichkeit reine Routine und die Kontrolle der springende Punkt. Wenn nicht, ist die Caddyfile eine Konfiguration, die Sie im Kopf behalten können. Der praktische Punkt ist einfach: Caddys Konfiguration lässt sich auf einen Blick leichter lesen, während Nginx Ihnen mehr explizite Kontrolle gibt.

Leistung und Speicher: Die Benchmarks sorgfältig lesen

Veröffentlichte Tests weisen in dieselbe grobe Richtung: Nginx verbraucht in der Regel weniger Speicher und liegt beim reinen Durchsatz oft vorn, aber wie groß dieser Vorteil ist, hängt stark von der Umgebung ab.

In einem Vier-Kern-VM-Test eines Drittanbieterserreichte Nginx ungefähr 48.000 Requests pro Sekunde, verglichen mit etwa 42.000 bei Caddy. Derselbe Test berichtete eine HTTPS-p99-Latenz von 2,1 ms für Nginx und 2,4 ms für Caddy. Betrachten Sie diese als Ergebnisse aus einem Setup und nicht als allgemeingültigen Leistungsabstand.

Die Speicherbereiche in der Vergleichstabelle stammen aus einem separaten VPS-Test. Ein weiterer synthetischer Test bei 50.000 gleichzeitigen Verbindungen berichtete 145 MB für Nginx und 520 MB für Caddy, aber dieser Test nutzte deutlich andere Hardware- und Workload-Bedingungen. Seine absoluten Zahlen sollten nicht direkt mit den obigen VPS-Zahlen verglichen werden.

Die belastbare Schlussfolgerung ist enger gefasst: Nginx hat im Allgemeinen den kleineren Speicherbedarf und liegt bei Workloads mit hohem Durchsatz oder hoher Nebenläufigkeit tendenziell vorn. Für einen gewöhnlichen kleinen bis mittleren VPS-Reverse-Proxy sind beide meist schnell genug, sodass betriebliche Einfachheit oft der nützlichere entscheidende Faktor ist.

Fazit des Abschnitts: wählen Sie nach dem Betrieb, es sei denn, Ihr Server ist speicherbeschränkt oder Ihre eigenen Lasttests zeigen, dass der Proxy-Durchsatz der Engpass ist.

Der Wildcard-Zertifikat-Haken (Caddy ist nicht immer ohne Konfiguration nutzbar)

Caddy kann Wildcard-Zertifikate automatisieren, aber nicht mit seinen standardmäßigen HTTP-01- oder TLS-ALPN-01-Challenges. Ein Zertifikat für *.example.com erfordert eine DNS-01-Validierung, die Let's Encrypt für Wildcard-Zertifikate vorschreibt. Das bedeutet ein DNS-Provider-Plugin (über xcaddy in Ihre Caddy-Binary eingebaut) plus ein API-Token für Ihren DNS-Host, konfiguriert im tls-Block. Es ist nicht die Eine-Zeile-tippen-und-loslassen-Geschichte, mit der Caddy wirbt.

Das trifft Homelab-Nutzer, die viele Dienste unter einer echten Domain betreiben, die sie kontrollieren, etwa *.home.example.com, und annehmen, dass die Ausstellung von Wildcards so automatisch abläuft wie app.example.com. Für rein interne Namen wie *.homelab.internalbehandeln Sie das als Terrain für lokale/interne PKI, nicht als öffentliche Let's-Encrypt-Wildcard. Um es genau zu sagen: Caddy beherrscht Wildcards gut, es macht sie nur nicht mit den Standard-Challenges, und die Einrichtung ist eine Stufe anspruchsvoller als der Einzeldomain-Fall. Nginx sitzt hier im selben Boot, da die DNS-01-Anforderung von Let's Encrypt kommt, nicht vom Server.

Wenn Sie eine GUI möchten: Nginx Proxy Manager (ein kurzer Exkurs)

Nginx Proxy Manager ist ein ganz anderes Kaliber als die beiden Werkzeuge oben, und er ist einen Absatz wert, weil der Name die Leute verwirrt. NPM ist ein GUI-Aufsatz über Nginx: Er verwaltet Reverse-Proxy-Regeln und Let's-Encrypt-Zertifikate über eine Weboberfläche auf port 81. Er ist nicht der Nginx-Kern und wird nicht so konfiguriert wie der Nginx-Kern.

Der Kompromiss ist der übliche Klicken-gegen-Konfigurieren-Kompromiss. NPM ist der einfache Knopf, bis Sie den vorgesehenen Pfad verlassen. Seine Konfiguration wird über eine Anwendungsdatenbank verwaltet statt über eine einzelne, von Hand bearbeitete Konfigurationsdatei. Das Standard-Docker-Setup verwendet SQLite, während MySQL/MariaDB und PostgreSQL unterstützte externe Datenbankoptionen sind. Dieser Unterschied wirkt sich auch auf die Portabilität aus: Ein Caddy-Setup lässt sich oft durch Kopieren einer einzigen Caddyfileverschieben, während ein Nginx-Proxy-Manager-Deployment erfordert, dass seine Anwendungsdaten und Datenbank erhalten bleiben. NPM ist eine gute Wahl, wenn Sie das Klicken dem Bearbeiten wirklich vorziehen und Ihr Setup einfach bleibt. Es ist die falsche Wahl für einen Infrastructure-as-Code-Workflow.

Migration von Nginx zu Caddy (was sich übertragen lässt und was nicht)

Wenn Sie bereits Nginx einsetzen und den Wechsel abwägen, senken Sie zunächst Ihre Erwartungen an die Automatisierung: Es gibt einen Caddy-NGINX-Konfigurationsadapter, aber er ist unvollständig und sollte nicht als zuverlässiger Migrationsweg in einem Durchgang behandelt werden. Eine Migration von Nginx zu Caddy ist größtenteils eine manuelle Neufassung, und das meiste davon wird kürzer.

Was sich übertragen lässt und einfacher wird, laut dem Umstellungsleitfaden der Caddy-Community:

• Bei HTTP-Upstreams reicht reverse_proxy den eingehenden Host -Header durch und setzt standardmäßig die üblichen X-Forwarded-*-Header, sodass die meisten dieser proxy_set_header -Zeilen verschwinden.
• PHP schrumpft von einem location-Block mit try_files plus fastcgi_pass plus einem Haufen Parameter auf eine einzige php_fastcgi -Direktive.
• Die WebSocket-Verarbeitung ist in Caddy v2 automatisch. Wenn ein Tutorial Ihnen sagt, Sie sollen eine separate websocket -Direktive hinzufügen, ist das ein Relikt aus Caddy v1. Ignorieren Sie es.

Was sich nicht automatisch übertragen lässt: alles, was an ein bestimmtes Nginx-Modul gebunden ist, das Caddy nicht hat, komplexe Rewrite- und location-Logik, die Sie eher neu durchdenken als portieren müssen, und Wildcard-Zertifikat-Setups, die Sie zurück zum DNS-Challenge-Setup aus dem obigen Abschnitt führen. Planen Sie Zeit für die Module und die Rewrites ein; der Rest ist in der Regel eine Nettoreduktion an Zeilen.

Welches sollten Sie installieren? (Die Entscheidung)

Sie haben die Konfigurationen, die Zahlen, den Wildcard-Haken und die Migrationskosten gesehen, hier also die Schlussfolgerung. Installieren Sie Caddy, wenn Sie ein Einzelentwickler oder ein kleines Team sind, es sich um ein frisches VPS-Deployment handelt, Sie einmal eingerichtetes, wartungsfreies TLS möchten, Sie Docker mit einfachem Routing betreiben oder Sie einfach eine Konfiguration wollen, die Ihnen in Fleisch und Blut übergeht. Das trifft auf die meisten zu, die das hier lesen.

Installieren Sie Nginx, wenn Sie feingranulare Kontrolle oder ein bestimmtes Modul aus seinem ausgereiften Ökosystem brauchen, wenn Sie einem speicherbeschränkten Server die letzte Leistung abringen, wenn Sie statische Dateien mit hoher Nebenläufigkeit ausliefern oder wenn Ihr Team bereits über tiefes Nginx-Know-how und einen Stapel funktionierender Konfigurationen verfügt. Das sind stichhaltige Gründe, und wenn einer davon auf Sie zutrifft, ist Nginx die richtige Wahl. Dies ist kein Fall, in dem das ältere Werkzeug das falsche Werkzeug ist.

Wofür Sie sich auch entscheiden, der nächste Schritt ist, es auf das System zu bringen. Beide Caddy und Nginx sind als Ein-Klick-Deployments in unserem Marktplatz verfügbar, sodass Sie die Installationsarbeit überspringen und direkt zur Caddyfile oder zum Server-Block gelangen können. Ein 1-GB-VPS ist ein vernünftiger Ausgangspunkt für ein Single-Site-Deployment mit geringem Datenverkehr, aber bemessen Sie den Server nach der Anwendung und dem Datenverkehr hinter dem Proxy und nicht nach dem Proxy allein. Wenn Sie Caddy als Eingangstür für selbst gehostete Dienste verwenden, kann es vor einem Prometheus-und-Grafana-Monitoring-Stack oder einem Uptime-Kuma-Deployment sitzen, ohne dass separate TLS-Werkzeuge nötig sind.

Fazit des Abschnitts: wählen Sie Caddy, es sei denn, Sie haben einen konkreten Grund, der für Nginx spricht.

Häufig gestellte Fragen