Caddy vs Nginx su un VPS: il confronto tra i file di configurazione

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

Le righe TLS nel blocco Nginx presuppongono che Certbot sia già stato eseguito. Per un upstream HTTP come quello sopra, Caddy passa l'intestazione Host in ingresso e imposta X-Forwarded-For, X-Forwarded-Proto, e X-Forwarded-Host per impostazione predefinita. Con Nginx, di norma aggiungi le intestazioni del proxy in modo esplicito quando l'upstream ha bisogno dell'host originale, dello schema e della catena degli indirizzi client. Ecco il compromesso in miniatura: Caddy adotta impostazioni predefinite di proxy pratiche, mentre Nginx rende più esplicito buona parte di quel comportamento.

Serving di file statici:

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, proteggendo tutto dietro un nome utente e una password:

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

Entrambi gli strumenti fanno l'hash della password fuori banda. Caddy usa caddy hash-password; Nginx usa htpasswd per costruire il file .htpasswd. La direttiva è basic_auth nell'attuale Caddy, tra l'altro. Era basicauth finché la v2.8.0 non l'ha rinominata, come indicato nella documentazione basic_auth di Caddy, e i vecchi tutorial fanno ancora inciampare le persone su questo punto.

Consiglio: Quell'hash nel Caddyfile non è la password. È l'output bcrypt di caddy hash-password. Esegui il comando, incolla ciò che stampa. Caddy rifiuta le password in chiaro nella configurazione, che è l'impostazione predefinita corretta e una piccola sorpresa la prima volta.

Le configurazioni parlano da sole. Caddy raccoglie TLS, intestazioni proxy sensate e un redirect in poche righe; Nginx è esplicito e prolisso e ti mette in mano ogni manopola. Se hai passato anni su Nginx, la verbosità è memoria muscolare e il controllo è proprio il punto. Se non l'hai fatto, il Caddyfile è una configurazione che riesci a tenere in testa. Il punto pratico è semplice: la configurazione di Caddy è più facile da leggere a colpo d'occhio, mentre Nginx ti dà un controllo più esplicito.

Prestazioni e memoria: leggere i benchmark con attenzione

I test pubblicati indicano tutti la stessa direzione generale: Nginx di solito usa meno memoria e spesso è in testa sul throughput grezzo, ma l'entità di quel vantaggio dipende fortemente dall'ambiente.

In un test di terze parti su una VM a quattro core, Nginx ha raggiunto circa 48.000 richieste al secondo, contro circa 42.000 per Caddy. Lo stesso test ha riportato una latenza HTTPS p99 di 2,1 ms per Nginx e 2,4 ms per Caddy. Consideralo come il risultato di una singola configurazione anziché come un margine di prestazioni universale.

Gli intervalli di memoria nella tabella di confronto provengono da un test su VPS separato. Un altro test sintetico con 50.000 connessioni concorrenti ha riportato 145 MB per Nginx e 520 MB per Caddy, ma quel test usava hardware e condizioni di carico sostanzialmente diversi. Le sue cifre assolute non vanno confrontate direttamente con i numeri su VPS sopra indicati.

La conclusione affidabile è più circoscritta: Nginx ha generalmente l'ingombro di memoria minore e tende a essere in testa sotto carichi ad alto throughput o alta concorrenza. Per un normale reverse proxy su VPS di dimensioni piccole o medie, entrambi sono di solito abbastanza veloci, quindi la semplicità operativa è spesso il fattore decisionale più utile.

In sintesi della sezione: scegli in base agli aspetti operativi, a meno che il tuo server non sia limitato dalla memoria o i tuoi stessi test di carico non mostrino che il throughput del proxy è il collo di bottiglia.

Il punto critico dei certificati wildcard (Caddy non è sempre a configurazione zero)

Caddy può automatizzare i certificati wildcard, ma non con le sue challenge predefinite HTTP-01 o TLS-ALPN-01. Un certificato per *.example.com richiede la validazione DNS-01, che Let's Encrypt impone per i certificati wildcard. Ciò significa un plugin per il provider DNS (integrato nel tuo binario Caddy tramite xcaddy) più un token API per il tuo host DNS, configurato nel blocco tls. Non è la storia del digita-una-riga-e-vattene che Caddy pubblicizza.

Questo colpisce gli utenti homelab che mettono molti servizi sotto un dominio reale che controllano, come *.home.example.com, e presumono che l'emissione dei wildcard sia automatica quanto quella di app.example.com. Per nomi puramente interni come *.homelab.internal, trattalo come territorio della PKI locale/interna, non come un wildcard pubblico di Let's Encrypt. Per essere precisi: Caddy gestisce bene i wildcard, semplicemente non lo fa con le challenge predefinite, e la configurazione è un gradino sopra il caso a dominio singolo. Nginx è nella stessa situazione qui, dato che il requisito DNS-01 viene da Let's Encrypt, non dal server.

