Caddy vs Nginx op een VPS: de vergelijking van configuratiebestanden

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;
}

De TLS-regels in het Nginx-blok gaan ervan uit dat Certbot al heeft gedraaid. Voor een HTTP-upstream zoals die hierboven geeft Caddy de binnenkomende Host header door en stelt X-Forwarded-For, X-Forwarded-Proto, en X-Forwarded-Host standaardin. Bij Nginx voeg je de proxyheaders normaal gesproken expliciet toe wanneer de upstream de oorspronkelijke host, het schema en de keten van clientadressen nodig heeft. Dat is de afweging in het klein: Caddy levert praktische proxystandaarden, terwijl Nginx meer van dat gedrag expliciet maakt.

Statische bestanden serveren:

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;
    }
}

Basisauth, alles beschermen achter een gebruikersnaam en wachtwoord:

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 tools hashen het wachtwoord buiten de configuratie om. Caddy gebruikt caddy hash-password; Nginx gebruikt htpasswd om het .htpasswd-bestand op te bouwen. De directive is basic_auth in het huidige Caddy, trouwens. Het was basicauth totdat v2.8.0 het hernoemde, zoals vermeld in de Caddy basic_auth-documentatie, en oude tutorials laten mensen er nog steeds over struikelen.

Pro-tip: Die hash in de Caddyfile is niet het wachtwoord. Het is bcrypt-uitvoer van caddy hash-password. Draai het commando, plak wat het afdrukt. Caddy weigert wachtwoorden in platte tekst in de configuratie, wat de juiste standaard is en de eerste keer een kleine verrassing.

De configuraties spreken voor zich. Caddy vouwt TLS, verstandige proxyheaders en een omleiding in een paar regels; Nginx is expliciet en uitgebreid en geeft je elke knop in handen. Als je jaren in Nginx hebt doorgebracht, is de uitgebreidheid spiergeheugen en is de controle juist het punt. Zo niet, dan is de Caddyfile een configuratie die je in je hoofd kunt houden. Het praktische punt is eenvoudig: de configuratie van Caddy is in één oogopslag gemakkelijker te lezen, terwijl Nginx je meer expliciete controle geeft.

Prestaties en geheugen: de benchmarks zorgvuldig lezen

Gepubliceerde tests wijzen in dezelfde algemene richting: Nginx gebruikt meestal minder geheugen en leidt vaak op ruwe doorvoer, maar de omvang van dat voordeel hangt sterk af van de omgeving.

In één VM-test met vier cores van een derde partij, haalde Nginx ongeveer 48.000 verzoeken per seconde, vergeleken met ongeveer 42.000 voor Caddy. Dezelfde test rapporteerde een HTTPS-p99-latentie van 2,1 ms voor Nginx en 2,4 ms voor Caddy. Behandel die als resultaten uit één opstelling en niet als een universele prestatiemarge.

De geheugenbereiken in de vergelijkingstabel komen uit een aparte VPS-test. Een andere synthetische test bij 50.000 gelijktijdige verbindingen rapporteerde 145 MB voor Nginx en 520 MB voor Caddy, maar die test gebruikte substantieel andere hardware- en workloadomstandigheden. De absolute cijfers ervan mogen niet rechtstreeks worden vergeleken met de VPS-getallen hierboven.

De betrouwbare conclusie is beperkter: Nginx heeft over het algemeen de kleinere geheugenvoetafdruk en leidt doorgaans bij workloads met hoge doorvoer of hoge gelijktijdigheid. Voor een gewone kleine tot middelgrote VPS-reverse-proxy zijn beide meestal snel genoeg, dus operationele eenvoud is vaak de nuttigere doorslaggevende factor.

Conclusie van deze sectie: kies op basis van de operationele kant, tenzij je server geheugenbeperkt is of je eigen belastingstests aantonen dat de proxydoorvoer de bottleneck is.

Het addertje bij wildcardcertificaten (Caddy is niet altijd zero-config)

Caddy kan wildcardcertificaten automatiseren, maar niet met zijn standaard HTTP-01- of TLS-ALPN-01-challenges. Een certificaat voor *.example.com vereist DNS-01-validatie, die Let's Encrypt verplicht stelt voor wildcardcertificaten. Dat betekent een DNS-provider-plugin (ingebouwd in je Caddy-binary via xcaddy) plus een API-token voor je DNS-host, geconfigureerd in het tls-blok. Het is niet het type-één-regel-en-loop-weg-verhaal dat Caddy verkoopt.

Dit treft homelabgebruikers die veel diensten onderbrengen onder een echt domein dat ze beheren, zoals *.home.example.com, en ervan uitgaan dat wildcarduitgifte net zo automatisch is als app.example.com. Voor puur interne namen zoals *.homelab.internal, behandel dat als lokaal/intern PKI-terrein, niet als een publieke Let's Encrypt-wildcard. Om precies te zijn: Caddy doet wildcards prima, het doet ze alleen niet met de standaardchallenges, en de opstelling is een stap complexer dan het geval van één enkel domein. Nginx zit hier in hetzelfde schuitje, aangezien de DNS-01-vereiste van Let's Encrypt komt, niet van de server.

