Proxy inverso Nginx con SSL

Se stai eseguendo un'applicazione Web su una porta privata (come Localhost: 3000), non è direttamente accessibile su Internet.Uno dei modi più efficaci per esporre quell'app in modo sicuro è quello di mettere un proxy inverso di fronte.

Nginx è uno strumento ben noto leggero che può fare esattamente questo-ricevere il traffico in arrivo e inoltrarlo alla tua app-gestendo anche HTTPS con un certificato SSL gratuito da Let's Crypt.

In questa guida, imparerai come:

• Imposta Nginx come proxy inverso per un servizio Web interno
  
• Proteggerlo con un certificato SSL utilizzando certbot
  
• Comprendi ogni parte della configurazione in modo da sapere cosa sta facendo e perché

Nuovo sui web server?Dai un'occhiata alla nostra spiegazione su Come funzionano i server web.

Cos'è un proxy inverso e perché usarne uno?

UN proxy inverso è un server che si trova tra i tuoi utenti e i servizi di backend.Invece di ascoltare la tua app pubblicamente su una porta (come 3000), Nginx riceve prima il traffico, quindi lo passa all'app in esecuzione in background.

Ecco perché questo approccio è così utile:

• Nasconde porte e servizi interni
  La tua app non deve essere esposta direttamente al pubblico.Ciò riduce la superficie di attacco e ti aiuta a controllare l'accesso.
  
• Gestisce HTTPS per te
  Molti quadri Web possono servire direttamente HTTPS, ma spesso è più facile e più affidabile lasciare che Nginx lo faccia, soprattutto quando si utilizzano certificati SSL gratuiti da Let's Crypt.
  
• Abilita l'hosting di più servizi su un server
  È possibile eseguire più app su porte diverse (come 3000, 4000, 5000) e instradare il traffico in base al dominio o al percorso utilizzando un solo IP pubblico.
  
• Migliora la registrazione e il monitoraggio
  Nginx fornisce accesso centralizzati di accesso e errori, quindi è più facile monitorare le prestazioni o indagare sui problemi.
  
• Fornisce memorizzazione nella cache, bilanciamento del carico e limitazione della velocità
  Puoi ottimizzare il flusso di traffico e proteggere i servizi di backend con poche linee extra nella configurazione Nginx.

Anche se la tua app può già gestire il traffico Web, l'utilizzo di NGINX come proxy inverso spesso semplifica l'impostazione, migliora la flessibilità e aumenta il controllo.

Prerequisiti

Prima di iniziare, assicuriamoci di avere tutto ciò di cui hai bisogno:

• Un VPS o Cloud Server che esegue Ubuntu 20.04 o successivo: La maggior parte dei comandi e delle versioni del pacchetto utilizzate in questo tutorial assumono un sistema basato su Debian.Mentre Nginx e CTERBOT lavorano su altre distribuzioni, il processo di installazione può differire.
• Accesso alla radice o sudo: Installererai pacchetti, modificando i file di sistema e riavviano servizi, tutti che richiedono privilegi elevati.
• Un nome di dominio registrato: Avrai bisogno di questo per richiedere un certificato SSL.Crittografia convalida la proprietà del tuo dominio prima di emettere un certificato.Senza DNS indicato sul tuo server, la convalida non riuscirà.
• DNS che indica l'IP pubblico del tuo server: Assicurati che i record DNS del tuo dominio siano aggiornati.Un semplice record che punta all'IP del tuo server è sufficiente:

A yourdomain.com → 123.123.123.123
A www.yourdomain.com → 123.123.123.123

La propagazione può richiedere qualche minuto a qualche ora.

Non sai come configurare il tuo DNS?Ecco Come aggiungere un record A con la maggior parte degli host di dominio.

• Un'applicazione in esecuzione su LocalHost (ad es. http://localhost:3000): Questa è l'app a cui verrai proxe.Potrebbe essere qualsiasi cosa - node.js, python blask, rubino sui binari, ecc. Finché ascolta su un porto locale, puoi proxy ad esso.

Nota: Se la tua app non è ancora in esecuzione, va bene, puoi comunque passare attraverso l'installazione e testare in seguito.

• Nginx installato: Nginx fungerà da server rivolto al pubblico.Se non è ancora installato:

sudo apt update
sudo apt install nginx

Quindi controlla che sia in esecuzione:

sudo systemctl status nginx

Dovresti vedere "Active (Running)".

