Cos'è un reverse proxy e perché me ne serve uno?

La tua app di solito ascolta su una porta locale come 127.0.0.1:3000. Un reverse proxy sta davanti sulle porte 80/443, termina l'HTTPS, e inoltra le richieste a quella porta locale. Ti dà un dominio pulito, un certificato TLS valido, e la capacità di far girare diverse app dietro un IP — nulla di cui la tua app debba occuparsi da sola.

nginx o Caddy — quale dovrei scegliere?

Caddy è la via più veloce: ottiene e rinnova automaticamente i certificati Let's Encrypt, e un proxy HTTPS funzionante è una riga di config. nginx è più ampiamente conosciuto e flessibile, ma aggiungi Certbot per il TLS. Se vuoi solo HTTPS con il minimo di fatica, usa Caddy; se già conosci nginx o ti servono le sue funzioni, usa nginx.

Per un certificato HTTPS fidato, sì — Let's Encrypt emette certificati per nomi di dominio, non per IP nudi. Punta un record A all'IP del tuo server, aspetta che il DNS si propaghi, poi il proxy può ottenere un certificato per quel nome.

Quali porte devono essere aperte?

80 e 443 in entrata. La porta 80 è usata per la sfida iniziale del certificato e per reindirizzare all'HTTPS; la 443 serve il traffico cifrato. Apri entrambe nel tuo firewall (vedi la guida UFW) e assicurati che nient'altro sia già legato a esse.

Perché l'emissione del certificato fallisce?

Quasi sempre DNS o porte. Il record A del dominio deve puntare a questo server ed essersi propagato, e le porte 80/443 devono essere raggiungibili (aperte nel firewall, non bloccate a monte). Sistema quelle due e l'emissione riesce; Caddy e Certbot riprovano entrambi.

Come configurare un reverse proxy nginx con HTTPS

Metti un dominio pulito e HTTPS automatico davanti a qualsiasi app in esecuzione su una porta locale. Due modi: nginx con Certbot, o Caddy per TLS automatico in una riga. Passo-passo, con la config da copiare.

La maggior parte delle app self-hosted ascolta su una porta locale come 127.0.0.1:3000 e parla HTTP semplice. Un reverse proxy sta davanti sulle porte 80/443, termina l'HTTPS con un certificato reale, e inoltra il traffico a quella porta locale — dandoti un pulito https://app.yourdomain.com e lasciandoti far girare diverse app dietro un IP. Ecco entrambi i modi comuni.

Prerequisiti

Un dominio con un record A che punta all'IP del tuo server (aspetta che il DNS si propaghi).
Porte 80 e 443 aperte — vedi come configurare un firewall UFW.
La tua app in esecuzione localmente, es. su 127.0.0.1:3000.

Opzione A — Caddy (HTTPS automatico, una riga)

sudo apt install -y caddy
echo 'app.yourdomain.com { reverse_proxy 127.0.0.1:3000 }' | sudo tee /etc/caddy/Caddyfile
sudo systemctl restart caddy

Ecco fatto — Caddy ottiene un certificato Let's Encrypt per il dominio e lo rinnova automaticamente.

Opzione B — nginx + Certbot

sudo apt install -y nginx certbot python3-certbot-nginx

Crea /etc/nginx/sites-available/app:

server {
    listen 80;
    server_name app.yourdomain.com;
    location / {
        proxy_pass http://127.0.0.1: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;
    }
}

Abilitalo e aggiungi HTTPS:

sudo ln -s /etc/nginx/sites-available/app /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d app.yourdomain.com

Certbot modifica la config per servire HTTPS e imposta il rinnovo automatico.

Cautele oneste

DNS e porte sono i fallimenti soliti. Il record A deve puntare qui ed essersi propagato, e la 80/443 devono essere raggiungibili, o l'emissione del certificato fallisce. Entrambi gli strumenti riprovano una volta sistemato.
Esponi solo ciò che intendi. Tieni l'app legata a 127.0.0.1 così è raggiungibile solo attraverso il proxy, non direttamente.
L'HTTPS ha bisogno di un dominio, non di un IP nudo — Let's Encrypt emette per nomi.

Prossimi passi

Un reverse proxy è ciò che permette a una macchina di servire molte cose — vedi self-hosting di più servizi dietro un IP. Fai girare l'app in un container? Inizia con come installare Docker. Per tenere l'app stessa viva attraverso riavvii e crash, vedi come creare un servizio systemd.