Als je een GUI wilt: Nginx Proxy Manager (een korte uitweiding)

Nginx Proxy Manager is een heel ander beest dan de twee tools hierboven, en het is één paragraaf waard omdat de naam mensen in de war brengt. NPM is een GUI-schil over Nginx: het beheert reverse-proxyregels en Let's Encrypt-certificaten via een webinterface op port 81. Het is niet de kern van Nginx, en het wordt niet geconfigureerd zoals de kern van Nginx.

De afweging is de gebruikelijke tussen klikken en configureren. NPM is de makkelijke knop totdat je van het gebaande pad afwijkt. De configuratie wordt beheerd via een applicatiedatabase in plaats van via één handmatig bewerkt configuratiebestand. De standaard Docker-opstelling gebruikt SQLite, terwijl MySQL/MariaDB en PostgreSQL ondersteunde externe databaseopties zijn. Dat verschil beïnvloedt ook de overdraagbaarheid: een Caddy-opstelling kan vaak worden verplaatst door één enkele Caddyfile, te kopiëren, terwijl een Nginx Proxy Manager-implementatie vereist dat de applicatiegegevens en database bewaard blijven. NPM is een prima keuze als je echt liever klikt dan bewerkt en je opstelling eenvoudig blijft. Het is de verkeerde keuze voor een infrastructure-as-code-workflow.

Migreren van Nginx naar Caddy (wat vertaalt en wat niet)

Als je al op Nginx zit en de overstap overweegt, begin dan met je verwachtingen over automatisering bij te stellen: er is een Caddy NGINX-configuratieadapter, maar die is onvolledig en mag niet worden behandeld als een betrouwbaar migratiepad in één keer. Een migratie van Nginx naar Caddy is grotendeels een handmatige herschrijving, en het meeste ervan wordt korter.

Wat vertaalt en eenvoudiger wordt, volgens de conversiegids van de Caddy-community:

• Voor HTTP-upstreams geeft reverse_proxy de binnenkomende Host header door en stelt de standaard X-Forwarded-*-headers standaard in, zodat de meeste van die proxy_set_header regels verdwijnen.
• PHP wordt teruggebracht van een location-blok met try_files plus fastcgi_pass plus een stapel parameters tot één enkele php_fastcgi directive.
• De afhandeling van WebSocket is automatisch in Caddy v2. Als een tutorial je zegt een aparte websocket directive toe te voegen, is dat een overblijfsel uit Caddy v1. Negeer het.

Wat niet automatisch vertaalt: alles wat gebonden is aan een specifieke Nginx-module die Caddy niet heeft, complexe rewrite- en location-logica die je zult moeten heroverwegen in plaats van overzetten, en wildcardcertificaat-opstellingen, die je terugbrengen bij de DNS-challenge-opstelling uit het gedeelte hierboven. Reserveer tijd voor de modules en de rewrites; de rest is meestal een netto vermindering van het aantal regels.

Welke moet je installeren? (De beslissing)

Je hebt de configuraties, de cijfers, het addertje bij wildcards en de migratiekosten gezien, dus hier komt het op neer. Installeer Caddy als je een soloontwikkelaar of klein team bent, dit een verse VPS-implementatie is, je set-and-forget TLS wilt, je Docker draait met eenvoudige routing, of je gewoon een configuratie wilt die in je spiergeheugen past. Dat geldt voor de meeste mensen die dit lezen.

Installeer Nginx als je gedetailleerde controle of een specifieke module uit het volwassen ecosysteem nodig hebt, je prestaties uit een geheugenbeperkte server perst, je statische bestanden met hoge gelijktijdigheid serveert, of je team al diepgaande Nginx-expertise en een stapel werkende configuraties heeft. Dat zijn solide redenen, en als een ervan de jouwe is, is Nginx de juiste keuze. Dit is geen geval waarin de oudere tool de verkeerde tool is.

Op welke je ook uitkomt, de volgende stap is hem op de machine zetten. Beide Caddy en Nginx zijn beschikbaar als one-click-implementaties in onze marketplace, zodat je het installatiewerk kunt overslaan en direct naar de Caddyfile of het serverblok kunt gaan. Een 1 GB-VPS is een redelijk startpunt voor een single-site-implementatie met weinig verkeer, maar stem de omvang van de server af op de applicatie en het verkeer achter de proxy, niet op de proxy alleen. Als je Caddy gebruikt als de voordeur voor zelfgehoste diensten, kan hij vóór een monitoringstack van Prometheus en Grafana of een Uptime Kuma-implementatie staan zonder dat er aparte TLS-tooling nodig is.

Conclusie van deze sectie: kies Caddy tenzij je een specifieke reden hebt die naar Nginx wijst.

Veelgestelde vragen