• Certbot installato con il plugin NGINX: CertBot automatizza il processo di ottenimento e rinnovo dei certificati SSL da Let's Crypt.Installalo in questo modo:

sudo apt install certbot python3-certbot-nginx

Questo plugin consente a CERTBOT di modificare automaticamente la configurazione Nginx quando si richiede un certificato, nessuna modifica manuale richiesta per le configurazioni di base.

Hai un altro sistema operativo?Segui questa guida su Come installare Let's Cript su Fedora e Debian

Passaggio 1: impostare il proxy inverso Nginx

Ora che il tuo sistema è pronto, il primo vero passo è configurare Nginx per ascoltare il traffico sul tuo dominio e inoltrarlo alla tua applicazione interna: questo è ciò che fa sì che Nginx funzioni come proxy inverso.

Perché questo è importante

Senza questa configurazione, gli utenti che cercano di visitare il tuo sito Web colpiranno una pagina vuota o la schermata di benvenuto NGINX predefinita.Devi dire esplicitamente Nginx:

• A quale dominio dovrebbe rispondere
  
• Cosa fare con le richieste in arrivo
  
• Dove inviare il traffico dietro le quinte

Crea un nuovo blocco server

Creerai un file di configurazione per il tuo dominio nella directory disponibile dei siti di Nginx.Ciò mantiene organizzate le configurazioni e semplifica abilitare o disabilitare i singoli siti.

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

Incolla nel blocco seguente, regolare la porta del dominio e dell'app secondo necessità:

server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;

    location / {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;

        # Pass important headers to the backend
        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;
    }
}

Cosa fa questa configurazione

• Ascolta 80;
  Dice a NGINX di ascoltare il traffico HTTP sulla porta 80.
  
• server_name yourdomain.com www.yourdomain.com;
  Abbina questo blocco alle richieste effettuate al tuo dominio.È possibile aggiungere o rimuovere i sottodomini secondo necessità.
  
• posizione /
  Cattura tutte le richieste al root e le inoltra alla tua app.
  
• proxy_pass http: // localhost: 3000;
  Questo è il cuore del proxy inverso: invia la richiesta all'app di backend in esecuzione sulla porta 3000.
  
• linee proxy_set_header
  Questi dettagli di conservazione della richiesta del client originale, come:
  
  • L'indirizzo IP dell'utente (X-REAL-IP)
    
  • Il protocollo originale (HTTP o HTTPS)
    
  • Il nome host originale
    
• Queste informazioni sono utili per la registrazione, l'analisi o quando la tua app deve generare URL che corrispondono all'esperienza del visitatore.

Abilita la configurazione

Nginx utilizza collegamenti simbolici in abilitati ai siti directory per attivare i siti.Quindi ora creerai un link e ricaricherai nginx:

sudo ln -s /etc/nginx/sites-available/yourdomain.com /etc/nginx/sites-enabled/
sudo nginx -t

Controlla gli errori di sintassi.Se tutto sembra buono:

sudo systemctl reload nginx

Il tuo proxy inverso è ora in diretta - richieste http://yourdomain.com Verrà passato alla tua app sulla porta 3000.

Passaggio 2: aggiungi SSL con let's cript e certbot

Con il proxy inverso che lavora su HTTP, il passo successivo è proteggerlo con HTTPS.Ciò aggiunge crittografia a tutte le comunicazioni tra gli utenti e il server: proteggere le credenziali di accesso, le richieste API, i dati personali e altro ancora.

Utilizzerai Crypt, un'autorità di certificazione gratuita e CertBot, che automatizza il processo.

Perché HTTPS è importante

• Crittografa il traffico Quindi nessuno può intercettare o manometterlo
  
• Migliora SEO - I motori di ricerca preferiscono siti sicuri
  
• Costruisce la fiducia - Gli utenti si aspettano di vedere l'icona del lucchetto
  
• Richiesto per molte API, accessi e sistemi di pagamento

Richiedere il certificato

Esegui questo comando, sostituendo i domini con i valori effettivi:

sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

Cosa fa questo:

• Dice a certbot di utilizzare il plugin NGINX
  
• Specifica per quali domini stai richiedendo un certificato

Certbot lo farà:

• Eseguire la convalida del dominio creando un file temporaneo nella configurazione Nginx
  
• Contatta Let's Cript per verificare la proprietà del dominio
  
• Scarica il certificato SSL e la chiave privata
  
• Modifica la configurazione Nginx per utilizzare HTTPS
  
• Facoltativamente reindirizza tutto il traffico HTTP a HTTPS

