Nginx come reverse proxy — configurazione completa con esempi

Un reverse proxy Nginx riceve le richieste HTTP/HTTPS dei client e le inoltra ai server backend interni. Per configurare Nginx reverse proxy basta definire un server block con la direttiva proxy_pass, gestendo SSL, header e rate limiting per proteggere le applicazioni.

| Direttiva | Scopo | Esempio |

|—|—|—|

| proxy_pass | Inoltra il traffico al backend | proxy_pass http://localhost:3000; |

| proxy_set_header | Imposta header per il backend | proxy_set_header X-Real-IP $remote_addr; |

| limit_req | Limita richieste per secondo | limit_req zone=api burst=20 nodelay; |

| proxy_cache | Abilita caching risposte | proxy_cache my_cache; |

Quando ho configurato l’infrastruttura per una PA con 2.000 endpoint, il problema principale non era la potenza dei server, ma come esporre le applicazioni interne senza farle attaccare. Il 73% dei breach parte da credenziali rubate o exploit su applicazioni esposte, secondo il Verizon DBIR 2025. Senza un reverse proxy, il backend riceve traffico diretto, senza filtro. Nginx risolve questo problema. Gestisce la crittografia SSL, assorbe il traffico DDoS, logga l’IP reale e fa caching. In questa guida vedrai come configurare Nginx reverse proxy passo dopo passo, con esempi pronti per la produzione.

Prerequisiti / Ambiente di test

Ti serve un server Linux con accesso root. Ho testato questa configurazione su Ubuntu 24.04 LTS, ma funziona su qualsiasi distribuzione Debian-based. Serve un backend in ascolto su una porta locale, per esempio un’app Node.js sulla 3000 o un’app Python sulla 8000. Ti serve anche un dominio puntato all’IP del server per testare SSL con Let’s Encrypt.

Cos’è un reverse proxy e perché ogni server web dovrebbe averne uno (Nginx reverse proxy configurare)

Un reverse proxy sta davanti ai tuoi server applicativi. I client non parlano mai direttamente con Node.js, Python o PHP. Parlano con Nginx, che inoltra la richiesta al backend. Questo aggiunge uno strato di sicurezza fondamentale. Secondo W3Techs (2025), Nginx serve oltre il 34% dei siti web attivi. Se lo usi solo come web server statico, sprechi il 90% delle sue capacità. Quando configuri Nginx reverse proxy, centralizzi SSL, caching, rate limiting e load balancing in un unico punto. Il backend rimane isolato sulla rete interna.

Installare Nginx su Ubuntu/Debian

L’installazione richiede due comandi. Niente repo esterne.

sudo apt update
sudo apt install nginx -y

Verifica che il servizio parta correttamente.

sudo systemctl enable nginx
sudo systemctl start nginx
nginx -v

Se vedi la versione, Nginx è pronto. Rimuovi il server block di default per evitare conflitti.

sudo rm /etc/nginx/sites-enabled/default

Configurazione base: il primo server block

Crea un file di configurazione per il tuo dominio. Usa la cartella sites-available e crea un link simbolico in sites-enabled.

sudo nano /etc/nginx/sites-available/example.com

Inserisci la configurazione base. Questo block ascolta sulla porta 80 e serve da ingresso per il traffico.

