# Cos'è un reverse proxy (e perché quasi ogni sito ne usa uno)
Table of Contents
Dietro quasi ogni sito che si visita c’è un componente di cui non ci si accorge mai, perché fa bene il suo lavoro proprio restando invisibile: il reverse proxy. Non è il programma che genera le pagine, né il database che conserva i dati. È l’intermediario che sta davanti a tutto il resto e decide chi entra, come e verso quale servizio. Capire cos’è aiuta a leggere l’architettura di un sito senza doverla immaginare come una scatola nera.
Cos’è un reverse proxy in parole semplici
Un proxy è, letteralmente, un intermediario: un componente che sta in mezzo a due parti e gira i messaggi dall’una all’altra. Un reverse proxy è un intermediario che sta davanti a uno o più server applicativi. Il visitatore parla con il reverse proxy; il reverse proxy inoltra la richiesta all’applicazione giusta, ne raccoglie la risposta e la restituisce al visitatore. Il client, cioè il browser, non parla mai direttamente con il server che genera davvero la pagina.
Un’immagine utile è quella del centralino, o della reception di un ufficio. Chi arriva non gira per i corridoi cercando la persona giusta: si rivolge al banco all’ingresso, che smista la richiesta a chi di dovere e riporta indietro la risposta. Il banco è un solo punto di contatto per molti uffici diversi. Il reverse proxy fa la stessa cosa per i servizi web.
La differenza con un forward proxy
La parola “proxy” da sola crea confusione, perché esistono due tipi opposti. La differenza sta da che lato si trova l’intermediario.
Un forward proxy sta davanti ai client. È l’intermediario che una rete aziendale o una VPN mette davanti ai computer degli utenti: quando qualcuno naviga, la richiesta passa prima dal forward proxy, che poi parla con i siti esterni al posto suo. Serve a controllare e filtrare il traffico in uscita e, spesso, a nascondere l’identità di chi naviga.
Un reverse proxy sta davanti ai server. È l’intermediario che il gestore di un sito mette davanti alle proprie applicazioni. La documentazione di MDN riassume bene il contrasto: un forward proxy agisce per conto dei client e può nasconderne l’identità, mentre un reverse proxy può nascondere l’identità dei server. Stessa idea di base, lato opposto: uno protegge chi chiede, l’altro protegge chi risponde.
Un solo ingresso per più servizi
Il motivo più concreto per cui il reverse proxy è così diffuso è che offre un solo punto d’ingresso per molti servizi. Su internet un sito è raggiungibile su due porte standard: la 80 per HTTP e la 443 per HTTPS. Ma dietro un singolo dominio possono vivere applicazioni diverse: il sito vetrina, l’area clienti, un’API per le app mobili, un pannello di amministrazione.
Il reverse proxy ascolta su quell’unica porta pubblica e, guardando il nome del dominio o il percorso richiesto, decide a quale applicazione interna girare ogni richiesta. Le applicazioni, dal canto loro, restano in ascolto solo sulla rete locale della macchina, senza essere esposte direttamente a internet. Un esempio essenziale con Nginx, uno dei reverse proxy più usati, rende l’idea:
server { listen 443 ssl; server_name sito.example.com; # ...certificati TLS...
location / { proxy_pass http://127.0.0.1:3000; }}Qui il proxy riceve le connessioni cifrate dall’esterno e le inoltra a un’applicazione che gira in locale sulla porta 3000. Il visitatore vede un solo indirizzo; dietro le quinte può esserci un intero insieme di servizi.
TLS: la cifratura gestita in un posto solo
Oggi il traffico web viaggia cifrato con TLS, il protocollo che sta dietro il lucchetto di HTTPS. Gestire la cifratura richiede certificati, chiavi e configurazione, e non è un lavoro che conviene duplicare in ogni singola applicazione.
Il reverse proxy risolve il problema con la terminazione TLS: è lui a occuparsi dell‘“handshake” cifrato con il browser, a decifrare le richieste in arrivo e a cifrare le risposte in uscita, così che i server dietro di lui non debbano farlo. I certificati stanno in un posto solo, la configurazione della sicurezza si aggiorna in un punto solo, e le applicazioni interne possono parlare in chiaro sulla rete locale, concentrandosi sul loro compito.
Cache e compressione: meno lavoro ripetuto
Un reverse proxy può anche conservare una copia delle risposte già calcolate. È la cache: se molti utenti chiedono la stessa immagine o la stessa pagina, non serve rigenerarla ogni volta. La prima richiesta paga il costo pieno verso l’applicazione; le successive ricevono la copia già pronta, molto più in fretta e senza affaticare il server d’origine.
Allo stesso livello agisce la compressione: il proxy può comprimere testi, HTML e dati prima di spedirli, riducendo i byte che viaggiano in rete e quindi i tempi di caricamento. Sono ottimizzazioni che è comodo mettere una volta sola, davanti a tutto, invece di reimplementarle in ogni applicazione.
Bilanciamento del carico
Quando un solo server non basta a reggere il traffico, si mettono più copie della stessa applicazione e si distribuiscono le richieste fra loro. Questo compito, il bilanciamento del carico (load balancing), è uno degli usi classici del reverse proxy.
Il proxy decide a quale server inoltrare ogni richiesta secondo una regola. Nginx, per esempio, di default usa il round robin, cioè distribuisce le richieste a turno fra i server disponibili tenendo conto di eventuali pesi; in alternativa può mandare ogni richiesta al server con meno connessioni attive (least connections) o legare un cliente sempre allo stesso server in base al suo indirizzo (ip hash). Il vantaggio è doppio: si regge più traffico e, se un server si guasta, gli altri continuano a rispondere.
Sicurezza: un filtro davanti all’applicazione
Mettere un intermediario davanti ai server ha anche un valore difensivo. Il primo è la riduzione della superficie esposta: le applicazioni non sono raggiungibili direttamente da internet, ma solo attraverso il proxy. Chi vuole attaccarle non ne conosce nemmeno l’indirizzo reale, perché a rispondere è sempre e solo l’intermediario.
Il secondo è che il reverse proxy diventa il punto naturale dove concentrare i controlli: limitare il numero di richieste per bloccare gli abusi (rate limiting), filtrare traffico sospetto, applicare regole di accesso. Farlo in un solo punto, davanti a tutto, è più semplice e più robusto che spargere le stesse difese in ogni applicazione.
Nginx e gli altri
Nginx è forse l’esempio più citato, ma il reverse proxy è un ruolo, non un prodotto. Lo stesso compito lo svolgono software come HAProxy, Apache, Caddy, Traefik o Envoy, i bilanciatori offerti dai fornitori cloud e, su scala globale, le CDN come quelle di Cloudflare, che sono anch’esse reverse proxy davanti a milioni di siti.
Vale la pena notare che il pattern non è legato al solo HTTP: un reverse proxy può inoltrare le richieste alle applicazioni anche con altri protocolli, e infatti Nginx supporta, oltre a HTTP, meccanismi come FastCGI, uwsgi, SCGI, memcached e gRPC. Il concetto resta lo stesso a prescindere dallo strumento scelto.
In sintesi
Un reverse proxy è l’intermediario che sta davanti alle applicazioni web e fa da unico punto di contatto verso l’esterno. Da lì gestisce la cifratura TLS, la cache e la compressione, distribuisce il carico fra più server e concentra i controlli di sicurezza, tenendo le applicazioni al riparo dall’esposizione diretta. Non è un componente vistoso e quasi nessun utente sa che c’è, ma è proprio per questo che quasi ogni sito ne usa uno: risolve in un posto solo una serie di problemi che, altrimenti, ogni applicazione dovrebbe affrontare da sé.