Mancia: Se il tuo DNS non è completamente propagato o il tuo server firewall blocca la porta 80, la convalida fallirà.Puoi testare questo con:

curl -I http://yourdomain.com

Per comprendere meglio le porte, controlla la nostra guida su Come funzionano le porte del server Web.

Verificare le modifiche

Dopo il completamento di CertBot, la configurazione Nginx dovrebbe includere qualcosa del genere:

listen 443 ssl;
ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

Ora dovresti essere in grado di visitare https://yourdomain.com e vedere il tuo sito con un certificato SSL valido.

Facoltativo: forza HTTPS

Se non hai scelto l'opzione di reindirizzamento durante la configurazione di certbot, puoi aggiungerlo manualmente:

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

Ciò costringe tutto il traffico HTTP a essere reindirizzato a HTTPS, il che garantisce che gli utenti non utilizzino accidentalmente la versione non sicura del tuo sito.

Passaggio 3: migliorare le impostazioni SSL (consigliate per la produzione)

Una volta che il certificato SSL è in atto, puoi mettere a punto Nginx per migliorare la sicurezza e la compatibilità.Queste impostazioni vanno all'interno del blocco server HTTPS.

Ecco un esempio migliorato:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_session_tickets off;

Cosa fanno queste impostazioni

• ssl_protocols TLSv1.2 TLSv1.3
  Disabilita protocolli più vecchi e meno sicuri come TLS 1.0 e 1.1.
  
• ssl_prefer_server_ciphers on
  Consentono al tuo server di decidere l'algoritmo di crittografia, piuttosto che differire al browser, il che può ridurre l'esposizione a attacchi di cifratura deboli.
  
• ssl_ciphers High :! Anull :! Md5
  Specifica forti suite di cifra ed esclude quelle deboli o rotti (come MD5 e cifre null).
  
• ssl_session_cache e ssl_session_timeout
  Controlla il riutilizzo della sessione SSL, che può migliorare leggermente le prestazioni senza compromettere la sicurezza.
  
• ssl_session_tickets off
  Disabilita i biglietti della sessione, che possono essere un problema di sicurezza se non ruotato regolarmente.

Questi cambiamenti migliorano il punteggio di sicurezza SSL e proteggono i visitatori dagli attacchi di downgrade o dalle scelte di crittografia non sicure.

Opzionale: Puoi testare il tuo sito con SSL Labs per vedere come funziona la tua configurazione e ottenere suggerimenti di miglioramento specifici.

Passaggio 4: (opzionale) Aggiungi i parametri Diffie-Hellman

Per una crittografia ancora più forte, puoi generare una chiave Diffie-Hellman (DH) personalizzata.Questo passaggio è facoltativo, ma è spesso raccomandato per gli ambienti di produzione.

Esegui questo comando per generare un gruppo DH da 2048 bit:

sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

Quindi aggiungi la riga seguente al blocco server SSL:

ssl_dhparam /etc/ssl/certs/dhparam.pem;

Perché aggiungere questo?

I parametri Diffie-Hellman si rafforzano Segreto in avanti, il che significa che anche se la tua chiave privata è in qualche modo compromessa in futuro, le sessioni crittografate passate saranno comunque sicure.

Ci vogliono alcuni minuti per generare il gruppo DH, ma è un passo una tantum e vale la pena fare per una migliore postura della sicurezza.

Passaggio 5: impostare il rinnovo automatico per i certificati SSL

Crittiamo i certificati scadono ogni 90 giorni.Fortunatamente, CertBot installa un timer di sistema che controlla due volte al giorno per i certificati a causa della scadenza e rinnovali automaticamente.

Puoi confermare che il timer è attivo con:

sudo systemctl list-timers | grep certbot

Dovresti vedere qualcosa di simile:

NEXT                         LEFT    LAST                         PASSED  UNIT           ACTIVATES
2025-06-19 04:00:00 UTC      12h     2025-06-18 04:00:00 UTC       11h ago certbot.timer  certbot.service

Per testare manualmente il processo di rinnovo (senza apportare modifiche), eseguire:

sudo certbot renew --dry-run

Questo simula l'intero processo di rinnovo e conferma che il tuo sistema è pronto a gestirlo automaticamente.

Se non ci sono errori, i certificati si rinnoveranno tranquillamente in background in futuro.

Passaggi finali e buone abitudini

Ora che il tuo proxy inverso è impostato e fissato con SSL, è una buona idea concludere con alcuni controlli pratici e le migliori pratiche.