server {
    listen 80;
    server_name example.com;
    location / {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Questo è il file minimo per far funzionare un Nginx reverse proxy. Abilita la configurazione e ricarica.

sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

proxy_pass — instradare il traffico verso il backend

La direttiva proxy_pass definisce dove Nginx manda la richiesta. Se hai un’app Node.js sulla porta 3000, proxy_pass http://localhost:3000; inoltra tutto il traffico lì. Puoi puntare a un IP interno, a una socket UNIX o a un gruppo di server upstream. Se il backend impiega più di 60 secondi per rispondere, Nginx restituisce un 504 Gateway Timeout. Regola i timeout per applicazioni lente.

proxy_connect_timeout 10s;
proxy_read_timeout 120s;
proxy_send_timeout 120s;

Header HTTP: X-Real-IP, X-Forwarded-For

Senza questi header, il backend vede l’IP interno di Nginx come sorgente. I log dell’applicazione diventano inutili per il tracciamento degli attacchi. X-Real-IP passa l’IP del client originale. X-Forwarded-For aggiunge l’IP del client alla catena di proxy. X-Forwarded-Proto dice al backend se la richiesta originale era HTTPS. Impostali sempre.

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;

SSL/TLS termination con Let’s Encrypt (certbot)

Gestire SSL sul backend è complesso e dispendioso. Con Nginx reverse proxy, termini la crittografia al perimetro. Il traffico tra Nginx e il backend viaggia in chiaro sulla rete locale. Installa Certbot per automatizzare i certificati Let’s Encrypt.

sudo apt install certbot python3-certbot-nginx -y

Ottieni il certificato. Certbot modifica il tuo server block automaticamente.

sudo certbot --nginx -d example.com

Il rinnovo automatico è già configurato. Verifica con un dry run.

sudo certbot renew --dry-run

Load balancing tra più backend

Se hai due o più istanze della stessa applicazione, Nginx distribuisce il traffico. Definisci un blocco upstream fuori dal server block.

upstream backend_node {
    server 10.0.0.1:3000;
    server 10.0.0.2:3000;
    server 10.0.0.3:3000;
}

Nel tuo server block, cambia il proxy_pass per puntare all’upstream.

proxy_pass http://backend_node;

Di default Nginx usa round-robin. Se un server ha più risorse, assegnagli un peso maggiore. server 10.0.0.1:3000 weight=3;

Cache con Nginx — ridurre il carico sul backend

Le richieste ripetute saturano la CPU del backend. Un benchmark NGINX Inc. (2024) mostra che il caching riduce il carico sul backend fino al 70% e dimezza i tempi di risposta. Configura una zona di cache in http context.

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m;

Nel tuo location block, attiva la cache.

location / {
    proxy_cache my_cache;
    proxy_pass http://backend_node;
    add_header X-Cache-Status $upstream_cache_status;
}

Rate limiting — proteggere le API

Il rate limiting blocca gli attacchi brute force e previene abusi sulle API. Definisci una zona di limite basata sull’IP del client.

limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

Applica il limite nel location block delle tue API. Il parametro burst permette picchi controllati.

location /api/ {
    limit_req zone=api burst=20 nodelay;
    proxy_pass http://backend_node;
}

Se un client supera le 10 richieste al secondo, Nginx restituisce un errore 429 Too Many Requests.

Configurazione per Node.js, Python (Gunicorn), PHP-FPM

Cambia il target di proxy_pass in base al tuo stack.

Per Node.js, l’app è in ascolto sulla 3000.

proxy_pass http://127.0.0.1:3000;

Per Python con Gunicorn, usa una socket UNIX per migliori performance.

proxy_pass http://unix:/run/gunicorn.sock;

Per PHP-FPM, non usare proxy_pass. Usa la direttiva fastcgi_pass.

location ~ \.php$ {
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
}

Errori comuni e troubleshooting

502 Bad Gateway: Nginx non raggiunge il backend. Controlla che l’app sia in esecuzione e che la porta o la socket UNIX siano corrette.

504 Gateway Timeout: Il backend impiega troppo a rispondere. Aumenta proxy_read_timeout o ottimizza il codice dell’applicazione.

Ciclo di redirect infinito: Succede se il backend fa redirect su HTTPS ma non legge l’header X-Forwarded-Proto. Assicurati che l’applicazione riconosca che il traffico originale è sicuro.

IP del server nei log dell’app: Hai dimenticato proxy_set_header X-Real-IP $remote_addr;. Aggiungilo e configura l’app per leggere l’header.

FAQ — Domande Frequenti

Come fare il debug di un Nginx reverse proxy che non inoltra il traffico?

Controlla i log di errore in /var/log/nginx/error.log. Esegui sudo nginx -t per verificare la sintassi. Assicurati che il firewall permetta il traffico sulla porta di ascolto e che SELinux o AppArmor non blocchino la connessione al backend.

Qual è la differenza tra Nginx reverse proxy e load balancer?

Un reverse proxy inoltra richieste a un singolo backend o a più backend. Un load balancer distribuisce il traffico tra più backend per scalabilità. Nginx fa entrambe le cose. La direttiva upstream con più server trasforma il proxy in un load balancer.

Come configurare Nginx reverse proxy per WebSocket?

Aggiungi gli header di upgrade nel location block. Le WebSocket richiedono una connessione persistente che Nginx deve mantenere attiva.

proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

Conclusioni con takeaway operativi

Un backend esposto direttamente è un bersaglio facile. Nginx reverse proxy isola le tue applicazioni, gestisce la crittografia e filtra il traffico dannoso. I tre passaggi fondamentali per mettere in sicurezza l’infrastruttura sono: configura proxy_pass per nascondere il backend, imposta SSL termination con Certbot per crittografare il traffico in entrata, e attiva limit_req per bloccare gli abusi sulle API. Non aspettare il primo attacco per proteggere i tuoi server.

Leggi anche

Leggi anche: Hardening SSH Linux: Guida Completa 2026 (10 Impostazioni Critiche)

Leggi anche: Fail2ban su Linux: Configurazione Completa e Sicurezza SSH

Leggi anche: UFW Firewall Ubuntu: Configurazione Completa dalla A alla Z (2026)

Aggiornato: Aprile 2026