nginx Reverse Proxy: tutorial completo di configurazione

Un nginx reverse proxy è un server nginx che accetta le richieste in entrata per conto di una o più applicazioni backend, quindi inoltra ogni richiesta al backend corretta e restituisce la risposta al client. Questo tutorial ti offre una configurazione nginx reverse proxy completa e pronta da copiare: un blocco server completo con proxy_pass e header inoltrati, bilanciamento del carico upstream, terminazione SSL, supporto WebSocket, regolazione di buffering e timeout, gzip, routing basato sulla posizione e soluzioni per gli errori 502 e 504 che mettono in difficoltà la maggior parte delle persone.

Alla fine avrai una configurazione nginx reverse proxy eseguibile, un modello mentale di come si incastrano i vari elementi e una valutazione onesta di quando un nginx reverse proxy non è più lo strumento giusto e subentra un forward o residential proxy.

DataImpulse è un fornitore di proxy etici che offre oltre 90 milioni di indirizzi IP residenziali, mobile e datacenter in 195 paesi. Utilizza un modello pay-as-you-go a partire da 1 dollaro per GB con traffico senza scadenza, ed è usato per web scraping, ad verification, monitoraggio dei prezzi, ricerche di mercato e gestione di più account.

nginx è un reverse proxy e come funziona?

Sì, nginx è uno dei reverse proxy più diffusi e il reverse proxying è una funzionalità primaria, non un componente aggiuntivo. Un reverse proxy si colloca davanti ai tuoi server backend, accetta connessioni client su un hostname pubblico e instrada ogni richiesta a un’applicazione interna che il client non vede mai direttamente.

Per distinguere bene le parti in movimento, questa guida usa un semplice modello con un nome. Chiamalomodello nginx reverse proxy a 5 livelli: ogni configurazione funzionante qui sotto è semplicemente composta da questi livelli, nell’ordine indicato:

• Ascoltatore.La direttivaAscoltare e nome_serverdecidono quali richieste gestiscono questo blocco, ovvero porta 80, porta 443 e hostname.
• Itinerario per posizione.Io bloccoposizionedividono i percorsi in entrata, in modo che/api/, /statico/ e /ciascuno può puntare a una destinazione diversa.
• A monte.Il bloccoa monteassegnare un nome al pool di server backend e al metodo di bilanciamento del carico.
• Intestazione.Le righeproxy_set_headerpreservano l’Host originale e l’IP del client, affinché il backend veda la richiesta reale, non nginx.
• TLS. certificato_ssl su ascolta 443termina HTTPS in nginx, così i backend possono parlare HTTP in chiaro internamente.

Se devi ancora scegliere tra le due direzioni del proxy, la nostra spiegazione diproxy inverso vs proxy in avantitratta il concetto in modo completo. Questo articolo riguarda solo il caso inverso. Per la configurazione in uscita lato client, consultare la guida complementare sunginx avanti proxy.

Di cosa hai bisogno prima di iniziare?

Ti servono un server Linux con nginx installato, almeno un’applicazione backend in ascolto su una porta locale e, per HTTPS, un certificato TLS. Il reverse proxying usa solo la build standard di nginx, quindi non sono necessari moduli personalizzati né ricompilazione.

Prima di modificare qualsiasi cosa, verifica che nginx sia presente e che la tua configurazione sia valida:

nginx -v
sudo nginx -t

Lo provonginx -tanalizza l’intera configurazione e segnala gli errori di sintassi con file e numero di riga. Eseguilo dopo ogni modifica di questo tutorial, perché nginx rifiuterà di ricaricare una configurazione non valida e lascerà attiva quella precedente. Inserisci i blocchi server del reverse proxy in/etc/nginx/conf.d/ o /etc/nginx/siti-disponibili/in base alla distribuzione e ricarica consudo nginx -s ricaricadopo che il test è riuscito. Tieni pronto anche l’indirizzo del backend, ad esempio un’app Node o Python su127.0.0.1:3000, dato che è la destinazione a cui punterà proxy_pass.

Come si configura passo dopo passo un nginx reverse proxy?

Inizia con un singolo blocco server in ascolto sulla porta 80, inoltra ogni richiesta a un backend con proxy_pass e imposta le intestazioni inoltrate. Quindi aggiungi bilanciamento del carico, TLS, WebSocket, buffering e gzip. Questo primo blocco è la configurazione minima funzionante di nginx reverse proxy:

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;
    }
}

Quei quattroproxy_set_headerle linee non sono facoltative. Senza di essi il backend vede nginx come client, registra lo IP sbagliato e può creare reindirizzamenti URL non funzionanti.Ospiteconserva il nome host richiesto,X-Real-IPEX-Inoltrato-Perportare il vero indirizzo del cliente eX-Forwarded-Protoindica all’app se la richiesta originale era HTTP o HTTPS.

