Hostwinds Tutorial
Cerca risultati per:
Sommario
Tag: Cloud Servers, SSL, VPS
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:
Nuovo sui web server?Dai un'occhiata alla nostra spiegazione su Come funzionano i server web.
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:
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.
Prima di iniziare, assicuriamoci di avere tutto ciò di cui hai bisogno:
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.
Nota: Se la tua app non è ancora in esecuzione, va bene, puoi comunque passare attraverso l'installazione e testare in seguito.
sudo apt update
sudo apt install nginx
Quindi controlla che sia in esecuzione:
sudo systemctl status nginx
Dovresti vedere "Active (Running)".
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
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.
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:
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;
}
}
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.
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.
Esegui questo comando, sostituendo i domini con i valori effettivi:
sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com
Cosa fa questo:
Certbot lo farà:
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.
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.
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.
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;
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.
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;
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.
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.
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.
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.
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.
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.
È 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.
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.
È 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.
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.
Scritto da Hostwinds Team / giugno 14, 2019