Queste semplici abitudini possono aiutare a prevenire i problemi lungo la linea, semplificare la configurazione e assicurarsi che tutto continui a funzionare come ti aspetti.

Anche se tutto sembra funzionare, passare qualche minuto in più qui può farti risparmiare tempo e problemi in seguito.

Riavvia l'app se non rileva automaticamente le modifiche
Alcune app devono essere riavviate per funzionare correttamente dietro un proxy.

Controlla i registri
È possibile monitorare i registri NGINX per errori o traffico insolito:

sudo tail -f /var/log/nginx/access.log
sudo tail -f /var/log/nginx/error.log

Mantieni aggiornati Nginx e CertBot
Usa Sudo Apt Update && Sudo Apt Aggiorna regolarmente.I pacchetti aggiornati fissano i bug, migliorano la compatibilità e i problemi di sicurezza delle patch.

Casi d'uso avanzati per il proxy inverso Nginx con SSL

Una volta padroneggiata le basi della configurazione di un proxy inverso sicuro, è possibile estendere la configurazione per supportare esigenze più complesse.Ecco alcuni scenari comuni che possono aiutarti a ottenere di più dal tuo server.

Ospitare più applicazioni su un server

Se si eseguono diverse app Web su porte diverse, NGINX può instradare le richieste a ciascuna app in base al percorso di dominio o URL.

Esempio: domini diversi

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

    location / {
        proxy_pass http://localhost:3001;
        # proxy headers here
    }
}

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

    location / {
        proxy_pass http://localhost:3002;
        # proxy headers here
    }
}

Questa configurazione consente di servire più app utilizzando sottodomi separati, tutti tramite NGINX su porte standard.

Usando Docker?Imparare Come proxy di più app Docker con Nginx.

Proxy basato sul percorso

In alternativa, puoi proxy in base ai percorsi URL, che è utile se si desidera tutte le app in un singolo dominio:

server {
    listen 80;
    server_name example.com;

    location /app1/ {
        proxy_pass http://localhost:3001/;
        # proxy headers here
    }

    location /app2/ {
        proxy_pass http://localhost:3002/;
        # proxy headers here
    }
}

Nota: Quando si utilizzano proxy basati su percorsi, le barre di trailing e la riscrittura dell'URL possono diventare difficili, assicurati che la tua app di backend sia in grado di gestire il servizio in un percorso secondario.

Aggiunta della tariffa limitante per proteggere la tua app

È possibile limitare quante richieste può effettuare un cliente in un determinato lasso di tempo per proteggere il backend da abusi o sovraccarico accidentale.

Aggiungi questo nel blocco HTTP in /etc/nginx/nginx.conf:

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

Quindi nel tuo server o blocco di posizione:

limit_req zone=mylimit burst=20 nodelay;

Questa configurazione consente 10 richieste al secondo con esplosioni di un massimo di 20 richieste, eliminando le richieste in eccesso per evitare di schiacciare la tua app.

Carica il bilanciamento su più server back -end

Se hai diverse istanze della tua app in esecuzione (ad esempio, più contenitori o VPS), NGINX può distribuire il traffico tra loro:

upstream backend {
    server 192.168.1.10:3000;
    server 192.168.1.11:3000;
}

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend;
        # proxy headers here
    }
}

Nginx bilance richieste round-robin per impostazione predefinita, ma è possibile configurarlo per altri metodi come le connessioni minime o hash IP.

Per saperne di più, dai un'occhiata alla nostra guida su Bilanciamento del carico DNS.

Registrazione e debug

È possibile personalizzare la registrazione per includere importanti informazioni proxy per la risoluzione dei problemi o l'analisi:

log_format proxy '$remote_addr - $remote_user [$time_local] '
                 '"$request" $status $body_bytes_sent '
                 '"$http_referer" "$http_user_agent" '
                 'upstream_response_time $upstream_response_time '
                 'request_time $request_time';

access_log /var/log/nginx/proxy_access.log proxy;

Questo registra tempi di risposta a monte e tempi di richiesta totali, aiutando a identificare le risposte al backend lente.

Intestazioni personalizzate e miglioramenti della sicurezza

Potresti voler aggiungere o modificare le intestazioni HTTP per la sicurezza o la funzionalità:

add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
add_header Referrer-Policy no-referrer-when-downgrade;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Queste intestazioni proteggono dal clickjacking, dall'annusamento di mime e applicano l'utilizzo di HTTPS.