Se vuoi una GUI: Nginx Proxy Manager (una breve digressione)

Nginx Proxy Manager è tutta un'altra bestia rispetto ai due strumenti sopra, e merita un paragrafo perché il nome confonde le persone. NPM è un wrapper con GUI su Nginx: gestisce le regole di reverse proxy e i certificati Let's Encrypt tramite un'interfaccia web sulla port 81. Non è il core di Nginx, e non si configura come si configura il core di Nginx.

Il compromesso è il solito tra clic e configurazione. NPM è il pulsante facile finché non esci dal percorso ideale. La sua configurazione è gestita tramite un database applicativo anziché un singolo file di configurazione modificato a mano. Il setup Docker predefinito usa SQLite, mentre MySQL/MariaDB e PostgreSQL sono opzioni di database esterno supportate. Quella differenza incide anche sulla portabilità: una configurazione Caddy spesso può essere spostata copiando un singolo Caddyfile, mentre un deployment di Nginx Proxy Manager richiede la conservazione dei suoi dati applicativi e del database . NPM è un'ottima scelta se preferisci davvero cliccare anziché modificare e la tua configurazione resta semplice. È la scelta sbagliata per un flusso di lavoro infrastructure-as-code.

Migrare da Nginx a Caddy (cosa si traduce e cosa no)

Se sei già su Nginx e stai valutando il passaggio, comincia abbassando le aspettative sull'automazione: esiste un adattatore di configurazione NGINX per Caddy, ma è incompleto e non va trattato come un percorso di migrazione affidabile in un colpo solo. Una migrazione da Nginx a Caddy è per lo più una riscrittura manuale, e gran parte di essa si accorcia.

Cosa si traduce e diventa più semplice, secondo la guida alla conversione della community di Caddy:

• Per gli upstream HTTP, reverse_proxy passa l'intestazione Host in ingresso e imposta le intestazioni standard X-Forwarded-* per impostazione predefinita, quindi la maggior parte di quelle proxy_set_header righe scompare.
• PHP si riduce da un location block con try_files più fastcgi_pass più un mucchio di parametri a un'unica php_fastcgi direttiva.
• La gestione dei WebSocket è automatica in Caddy v2. Se un tutorial ti dice di aggiungere una direttiva websocket separata, è un residuo di Caddy v1. Ignoralo.

Cosa non si traduce automaticamente: tutto ciò che è legato a uno specifico modulo Nginx che Caddy non ha, la logica complessa di rewrite e location che dovrai ripensare anziché portare così com'è, e le configurazioni di certificati wildcard, che ti riportano alla configurazione con challenge DNS della sezione precedente. Metti in conto i moduli e i rewrite; il resto è di solito una riduzione netta di righe.

Quale dovresti installare? (La decisione)

Hai visto le configurazioni, i numeri, il punto critico dei wildcard e il costo della migrazione, quindi ecco dove si arriva. Installa Caddy se sei uno sviluppatore singolo o un piccolo team, se si tratta di un deployment su VPS appena creato, se vuoi un TLS da impostare e dimenticare, se stai usando Docker con routing semplice, o se vuoi semplicemente una configurazione che entri nella memoria muscolare. È la maggior parte di chi sta leggendo.

Installa Nginx se ti serve un controllo granulare o uno specifico modulo del suo ecosistema maturo, se stai spremendo prestazioni da un server limitato dalla memoria, se stai facendo serving di file statici ad alta concorrenza, o se il tuo team ha già una profonda esperienza con Nginx e una pila di configurazioni funzionanti. Sono motivi solidi, e se uno di essi è il tuo, Nginx è la scelta giusta. Questo non è un caso in cui lo strumento più vecchio è lo strumento sbagliato.

Qualunque sia la tua scelta, il passo successivo è metterlo sulla macchina. Entrambi Caddy e i piani Nginx sono disponibili come deployment con un clic nel nostro marketplace, così puoi saltare il lavoro di installazione e passare direttamente al Caddyfile o al server block. Un VPS da 1 GB è un punto di partenza ragionevole per un deployment a sito singolo a basso traffico, ma dimensiona il server in base all'applicazione e al traffico dietro il proxy, non al solo proxy. Se stai usando Caddy come porta d'ingresso per servizi self-hosted, può stare davanti a uno stack di monitoraggio Prometheus e Grafana o a un deployment di Uptime Kuma senza richiedere strumenti TLS separati.

In sintesi della sezione: scegli Caddy a meno che tu non abbia un motivo specifico che indichi Nginx.

Domande frequenti