VPS · Guida

Guida a nginx come reverse proxy

Aggiornato October 11, 2026 5 min di lettura

In questa pagina
  1. Cosa fa un reverse proxy
  2. Passo 1: installare nginx
  3. Passo 2: creare il server block del proxy
  4. Gli header e lo slash finale
  5. WebSocket
  6. Passo 3: HTTPS gratuito con Certbot
  7. Risolvere gli errori 502, 504 e 413
  8. Usalo su un VPS HytHost
  9. FAQ

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.com e example.com/blog possono 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 VPS

Passo 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

  • Host passa il dominio richiesto dal visitatore. Senza, nginx invia l'indirizzo di proxy_pass e le app che costruiscono i link a partire dall'host si rompono.
  • X-Real-IP e X-Forwarded-For passano l'indirizzo IP del visitatore. Senza, ogni richiesta sembra arrivare da 127.0.0.1.
  • X-Forwarded-Proto dice 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

ErroreCausa tipicaSoluzione
502 Bad Gatewaynginx non raggiunge l'app: è ferma, è andata in crash o ascolta su un'altra porta o indirizzoAvvia l'app, controlla la porta con curl http://127.0.0.1:PORT, leggi /var/log/nginx/error.log
504 Gateway TimeoutL'app ha impiegato più di 60 secondi a rispondereVelocizza la richiesta o aumenta proxy_read_timeout per quella location
413 Request Entity Too LargeUn upload supera il limite predefinito di nginx di 1 MBImposta client_max_body_size 50m; nel server block
Loop di redirectL'app non sa che il visitatore ha usato HTTPSPassa 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.

FAQ

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 hours

Questa guida ti è stata utile?