Caddy vs nginx: HTTPS, configurazione e quale scegliere
Caddy vs nginx
Caddy vs nginx: HTTPS automatico e config a confronto | We.Inc
Caddy vs nginx su casi reali: HTTPS automatico, siti statici, reverse proxy, load balancing e WebSocket, con un generatore che scrive entrambe le config per il tuo dominio.
La differenza principale sono i certificati. Caddy serve ogni sito in HTTPS per default, ottenendo e rinnovando i certificati da Let's Encrypt o ZeroSSL e reindirizzando l'HTTP al posto tuo. nginx ha bisogno di file di certificato forniti da te, da un client ACME o dal suo modulo acme separato. I Caddyfile sono più corti; nginx offre un controllo più fine e una storia molto più lunga alle spalle.
Caddy e nginx a confronto sui lavori di tutti i giorni
Lavoro
Caddy
Certificati HTTPS
Automatici per ogni dominio pubblico nella config
Punti ssl_certificate a dei file, oppure aggiungi il modulo separato ngx_http_acme_module
Redirect da HTTP a HTTPS
Automatico
Un blocco server sulla porta 80 che restituisce 301
Compressione
encode zstd gzip
gzip on
Reverse proxy
reverse_proxy localhost:3000
proxy_pass in una location, più gli header
WebSocket attraverso il proxy
Gestiti automaticamente
Inoltrare gli header Upgrade e Connection
Load balancing di default
round robin
Health check attivi
health_uri in reverse_proxy
health_check solo nell'edizione commerciale
Verifica e reload della config
caddy validate, caddy reload
nginx -t, nginx -s reload
La maggior parte dei confronti si ferma alle funzionalità. Qui puoi scrivere un dominio e la porta di un'app e ottenere entrambe le config, così vedi esattamente quanto ti chiede di scrivere ciascun server per lo stesso risultato. Sotto il generatore trovi frammenti affiancati per i lavori più frequenti, poi note oneste su dove si adatta meglio ciascuno.
Inserisci il tuo dominio e scegli se il server deve servire file statici o inoltrare le richieste a un'app.
Attiva o disattiva la compressione e il redirect www per vedere quali righe servono a ogni server.
Copia il Caddyfile accanto al binario caddy ed esegui caddy run, oppure copia il blocco nginx in un file nella cartella dei tuoi siti.
Per nginx, ottieni prima un certificato con il tuo client ACME e aggiorna i due percorsi dei certificati prima del reload.
Caddy può ottenere un certificato pubblico solo se il record A o AAAA del dominio punta alla macchina e le porte 80 e 443 sono raggiungibili dall'esterno.
Dai a Caddy uno storage persistente e scrivibile per la sua directory dei dati. Nei container monta un volume, altrimenti richiede nuovi certificati a ogni riavvio.
Esegui caddy fmt sui Caddyfile modificati a mano; sistema l'indentazione sempre allo stesso modo.
Su nginx, fai un test con nginx -t prima di ogni reload. Controlla la sintassi e prova anche ad aprire i file a cui la config fa riferimento, come i percorsi dei certificati.
Da Caddy 2.8 la direttiva root non richiede più il matcher *, quindi root /srv funziona. Le guide più vecchie che scrivono root * /srv restano valide.
Domande frequenti
Caddy può sostituire direttamente nginx?
Per siti statici, reverse proxy e load balancing semplice, di solito sì, e la config si accorcia. Grandi installazioni nginx che usano molti moduli di terze parti, logiche complesse di map e rewrite o caching ottimizzato potrebbero non avere un equivalente diretto in Caddy, quindi traduci e prova un sito alla volta.
Ora nginx fa HTTPS automatico?
nginx ha un ngx_http_acme_module che implementa ACME, ma non è compilato per default. Lo installi come modulo dinamico separato (il pacchetto nginx-module-acme) e configuri un emittente. Senza di esso, i certificati arrivano da un client esterno.
Caddy può darmi HTTPS su localhost?
Sì. Per localhost e i nomi interni Caddy crea una propria autorità di certificazione locale e rilascia certificati da lì. Il tuo sistema potrebbe chiederti una volta di considerare attendibile il suo certificato root.
Quale ha prestazioni migliori?
Non pubblichiamo numeri di velocità perché variano con hardware, impostazioni TLS e carico di lavoro. Entrambi gestiscono senza fatica siti web e API tipici. Se per te conta il throughput puro, fai un benchmark del tuo schema di traffico sui tuoi server.
Caddy supporta load balancing e health check?
Sì. Elenca più upstream in reverse_proxy, scegli una lb_policy come round_robin o least_conn, e aggiungi health_uri per i controlli attivi o fail_duration per quelli passivi. Senza una policy, Caddy sceglie gli upstream a caso.
Cosa copre davvero l'HTTPS automatico
Quando un Caddyfile nomina un dominio pubblico, Caddy ottiene un certificato tramite ACME, serve il sito sulla 443, reindirizza la porta 80 su HTTPS e rinnova il certificato in background. Se un emittente fallisce riprova e può ripiegare su un altro. Nulla nella config menziona TLS a meno che tu non voglia cambiare i default.
nginx lascia questo compito a te. La configurazione abituale è un client ACME che scrive i file dei certificati e ricarica nginx dopo il rinnovo, oppure il più recente modulo acme che installi apposta.
Quando nginx è la scelta migliore
nginx è ovunque: nelle distribuzioni, nelle immagini container e nei pannelli di hosting, con documentazione e risposte per quasi ogni situazione. I team che lo usano già, che dipendono da moduli specifici o che hanno bisogno di un controllo fine su buffering e caching hanno pochi motivi per cambiare.
Quando Caddy è la scelta migliore
Team piccoli, progetti personali e molti domini traggono il massimo vantaggio dal non dover gestire certificati. Il suo formato di config nativo è JSON, che caddy adapt genera da un Caddyfile, e caddy reload invia una nuova config al processo in esecuzione tramite la sua admin API senza downtime.
Load balancing su tre application server
Caddyfile
Round robin su tre backend, con health check in background su /healthz.
Il round robin è il default. nginx open source controlla lo stato solo in modo passivo, tramite le richieste fallite.
Proxy dei WebSocket
Caddyfile
reverse_proxy esegue l'upgrade e tiene aperto un tunnel bidirezionale senza righe aggiuntive.
Gli header Upgrade e Connection vanno inoltrati esplicitamente; proxy_http_version 1.1 è necessario prima di nginx 1.29.7.