Configurare un reverse proxy con Nginx

Nginx e il reverse proxy più usato al mondo: leggero, veloce, configurabile, supporta HTTP/2 e HTTP/3, caching, load balancing, terminazione SSL. Configurare correttamente un reverse proxy permette di centralizzare TLS, esporre servizi interni in modo controllato e ottimizzare le performance.

Cosa fa un reverse proxy

Un reverse proxy riceve richieste dai client e le inoltra a uno o più server applicativi (upstream), restituendo la risposta come se fosse il server originale. Permette di nascondere la topologia interna, gestire SSL in un punto unico, fare caching, comprimere risposte, applicare rate limiting e header di sicurezza. E un componente centrale in architetture moderne.

Esempio base

Una configurazione minima per esporre un'app Node.js sulla porta 3000 dietro Nginx prevede un blocco server in ascolto su 80/443, un location / con direttiva proxy_pass http://127.0.0.1:3000; e gli header per preservare l'IP del client originale: proxy_set_header Host $host;, X-Real-IP, X-Forwarded-For, X-Forwarded-Proto.

Procedura passo-passo

1. Installa Nginx: apt install nginx.
2. Crea un file in /etc/nginx/sites-available/myapp.conf.
3. Definisci server_name, listen e blocco location con proxy_pass.
4. Aggiungi gli header X-Real-IP, X-Forwarded-For, Host.
5. Abilita HTTP/2 e TLS con certificato Let s Encrypt (certbot --nginx).
6. Configura compressione gzip e/o brotli.
7. Aggiungi header di sicurezza: Strict-Transport-Security, X-Frame-Options, Content-Security-Policy.
8. Imposta rate limiting con limit_req_zone.
9. Abilita symlink in sites-enabled e ricarica con nginx -t && systemctl reload nginx.
10. Monitora i log e le metriche (stub_status + Prometheus exporter).

Caching

Nginx puo cachare risposte upstream con proxy_cache_path. Definisci una zona, attiva proxy_cache in location e imposta proxy_cache_valid per i codici di stato. Utile per API con risposte stabili o asset statici dietro app dynamic.

Load balancing

Definisci un blocco upstream con più server e specifica un'algoritmo: round-robin (default), least_conn, ip_hash per sessioni sticky. Aggiungi parametri max_fails e fail_timeout per health check passivi.

Errori comuni e come risolverli

• IP client perso: imposta X-Forwarded-For e configura set_real_ip_from a monte.
• WebSocket non funzionano: aggiungi proxy_http_version 1.1 e header Upgrade.
• SSL backend self-signed: proxy_ssl_verify off solo se davvero necessario.
• Buffer troppo piccoli: configura proxy_buffers per risposte grandi.

Domande frequenti

D: Nginx o HAProxy come reverse proxy?
R: Nginx eccelle per HTTP e caching; HAProxy per pure load balancing TCP/HTTP a basso latency.

D: Posso usare Nginx come API gateway?
R: Si per scenari semplici; per logica complessa preferisci Kong o Traefik.

D: HTTP/3 e già stabile?
R: Si dal 2023; abilitalo con il modulo QUIC nelle versioni recenti di Nginx.

Approfondimento tecnico: rate limiting e mTLS

Il rate limiting in Nginx si configura con due direttive: limit_req_zone definisce una zona condivisa di memoria con chiave (tipicamente IP client) e rate; limit_req applica la zona a una location con eventuale burst e nodelay. Esempio: limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s; consente 10 richieste/secondo per IP con buffer di burst.

L mTLS (mutual TLS) richiede certificati client validi oltre a quelli server: utile per API B2B. Nginx lo configura con ssl_client_certificate (CA fidata), ssl_verify_client on. La distribuzione dei certificati ai client e la parte difficile: tipicamente una CA interna o un servizio come step-ca.

Scenari d'uso reali

Una API pubblica protegge gli endpoint pesanti con rate limit 5 req/s + JWT auth: spammers respinti, utenti legittimi non penalizzati.

Una partner integration B2B usa mTLS per identificare 12 partner certificati senza gestire API key.

Un e-commerce usa Nginx come reverse proxy davanti a 4 worker Node.js, caching delle pagine prodotto in shared memory, rate limit per IP sui form di checkout.

Checklist operativa Nginx reverse proxy

• HTTPS obbligatorio con HSTS abilitato.
• Header X-Real-IP e X-Forwarded-For inoltrati.
• HTTP/2 e HTTP/3 dove possibile.
• Gzip o Brotli per compressione.
• Rate limiting su endpoint sensibili.
• Cache configurata per asset e API stabili.
• Logging strutturato e monitoraggio.

Risorse e riferimenti

nginx.org/en/docs. Mozilla SSL Configuration Generator. Certbot per Let s Encrypt. Per WAF: ModSecurity con OWASP CRS. Alternative reverse proxy: Caddy (HTTPS automatico), Traefik (cloud-native).

Considerazioni economiche e organizzative

Implementare correttamente quanto descritto in questo articolo su configurare un reverse proxy con nginx richiede tempo, formazione e talvolta investimenti hardware o software. La buona notizia e che il ritorno e quasi sempre positivo: meno incidenti, meno tempo speso in troubleshooting reattivo, maggiore predicibilita dei servizi. Stima sempre il costo del downtime per il tuo business: anche poche ore l'anno di indisponibilita possono giustificare investimenti che a prima vista sembrano sovradimensionati.

Sul piano organizzativo, la documentazione e il fattore decisivo. Un sistema brillantemente configurato ma non documentato e una bomba a orologeria: il giorno in cui il sysadmin originale lascia l'azienda, ogni intervento diventa archeologia. Mantieni runbook aggiornati, versionali in git, fai pratica di lettura nei momenti di calma e non solo durante gli incidenti.

Glossario rapido dei termini chiave

RTO (Recovery Time Objective): tempo massimo entro cui un servizio deve tornare operativo dopo un'incidente. RPO (Recovery Point Objective): perdita massima accettabile di dati misurata nel tempo (es. 1 ora di transazioni). SLA (Service Level Agreement): contratto formale che definisce livelli di servizio e penali. SLO/SLI (Service Level Objective/Indicator): metriche interne di qualità usate per misurare e mantenere lo SLA. MTBF/MTTR: tempo medio tra guasti e tempo medio di ripristino, indicatori di affidabilità. Idempotenza: proprietà di un'operazione che, applicata più volte, produce lo stesso risultato della singola applicazione (fondamentale per automazione).

Hai bisogno di aiuto?

Se hai dubbi sulla gestione server, il team di G Tech Group puo aiutarti. Contattaci tramite il modulo di contatto.