> ## Content Index > Fetch the complete content index at: https://opensourcesociety.net/llms.txt > Use this file to discover other available public pages before exploring further. # Vuoi un reverse Proxy da gestire in pochi minuti? Caddy è la soluzione - URL: https://opensourcesociety.net/vuoi-un-reverse-proxy-da-gestire-in-pochi-minuti-caddy-e-la-soluzione/ - Published: 2026-09-22T07:30:53.000Z - Updated: 2026-09-22T07:30:53.000Z - Author: Marco Scurria - Tags: Reverse Proxy, sicurezza, Let's Encrypt, docker Hai mai passato ore a configurare Nginx, a cercare di far funzionare certbot o a debuggare un `nginx.conf` con 200 righe? Caddy nasce per eliminare esattamente questo problema. È un server web e reverse proxy scritto in **Go**, progettato con un'unica filosofia: **la sicurezza e la produttività non devono richiedere un PhD in networking**. In tre righe di configurazione ottieni un reverse proxy completo con HTTPS, HTTP/2, HTTP/3 e redirect automatico da HTTP a HTTPS. Niente altro. ### Perché Caddy batte la concorrenza (per la semplicità) | Funzione | Caddy | Nginx | Traefik | | -------------------- | --------------------------- | ------------------------ | -------------------------------- | | HTTPS automatico | Built-in, attivo di default | Serve certbot + cron | Serve blocco ACME + certresolver | | HTTP/2 | Default | Configurazione esplicita | Default | | HTTP/3 (QUIC) | Built-in | Build sperimentale | Via plugin | | Syntax | Caddyfile (conciso) | nginx.conf (verboso) | YAML / Docker labels | | Footprint in memoria | \~15 MB idle | \~3 MB idle | \~25 MB idle | | Reload zero-downtime | systemctl reload caddy | nginx -s reload | API / file watch | Il punto chiave: con Caddy **non installi certbot**, non scrivi blocchi `ssl_certificate`, non configuri redirect manuali. Il dominio nel Caddyfile *è* la configurazione TLS. ## Setup in 5 minuti (Linux) ### 1\. Installa Caddy ```yml # Aggiungi il repository ufficiale sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https echo "deb [signed-by=/usr/share/keyrings/caddy-server-archive-keyring.gpg] https://dl.caddyserver.com/apt stable main" | sudo tee /etc/apt/sources.list.d/caddy-stable.list sudo apt update && sudo apt install -y caddy ``` ### 2\. Scrivi il Caddyfile Apri `/etc/caddy/Caddyfile` e sostituisci il contenuto con: ```yml { email admin@tuo-dominio.com } app.tuo-dominio.com { reverse_proxy localhost:3000 } ``` **È tutto.** Caddy farà automaticamente: - Ascoltare su porte 80 e 443 - Ottenere un certificato Let's Encrypt per `app.tuo-dominio.com` - Redirect HTTP → HTTPS - Proxy del traffico al backend su porta 3000 - Rinnovo del certificato prima della scadenza ### 3\. Avvia e verifica ```yml sudo systemctl enable --now caddy curl -I https://app.tuo-dominio.com ``` Vedrai un `200` (o il response del tuo backend) con `HTTP/2` e un certificato valido. ## Docker: il caso d'uso più comune Per un homelab con servizi containerizzati, il setup è ancora più rapido: ```yml # docker-compose.yml services: caddy: image: caddy:alpine restart: always ports: - "80:80" - "443:443" - "443:443/udp" volumes: - ./Caddyfile:/etc/caddy/Caddyfile - caddy_data:/data - caddy_config:/config networks: - edge gitea: image: gitea/gitea:latest restart: unless-stopped environment: - USER_UID=1000 - USER_GID=1000 volumes: - gitea_data:/data networks: - edge jellyfin: image: jellyfin/jellyfin:latest restart: unless-stopped networks: - edge volumes: caddy_data: caddy_config: gitea_data: ``` Caddyfile: ```yml { email admin@tuo-dominio.com } git.tuo-dominio.com { reverse_proxy gitea:3000 } jellyfin.tuo-dominio.com { reverse_proxy jellyfin:8096 } ``` ```yml docker compose up -d ``` Visita `https://app.tuodominio.com` — funziona, con HTTPS completo. ## Riavviare Caddy dopo modifiche Dopo aver modificato il Caddyfile, le modifiche non si applicano da sole. Serve un reload: **Installazione nativa (systemd):** ```yml sudo systemctl reload caddy ``` **Docker Compose:** ```yml docker compose exec -w /etc/caddy caddy caddy reload ``` Il reload è **graceful**: Caddy carica la nuova configurazione e le connessioni in corso finiscono con quella vecchia. Zero downtime. Se la nuova config ha un errore, Caddy continua a servire con quella vecchia e riporta l'errore a schermo. > **Nota:** non usare `restart` per le modifiche di configurazione — interrompe le connessioni attive. Il `restart` serve solo per aggiornare il binario di Caddy stesso. ## E oltre il reverse proxy Caddy non si limita a fare da proxy. Con poche righe in più nel Caddyfile puoi aggiungere: - **Header di sicurezza** (HSTS, X-Frame-Options, X-Content-Type-Options) riutilizzabili via snippet - **Autenticazione basica** con password hashate - **Load balancing** tra più backend con health check - **WebSocket** gestiti automaticamente senza configurazione extra - **Certificati wildcard** tramite DNS-01 (es. Cloudflare), senza esporre le porte 80/443 Tutto senza plugin esterni: è tutto già nel binario. ## Quando Caddy non è la scelta giusta Per essere onesti: Caddy non è perfetto per ogni scenario. - **Alto traffico con requisiti di tuning fine** → Nginx offre più controllo su worker process, buffering, connection pooling. - **Service discovery automatica da Docker labels** → Traefik è più immediato. - **Footprint di memoria critico** (es. Raspberry Pi con 512 MB) → Nginx usa \~3 MB vs \~15 MB di Caddy. Ma per il 90% degli scenari — homelab, side project, microservizi, API gateway leggeri — Caddy è la via più rapida verso un reverse proxy **sicuro, moderno e a bassa manutenzione**. ## Conclusione La promessa di Caddy è mantenuta: un reverse proxy in **pochi minuti**, senza certbot, senza blocchi SSL, senza redirect manuali. Un singolo binario Go, un Caddyfile leggibile, e HTTPS che funziona *out of the box*. Se il tuo obiettivo è esporre un servizio al mondo in modo sicuro senza diventare un sysadmin, Caddy è la soluzione.