Cos'è un reverse proxy e perché ti serve

Hai la tua applicazione che gira sul server, ascolta sulla porta 3000 e funziona. Poi arrivano le domande vere: come la raggiungo dal dominio senza scrivere la porta? Come metto HTTPS? E se voglio far girare una seconda applicazione sulla stessa macchina? La risposta a tutte e tre è la stessa componente, e si chiama reverse proxy.

Cos'è

Un reverse proxy è un server che sta davanti alle tue applicazioni: riceve tutte le richieste dall'esterno e le smista a quella giusta, restituendo poi la risposta al visitatore.

Dal punto di vista di chi visita il sito, esiste un solo server. Dietro, possono esserci una o dieci applicazioni, in linguaggi diversi, su porte diverse.

La differenza con un proxy normale sta nella direzione. Un proxy classico sta davanti a chi naviga e protegge lui. Un reverse proxy sta davanti ai server e protegge loro. Da qui il "reverse".

I quattro problemi che risolve

1. Le porte e i domini

La tua applicazione ascolta su localhost:3000. Il browser di chi visita si aspetta la porta 443 per HTTPS. Il reverse proxy fa da tramite: riceve su 443, inoltra a 3000.

E con lo stesso meccanismo ospiti più siti su una macchina sola. Il reverse proxy guarda il nome del dominio nella richiesta e decide dove mandarla:

• sito1.it → applicazione sulla porta 3000
• sito2.it → applicazione sulla porta 4000
• api.sito1.it → applicazione sulla porta 5000

Un solo VPS, un solo indirizzo IP, tanti siti. È il motivo principale per cui quasi ogni server ne ha uno.

2. HTTPS in un posto solo

I certificati TLS vanno installati, rinnovati e configurati. Farlo dentro ogni applicazione significa ripetere il lavoro e sbagliarlo da qualche parte.

Con un reverse proxy, HTTPS si gestisce una volta all'ingresso. Le applicazioni dietro parlano HTTP in chiaro sulla rete locale della macchina, e non sanno nulla di certificati. Questo si chiama terminazione TLS.

Con Let's Encrypt il rinnovo è automatico e il certificato è gratuito.

3. Sicurezza

Le applicazioni non sono esposte direttamente. Ascoltano solo su localhost e l'unico programma raggiungibile dall'esterno è il reverse proxy — un software maturo, il cui unico mestiere è ricevere richieste da internet.

In più è il punto giusto dove mettere limitazioni sul numero di richieste, blocchi per indirizzo IP e intestazioni di sicurezza: le applichi una volta e valgono per tutto.

4. Prestazioni

Serve i file statici (immagini, CSS, JavaScript) senza disturbare l'applicazione, comprime le risposte, gestisce le connessioni lente e può fare caching. Sono cose che un server web fa meglio e con meno risorse di quanto le faccia il codice della tua applicazione.

Una configurazione minima

Con Nginx, il caso base è più corto di quanto ci si aspetti:

server {
    listen 80;
    server_name miosito.it www.miosito.it;

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

Le righe proxy_set_header non sono opzionali, ed è l'errore più comune ometterle. Senza, la tua applicazione vede tutte le richieste provenire da 127.0.0.1: log inutili, blocchi per IP che non funzionano e limitazioni di frequenza che colpiscono tutti insieme. X-Forwarded-Proto serve all'applicazione per sapere che l'utente sta usando HTTPS, altrimenti i reindirizzamenti finiscono in cicli infiniti.

Attivare la configurazione:

sudo nginx -t                 # verifica la sintassi PRIMA
sudo systemctl reload nginx   # applica senza interrompere

nginx -t prima di ogni ricarica. Una configurazione con un errore impedisce l'avvio, e se il servizio era attivo lo lascia fermo.

HTTPS con Let's Encrypt

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d miosito.it -d www.miosito.it

Certbot ottiene il certificato, modifica da solo la configurazione di Nginx e imposta il rinnovo automatico. Verificalo:

sudo certbot renew --dry-run

Perché il rilascio funzioni, il dominio deve già puntare al server. Se non ci sei ancora, il passaggio è in collegare un dominio al sito.

Due dettagli che fanno perdere ore

I WebSocket richiedono due righe in più. Senza, la connessione si apre e cade subito:

location /ws {
    proxy_pass http://localhost:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

Il limite di dimensione dei caricamenti è basso per impostazione predefinita. Un utente carica un'immagine e riceve un errore 413 dal proxy, mentre l'applicazione non riceve mai la richiesta:

client_max_body_size 20M;

Quale usare

	Punto di forza	Attenzione
Nginx	Diffusissimo, ogni guida lo considera	Configurazione un po' verbosa
Caddy	HTTPS automatico senza fare nulla	Comunità più piccola
Traefik	Si configura da solo con Docker	Ha senso soprattutto con i container
Apache	Molto flessibile	Più pesante sotto carico elevato

Il consiglio pratico: Nginx se vuoi trovare risposte facilmente, ed è la scelta che consiglio a chi inizia. Caddy se vuoi il percorso più corto — la configurazione minima è di tre righe e ottiene i certificati da solo:

miosito.it {
    reverse_proxy localhost:3000
}

Il confronto con Apache è approfondito in Nginx o Apache.

Reverse proxy o Cloudflare?

Domanda ricorrente, e la risposta è che risolvono cose diverse.

Cloudflare sta davanti a tutto, sulla rete pubblica: protegge dagli attacchi, distribuisce i contenuti geograficamente, nasconde l'indirizzo del server.

Il reverse proxy sta sulla tua macchina e smista verso le applicazioni locali.

Non sono alternative, e la configurazione più comune li usa entrambi: Cloudflare in cima come scudo e rete di distribuzione, Nginx sul server per instradare e servire.

In sintesi

Un reverse proxy riceve le richieste dall'esterno e le smista alle applicazioni giuste sul server.

Risolve in un colpo solo quattro problemi: far rispondere le applicazioni sulle porte standard, gestire HTTPS in un punto unico, tenere le applicazioni non esposte e servire i file statici in modo efficiente.

Se hai un'applicazione su un VPS, ti serve: è il pezzo che sta tra "gira sulla porta 3000" e "è online sul mio dominio con il lucchetto".

Le due cose da non dimenticare sono le intestazioni X-Forwarded-* — senza, la tua applicazione non sa chi la sta visitando — e nginx -t prima di ogni ricarica.

Per tenere l'applicazione avviata e resistente ai riavvii, il pezzo complementare è systemd. Per il quadro completo del server, vedi come configurare un VPS da zero.