Perché Server Manager usa Caddy?

Server Manager fa scelte precise: ogni ricetta e procedura guidata scrive blocchi Caddyfile, non nginx server { }, Apache <VirtualHost> o label Docker di Traefik. Non perché gli altri motori siano scadenti — nginx, in particolare, è un ottimo software. Il motivo è che Caddy riduce a zero configurazione la parte più fastidiosa della gestione di un sito web (HTTPS), mentre gli altri no. Se usi già nginx, Apache o Traefik, Server Manager rileva la tua configurazione e sei tu a scegliere: restare dove sei (con un piccolo compromesso nell'esperienza d'uso) oppure eseguire la ricetta con un clic Migra a Caddy.

A cosa serve un reverse proxy, di nuovo?

Il proxy inverso è il server esposto pubblicamente sulle porte 80 (HTTP) e 443 (HTTPS). I browser si collegano a lui; lui inoltra ogni richiesta all'app interna corretta che sta dietro — il tuo WordPress, la tua web app, la tua API. Le tue app ascoltano su porte interne come 3000 o 127.0.0.1:8080; il reverse proxy è la porta d'ingresso che decide cosa va instradato dove.

Ti serve un reverse proxy per:

• Servire HTTPS (l'icona del lucchetto). Oggi i browser si rifiutano di inviare cookie / password / pagamenti su semplice HTTP.
• Gestire più siti su un solo server con domini diversi.
• Nascondere le porte interne — i visitatori aprono https://mysite.com, non https://mysite.com:3000.

Le quattro scelte più comuni

La stessa idea, in una riga ciascuno:

• Caddy — "Voglio che HTTPS funzioni e basta."
• nginx — "Mi serve la massima capacità di traffico e ho tempo per configurarlo con attenzione."
• Apache — "Eseguo app PHP aziendali con .htaccess."
• Traefik — "È tutto in Docker, basta etichettarlo."

Perché Server Manager ha scelto Caddy

Tre motivi, in ordine di priorità:

1. L'HTTPS automatico è la funzionalità decisiva per gli utenti non tecnici. Il principale attrito nel pubblicare un piccolo sito web è gestire i certificati TLS. Caddy elimina completamente questo attrito. La procedura guidata ti chiede di inserire un dominio; 30 secondi dopo il sito è online in HTTPS con un certificato Let's Encrypt valido. Niente installazione di certbot, niente scelta di plugin, niente cron di rinnovo, niente modifiche alla configurazione. È un vantaggio netto e non vogliamo scendere a compromessi su questo.
2. Impostazioni predefinite sensate riducono i bug che rompono i siti. Caddy include compressione gzip, HTTP/2, cifrari TLS moderni e timeout ragionevoli, tutti attivi di default. nginx e Apache lasciano disattivata la maggior parte di queste opzioni — il che significa che una quota reale di ogni distribuzione nginx finisce con una configurazione leggermente subottimale che l'utente non sa nemmeno di dover correggere. Caddy rende predefinita la scelta giusta.
3. La sintassi del Caddyfile è accessibile. Faro può scrivere blocchi Caddyfile in modo affidabile; tu puoi leggerli. L'equivalente in nginx richiede blocchi server { listen 80; listen 443 ssl; ssl_certificate /etc/letsencrypt/live/...; ... } su più righe, più difficili da esaminare e più difficili da generare correttamente per un LLM. Sintassi con meno attrito = meno errori dell'agente + revisioni di approvazione più pulite.

A cosa rinunci scegliendo Caddy

Cerchiamo di essere onesti sui compromessi. Caddy non è necessariamente migliore in tutto.

• Prestazioni massime con milioni di richieste. nginx mantiene ancora un vantaggio in termini di capacità di traffico. Per la maggior parte dei siti non conta — il collo di bottiglia è il backend, non il proxy — ma se servi centinaia di milioni di richieste al giorno, nginx userà un po' meno CPU.
• Moduli nginx di nicchia. mod_lua / OpenResty, proxy_cache_path, limit_req_zone, geoip — sono funzionalità reali che Caddy gestisce in modo diverso o non offre. Se ci fai affidamento, la migrazione non è una cosa da un clic.
• **Legacy Apache + mod_php.** Alcune vecchie app PHP presuppongono Apache con mod_php (PHP gira dentro il processo Apache). Caddy usa PHP-FPM (processo separato); il risultato funzionale è lo stesso, ma se hai anni di configurazioni specifiche per Apache (.htaccess personalizzati, catene mod_rewrite), il porting richiede lavoro.
• Familiarità del team. Se il tuo team conosce già nginx alla perfezione, passare a qualcos'altro ha un costo di apprendimento. Vale la pena per l'HTTPS automatico, ma non è gratis.

Per il pubblico di riferimento di Server Manager (piccoli team, progetti personali, distribuzioni su un singolo server), di solito nessuno di questi aspetti crea problemi. Il vantaggio dell'HTTPS automatico è ciò che conta nell'uso quotidiano.

E se mantengo il mio motore attuale?

Puoi farlo. Server Manager rileva nginx, Apache e Traefik e ti offre due percorsi supportati:

• Restare sul motore attuale. Faro lo configura nativamente in chat: /etc/nginx/sites-available/ + certbot --nginx per nginx, l'equivalente Apache per Apache, label Docker per Traefik. Stesso risultato finale per ogni dominio; la palette delle ricette contrassegna i flussi solo Caddy con un badge 💬 via chat — funzionano comunque, richiedono solo un clic di approvazione in più rispetto al percorso ideale con Caddy.
• **Migra a Caddy** con la ricetta integrata. Traduce la tua configurazione esistente in un Caddyfile, fa una prova su porte alternative mentre il motore attuale continua a servire il traffico live, esegue lo scambio in modo atomico se va tutto bene e fa rollback automatico in caso di qualsiasi errore. ~10 minuti; supporta nginx, Apache e Traefik.

Qualunque opzione tu scelga, i siti esistenti continuano a servire traffico. La migrazione è facoltativa.

Quando NON migrare

Non migrare a Caddy se una di queste situazioni ti riguarda:

• Usi OpenResty / nginx-lua o altre funzionalità nginx basate pesantemente su moduli personalizzati.
• Hai regole **Apache .htaccess complesse** con catene RewriteRule [L,PT,NE] sovrapposte.
• Usi Traefik con middleware personalizzati (basic auth, rate limit, catene di riscrittura degli header) — in teoria si possono tradurre, ma la ricetta v1 non lo fa automaticamente.
• Sei un host condiviso con utenti di cui non ti fidi — potresti dipendere dai modelli di isolamento per utente di Apache con mod_php, che Caddy non replica.

Il controllo di gestibilità della ricetta di migrazione si rifiuta di partire quando rileva questi casi. Ma questo riguarda solo la ricetta di migrazione automatica — ogni altra azione di Server Manager (distribuire, installare WordPress, collegare un dominio, gestire backup, diagnosticare un sito lento, riavviare un servizio) funziona comunque tramite il percorso in chat sul motore che usi già. Faro si adatta al proxy presente sul server. Prova pure; se un pulsante dell'interfaccia è bloccato, Faro ti proporrà di fare lo stesso lavoro tramite comandi shell.

In sintesi

Caddy non è superiore in ogni dimensione. È superiore nella dimensione che conta di più per il tipo di server usato dalla maggior parte degli utenti di Server Manager: HTTPS automatico, affidabile e senza configurazione. Tutto il resto (impostazioni predefinite sensate, singolo binario, sintassi sintetica, ricaricamento live) sostiene questo vantaggio principale.

Se usi già nginx / Apache / Traefik e la configurazione attuale è in buona salute, il percorso in chat è pienamente supportato. Se vuoi l'esperienza Server Manager completa con un clic, la ricetta Migra a Caddy è disponibile nella scheda Server web di Informazioni server.