Aggiungi il bilanciamento del carico a monte.Per stare di fronte a diverse istanze di backend, definisci ana montebloccare e puntare proxy_pass al suo nome. ILalmeno_connIl metodo invia ciascuna richiesta all’istanza con il minor numero di connessioni attive:

upstream app_backend {
    least_conn;
    server 10.0.0.11:3000;
    server 10.0.0.12:3000;
    server 10.0.0.13:3000 backup;
}

server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://app_backend;
        proxy_set_header Host              $host;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

ILbackupil server riceve traffico solo quando i server primari sono inattivi. Scambiaip_hashinvece dialmeno_connse hai bisogno dello stesso client bloccato sullo stesso backend per sticky session.

Termina SSL sulla porta 443.I proxy inversi di produzione dovrebbero servire HTTPS e reindirizzare il semplice HTTP. nginx gestisce TLS in modo che i tuoi backend possano rimanere su HTTP internamente:

server {
    listen 443 ssl;
    server_name app.example.com;

    ssl_certificate     /etc/letsencrypt/live/app.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;

    location / {
        proxy_pass http://app_backend;
        proxy_set_header Host              $host;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

server {
    listen 80;
    server_name app.example.com;
    return 301 https://$host$request_uri;
}

Supporta WebSocket.Le connessioni WebSocket iniziano come HTTP e poi si aggiornano, quindi nginx deve passare le intestazioni Upgrade e Connection e utilizzare HTTP/1.1. Assegna ai percorsi in tempo reale la propria posizione:

location /ws/ {
    proxy_pass http://app_backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade    $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host       $host;
    proxy_read_timeout 3600s;
}

Il lungoproxy_read_timeoutimpedisce la chiusura dei socket inattivi durante la sessione, una causa comune di interruzione delle connessioni attive.

Ottimizza buffering e timeout.I valori predefiniti sono conservativi; i backend lenti beneficiano di valori espliciti quindi nginx non chiude una connessione prima che l’app risponda:

location / {
    proxy_pass http://app_backend;
    proxy_connect_timeout 5s;
    proxy_send_timeout    60s;
    proxy_read_timeout    60s;
    proxy_buffering       on;
    proxy_buffers         16 16k;
    proxy_buffer_size     32k;
}

Abilita gzip.La compressione delle risposte proxy riduce la larghezza di banda per le risorse di testo. Metti questo nelhttpblock in modo che si applichi a tutto il sito:

gzip on;
gzip_types text/plain text/css application/json application/javascript;
gzip_min_length 1024;
gzip_comp_level 5;

Itinerario per sentiero.Un proxy inverso può gestire diversi servizi abbinando diversi prefissi di posizione a diversi upstream, servendo file statici direttamente dal disco senza toccare un backend:

server {
    listen 80;
    server_name example.com;

    location /api/ {
        proxy_pass http://api_backend;
        proxy_set_header Host $host;
    }

    location /static/ {
        root /var/www/assets;
    }

    location / {
        proxy_pass http://web_backend;
        proxy_set_header Host $host;
    }
}

Come si verifica il funzionamento di nginx reverse proxy?

Ricarica nginx, quindi invia una richiesta al nome host pubblico e conferma che la risposta proviene dal tuo backend anziché da una pagina nginx predefinita. Testare prima la configurazione in modo che un errore di battitura non blocchi il sito:

sudo nginx -t && sudo nginx -s reload
curl -I http://app.example.com

A 200o un reindirizzamento previsto nelle intestazioni della risposta significa che il routing funziona. Per dimostrare che il backend sta ricevendo le intestazioni inoltrate, controlla il suo registro di accesso o un endpoint echo e conferma che vede il vero client IP daX-Inoltrato-Per, non127.0.0.1. Puoi anche ignorare il DNS e prendere di mira direttamente proxy mentre esegui lo spoofing del nome host:

curl -H "Host: app.example.com" http://127.0.0.1

Per HTTPS, eseguicurl -I https://app.example.come verificare che il certificato venga accettato e che la richiesta non venga declassata. Se il backend esegue il rendering di collegamenti o reindirizzamenti con lo schema sbagliato, si tratta quasi sempre di un erroreX-Forwarded-Protointestazione anziché un errore TLS.

Come si risolvono gli errori 502 e 504?

Un 502 Bad Gateway significa che nginx ha raggiunto l’upstream ma ha ricevuto una risposta non valida o rifiutata, mentre un 504 Gateway Timeout significa che l’upstream ha accettato la connessione ma non ha risposto in tempo. Entrambi sono problemi upstream, non bug nginx, e il registro degli errori indica la causa esatta. Guardalo in diretta mentre riproduci la richiesta:

sudo tail -f /var/log/nginx/error.log
# [error] connect() failed (111: Connection refused) while connecting to upstream

Risolvi le solite cause in ordine:

• 502, connessione rifiutata.Il backend non è in esecuzione o è in ascolto su un indirizzo o una porta diversa rispetto alle destinazioni proxy_pass. Conferma conarricciatura http://127.0.0.1:3000sul server stesso.
• 502, SELinux o firewall.Sui sistemi della famiglia RHEL, SELinux impedisce a nginx di aprire connessioni in uscita fino all’esecuzionesetsebool -P httpd_can_network_connect 1.
• 504, backend lento.L’app richiede più tempo diproxy_read_timeoutper rispondere. Aumenta il timeout per quella posizione o correggi la query lenta, anziché mascherarla a livello globale.
• 502, intestazioni grandi.Un backend che invia intestazioni di risposta di grandi dimensioni può traboccare i buffer proxy. Aumentoproxy_dimensione_bufferEproxy_buffer.
• Scelta sbagliata a monte.Se un server in un pool upstream è inattivo, nginx lo contrassegna come non integro e riprova con il successivo, quindi i 502 intermittenti spesso puntano a un singolo backend non integro.

Quale proxy inverso è adatto e quando è necessario un proxy diverso?

Utilizza un nginx reverse proxy quando termini TLS, bilanciamento del carico o percorsi di instradamento davanti ai tuoi server; raggiungere un inoltro o residential proxy quando il lavoro invia richieste in uscita da molti IP. nginx è eccellente per il lavoro in entrata e non è progettato per quello in uscita. Ecco la matrice decisionale:

• Usa un nginx inverso proxy quandoospiti il ​​backend, desideri un endpoint HTTPS pubblico su diversi servizi interni, hai bisogno del bilanciamento del carico tra le istanze o desideri la memorizzazione nella cache e gzip sul perimetro.
• Evita nginx come proxy quandol’obiettivo sono le richieste in uscita che devono sembrare provenire da molti IP o paesi diversi, perché un proxy inverso esce dal tuo singolo server IP e non può ruotare gli indirizzi.

Tra i proxy inversi in particolare, nginx, Caddy e HAProxy effettuano diversi compromessi:

Per l’automazione pesante in uscita, il nsweb scraping migliori pratichela guida copre la rotazione e il controllo della velocità eProxy datacenter or Proxy mobilesono adatti a lavori in cui il costo o il vettore IP contano più della fedeltà residenziale.

Quali sono le limitazioni e i rischi di un nginx reverse proxy?

Un nginx reverse proxy è potente per il traffico in entrata ma presenta dei limiti reali: non può ruotare gli IP in uscita, le intestazioni configurate in modo errato perdono o nascondono il client e aggiunge un componente operativo che deve essere patchato e monitorato. Conoscere queste cose mantiene le aspettative oneste.

• Uscita singola IP.Ogni richiesta in uscita da proxy passa attraverso il IP del server, quindi un proxy inverso non può essere d’aiuto con attività che richiedono molti indirizzi di origine.
• Gli errori di intestazione sono silenziosi.DimenticareX-Inoltrato-Pernasconde il vero client IP dalla tua app e la sua limitazione di velocità; dimenticareX-Forwarded-Protointerrompe i reindirizzamenti HTTPS. nginx non ti avviserà.
• TLS e manutenzione dei certificati.I certificati scadono, quindi sei tu a dover rinnovarli e ricaricarli, solitamente tramite certbot e un lavoro cron o un timer systemd.
• Un nuovo punto di fallimento.proxy si trova ora nel percorso critico; se si guasta, ogni backend dietro di esso è irraggiungibile, motivo per cui i controlli di integrità e il monitoraggio sono importanti.
• Non è uno strumento di anonimato in uscita.Un proxy inverso non è costruito per mascherare la provenienza delle richieste. Questo è il compito dell’attaccante proxy.

nginx non è un prodotto DataImpulse e DataImpulse non vende uno scraping gestito API o un web proxy gratuito. Esegui nginx dove si adatta; dove è necessaria la scala in uscita, DataImpulse genera i suoi IP comedeleghe etichedagli utenti che aderiscono e ricevono un compenso. Ultimo aggiornamento: 22-07-2026.

Frequently asked questions

Guide correlate

• Proxy di inoltro NGINX
• Cloudflare Reverse Proxy
• Proxy inverso Docker

Hai bisogno di IP in uscita che nginx non può ruotare?

Un proxy inverso gestisce il traffico in entrata, ma quando il tuo lavoro necessita di richieste in uscita da molti IP reali, DataImpulse aggiunge oltre 90 milioni di residenziali a rotazione, mobile e datacenter IP in 195 paesi, con pagamento in base al consumo da un dollaro per GB con traffico senza scadenza.Creare un accountper ottenere le credenziali del gateway e instradare il client nel pool.