Guida a nginx come reverse proxy
In questa pagina
Un reverse proxy si mette davanti alle tue applicazioni e passa loro le richieste dei visitatori. Con nginx davanti, un'app Node.js, un container Docker o una dashboard in ascolto su una porta qualsiasi diventa https://app.example.com, con HTTPS, header corretti e un unico punto da cui gestire tutto.
Questa guida configura nginx come reverse proxy su Ubuntu, passo dopo passo: il server block, gli header, i WebSocket, l'HTTPS gratuito e gli errori che incontrerai più spesso.
Cosa fa un reverse proxy
- Un solo punto di accesso pubblico. nginx ascolta sulle porte 80 e 443 e inoltra ogni dominio o percorso all'app giusta, così le app non sono mai esposte direttamente a internet.
- HTTPS in un solo posto. nginx gestisce i certificati; le app dietro di lui possono parlare in HTTP semplice su localhost.
- Più app su un solo server.
app.example.com,api.example.comeexample.com/blogpossono puntare ciascuno a un servizio diverso. - Extra: compressione, cache, limiti di upload e regole di accesso, senza toccare l'app.
Passo 1: installare nginx
sudo apt update sudo apt install nginx
Apri http://your-server-ip e dovresti vedere la pagina di benvenuto di nginx. Se usi ufw, consenti il traffico web con sudo ufw allow 'Nginx Full'.
Assicurati che la tua app sia in esecuzione e raggiungibile dal server stesso, per esempio con curl http://127.0.0.1:3000. Se questo non funziona, non funzionerà nemmeno nginx.
Esegui nginx e le tue app con accesso root completo: i piani VPS KVM di HytHost partono da €2.92/mese.
Vedi i piani VPSPasso 2: creare il server block del proxy
Su Ubuntu ogni sito ha un file in /etc/nginx/sites-available/, che si attiva con un link in sites-enabled. Crea /etc/nginx/sites-available/app.example.com:
server {
listen 80;
server_name app.example.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;
}
}
Attivalo, verifica la configurazione e ricarica:
sudo ln -s /etc/nginx/sites-available/app.example.com /etc/nginx/sites-enabled/ sudo nginx -t sudo systemctl reload nginx
Punta il record A del dominio al tuo server e http://app.example.com mostrerà la tua app. Esegui sempre nginx -t prima di ricaricare: individua gli errori di battitura prima che mandino giù il sito.
Gli header e lo slash finale
Hostpassa il dominio richiesto dal visitatore. Senza, nginx invia l'indirizzo diproxy_passe le app che costruiscono i link a partire dall'host si rompono.X-Real-IPeX-Forwarded-Forpassano l'indirizzo IP del visitatore. Senza, ogni richiesta sembra arrivare da127.0.0.1.X-Forwarded-Protodice all'app se il visitatore ha usato HTTPS, così non finisce in un loop di redirect.
Il pacchetto nginx di Ubuntu include già queste righe in /etc/nginx/proxy_params, quindi include proxy_params; è una scorciatoia.
Lo slash finale conta. Per un'app sotto un percorso:
location /app/ {
proxy_pass http://127.0.0.1:3000/;
}
Con lo slash dopo la porta, /app/login arriva all'app come /login. Senza, l'app riceve il percorso completo /app/login.
WebSocket
App di chat, dashboard in tempo reale e molti pannelli di amministrazione usano i WebSocket, che richiedono due header in più. Aggiungi questa map una sola volta, dentro il blocco http, per esempio in un nuovo file /etc/nginx/conf.d/websocket.conf:
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
Poi, nella location:
proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; proxy_read_timeout 1h;
nginx chiude una connessione in proxy che non invia nulla per 60 secondi; un proxy_read_timeout più lungo tiene aperti i WebSocket inattivi. proxy_http_version 1.1 è il valore predefinito solo da nginx 1.29.7, e Ubuntu 24.04 include la 1.24, quindi lascia la riga.
Passo 3: HTTPS gratuito con Certbot
sudo snap install --classic certbot sudo ln -s /snap/bin/certbot /usr/local/bin/certbot sudo certbot --nginx -d app.example.com
Certbot ottiene un certificato gratuito Let's Encrypt, aggiunge le impostazioni HTTPS al tuo server block e può reindirizzare HTTP su HTTPS. Rinnova il certificato in automatico; verificalo con sudo certbot renew --dry-run. Altro sui certificati in come ottenere un certificato SSL gratuito.
Risolvere gli errori 502, 504 e 413
| Errore | Causa tipica | Soluzione |
|---|---|---|
| 502 Bad Gateway | nginx non raggiunge l'app: è ferma, è andata in crash o ascolta su un'altra porta o indirizzo | Avvia l'app, controlla la porta con curl http://127.0.0.1:PORT, leggi /var/log/nginx/error.log |
| 504 Gateway Timeout | L'app ha impiegato più di 60 secondi a rispondere | Velocizza la richiesta o aumenta proxy_read_timeout per quella location |
| 413 Request Entity Too Large | Un upload supera il limite predefinito di nginx di 1 MB | Imposta client_max_body_size 50m; nel server block |
| Loop di redirect | L'app non sa che il visitatore ha usato HTTPS | Passa X-Forwarded-Proto e indica all'app che si trova dietro un proxy |
Dopo ogni modifica: sudo nginx -t, poi sudo systemctl reload nginx.
Usalo su un VPS HytHost
Un reverse proxy richiede un server su cui controlli le porte 80 e 443. I piani VPS di HytHost girano su KVM con accesso root completo, storage SSD e protezione DDoS; scegli Ubuntu 24.04 e segui i passi qui sopra. Usi i container per le tue app? Prima configura Docker con come installare Docker su Ubuntu e collega le porte dei container a 127.0.0.1, così solo nginx può raggiungerle.
Domande frequenti
Un reverse proxy inoltra le richieste a una o più app che stanno dietro. Un load balancer è un reverse proxy che distribuisce le richieste tra più copie della stessa app. nginx sa fare entrambe le cose, con un blocco upstream che elenca le copie.
nginx non riesce a raggiungere l'app che ha dietro. Controlla che l'app sia in esecuzione e in ascolto sull'indirizzo e sulla porta indicati in proxy_pass, e leggi /var/log/nginx/error.log per il motivo esatto.
No, se l'app gira sullo stesso server. nginx gestisce l'HTTPS per i visitatori e parla con l'app in HTTP semplice su 127.0.0.1, che non esce mai dalla macchina.
Dai a ogni app il suo server block con il suo server_name, come app.example.com e api.example.com, ciascuno con un proxy_pass verso una porta diversa.
Sì. Pubblica la porta di ogni container solo su 127.0.0.1 e punta proxy_pass su di essa. Così i container restano fuori dall'internet pubblico, cosa importante perché le porte pubblicate da Docker aggirano ufw.
Ospita le tue app dietro nginx
I piani VPS KVM di HytHost con accesso root completo, storage SSD e protezione DDoS partono da €2.92/mese.
Live chat 8 AM – 11 PM (Chișinău time) · tickets answered during business hoursQuesta guida ti è stata utile?