Node.js + Nginx - E adesso?


1003

Ho impostato Node.js e Nginx sul mio server. Ora voglio usarlo, ma prima di iniziare ci sono 2 domande:

  1. Come dovrebbero lavorare insieme? Come devo gestire le richieste?
  2. Esistono 2 concetti per un server Node.js, quale è meglio:

    un. Crea un server HTTP separato per ogni sito Web che ne ha bisogno. Quindi caricare tutto il codice JavaScript all'avvio del programma, in modo che il codice venga interpretato una volta.

    b. Creare un singolo server Node.js che gestisca tutte le richieste Node.js. Questo legge i file richiesti e ne valuta il contenuto. Quindi i file vengono interpretati su ogni richiesta, ma la logica del server è molto più semplice.

Non è chiaro per me come utilizzare Node.js correttamente.

Risposte:


1306

Nginx funziona come un server front-end, che in questo caso inoltra le richieste a un server node.js. Pertanto è necessario impostare un file di configurazione nginx per il nodo.

Questo è quello che ho fatto nella mia scatola Ubuntu:

Crea il file yourdomain.comsu /etc/nginx/sites-available/:

vim /etc/nginx/sites-available/yourdomain.com

In esso dovresti avere qualcosa di simile:

# the IP(s) on which your node server is running. I chose port 3000.
upstream app_yourdomain {
    server 127.0.0.1:3000;
    keepalive 8;
}

# the nginx server instance
server {
    listen 80;
    listen [::]:80;
    server_name yourdomain.com www.yourdomain.com;
    access_log /var/log/nginx/yourdomain.com.log;

    # pass the request to the node.js server with the correct headers
    # and much more can be added, see nginx config options
    location / {
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header Host $http_host;
      proxy_set_header X-NginX-Proxy true;

      proxy_pass http://app_yourdomain/;
      proxy_redirect off;
    }
 }

Se si desidera che nginx (> = 1.3.13) gestisca anche le richieste di socket Web, aggiungere le seguenti righe nella location /sezione:

proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

Una volta che hai questa configurazione devi abilitare il sito definito nel file di configurazione sopra:

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

Crea l'app del tuo nodo server su /var/www/yourdomain/app.jsed eseguila sulocalhost:3000

var http = require('http');

http.createServer(function (req, res) {
    res.writeHead(200, {'Content-Type': 'text/plain'});
    res.end('Hello World\n');
}).listen(3000, "127.0.0.1");
console.log('Server running at http://127.0.0.1:3000/');

Test per errori di sintassi:

nginx -t

Riavvia nginx:

sudo /etc/init.d/nginx restart

Avviare infine il nodo server:

cd /var/www/yourdomain/ && node app.js

Ora dovresti vedere "Hello World" su yourdomain.com

Un'ultima nota per quanto riguarda l'avvio del nodo server: dovresti usare un qualche tipo di sistema di monitoraggio per il demone del nodo. C'è un fantastico tutorial sul nodo con upstart e monit .


11
Grazie per il post, nginx memorizzerà nella cache le risposte node.js per il server sopra o le eseguirà di nuovo ogni volta.
Lime,

79
C'è qualche motivo per cui non puoi semplicemente farlo location / { proxy_pass http://127.0.0.1:3000; }? Perché hai bisogno di tutto il upstreambit di configurazione?
Robin Winslow,

20
+1, Risposta molto diretta e semplice a una domanda comune; ottimo per le persone che vogliono configurare host virtuali usando node e nginx. L'unica cosa che penso ti sia sfuggita è una risposta qualitativa al perché nginx-in-front-of-node è la soluzione migliore per servire più host (seconda domanda di Asker).
Paul d'Aoust,

34
@Robin Winslow nel caso in cui si desideri aggiungere più server per server per il bilanciamento del carico.
Joao Da Silva,

76
Va notato che questa risposta (molto utile) si riferisce a un sapore di nginx che, per impostazione predefinita, viene fornito con sites-enablede sites-availabledirectory all'interno /etc/nginx. Se la tua versione è arrivata senza queste due directory, probabilmente ha una sola conf.ddirectory. In tal caso, seguire queste istruzioni non avrebbe alcun effetto, A MENO CHE non si modifichi l' includeistruzione all'interno del file nginx.confin modo che punti sites-enabledinvece del valore predefinito conf.d. Spero che abbia un senso. Dovrebbe diventare autoesplicativo una volta che vedi la suddetta includeaffermazione all'interno nginx.conf.
Meetamit

167

Puoi anche configurare più domini con nginx, inoltrando a più processi node.js.

Ad esempio per raggiungere questi:

Queste porte (4000 e 5000) devono essere utilizzate per ascoltare le richieste dell'app nel codice dell'app.

/ Etc / nginx / sites-enabled / domain1

server {
    listen 80;
    listen [::]:80;
    server_name domain1.com;
    access_log /var/log/nginx/domain1.access.log;
    location / {
        proxy_pass    http://127.0.0.1:4000/;
    }
}

In / etc / nginx / sites-enabled / domain2

server {
    listen 80;
    listen [::]:80;
    server_name domain2.com;
    access_log /var/log/nginx/domain2.access.log;
    location / {
        proxy_pass    http://127.0.0.1:5000/;
    }
}

5
Sto usando il metodo di proxy_pass, ma per qualche motivo http://example.comottiene automaticamente 302'd a http://www.example.com. Perché?
Kristian,

Hai Cloudflare o qualcosa di simile? La configurazione sopra non dovrebbe reindirizzare affatto.
ozzieisaacs,

1
@Kristian Dovrai aggiungere proxy_set_header Host $hostper evitare il reindirizzamento HTTP 302.
Ivan Shatsky,

@IvanShatsky - Puoi fornire aiuto su come configurare più porte con più sottodomini e impedire che altre porte siano in esecuzione in un altro dominio? Nginx v
1.14.1

59

Puoi anche avere URL diversi per le app in una configurazione del server:

In / etc / nginx / sites-enabled / tuo dominio :

server {
    listen 80;
    listen [::]:80;
    server_name yourdomain.com;

    location ^~ /app1/{
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_set_header X-NginX-Proxy true;
        proxy_pass    http://127.0.0.1:3000/;
    }

    location ^~ /app2/{
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_set_header X-NginX-Proxy true;
        proxy_pass    http://127.0.0.1:4000/;
    }
}

Riavvia nginx:

sudo service nginx restart

Avvio di applicazioni.

nodo app1.js

var http = require('http');
http.createServer(function (req, res) {
    res.writeHead(200, {'Content-Type': 'text/plain'});
    res.end('Hello from app1!\n');
}).listen(3000, "127.0.0.1");
console.log('Server running at http://127.0.0.1:3000/');

nodo app2.js

var http = require('http');
http.createServer(function (req, res) {
    res.writeHead(200, {'Content-Type': 'text/plain'});
    res.end('Hello from app2!\n');
}).listen(4000, "127.0.0.1");
console.log('Server running at http://127.0.0.1:4000/');

3
La versione della community open source è gratuita ma hanno una versione con altre funzionalità che non sono gratuite. nginx.com/products/feature-matrix
0x8BADF00D

Scusa per la mia ignoranza. Qual è lo scopo, i vantaggi di servirlo in questo modo? hai qualche esempio o caso d'uso? Grazie in anticipo.
Mauro Aguilar,

2
@MauroAguilar Se hai bisogno di 2 app node.js su un server puoi servirle usando il modo suggerito (usando porte diverse). Nel mio caso c'erano due diverse app di test.
0x8BADF00D

Ok, ma qual è la differenza tra l'esecuzione di 2 app e una singola? Voglio dire, quali sono i vantaggi se fossero destinati allo stesso scopo?
Mauro Aguilar,

2
@MauroAguilar, puoi eseguirli in uno solo e non ci sono vantaggi se potrebbe far parte di un progetto e avere lo stesso scopo. Ma se è necessario eseguire 2 progetti diversi con scopi diversi e con configurazioni diverse su un server, allora si ha il vantaggio di usare questa configurazione.
0x8BADF00D

35

Proxyo applicazioni Node Express indipendenti tramite Nginx.

Quindi nuove applicazioni possono essere facilmente montate e posso anche eseguire altre cose sullo stesso server in posizioni diverse.

Ecco altri dettagli sulla mia configurazione con l'esempio di configurazione di Nginx:

Distribuire più applicazioni Node su un server Web in sottocartelle con Nginx

Le cose si complicano con Node quando è necessario spostare l'applicazione da localhost a Internet.

Non esiste un approccio comune per la distribuzione dei nodi.

Google può trovare tonnellate di articoli su questo argomento, ma stavo faticando a trovare la soluzione adeguata per l'installazione di cui ho bisogno.

Fondamentalmente, ho un web server e voglio che le applicazioni Node siano montate su sottocartelle (ad es. Http: // myhost / demo / pet-project / ) senza introdurre alcuna dipendenza di configurazione dal codice dell'applicazione.

Allo stesso tempo, voglio che altre cose come il blog vengano eseguite sullo stesso server Web.

Sembra semplice eh? Apparentemente no.

In molti esempi sul Web, le applicazioni Node possono essere eseguite sulla porta 80 o inviate in proxy da Nginx alla radice.

Sebbene entrambi gli approcci siano validi per determinati casi d'uso, non soddisfano i miei criteri semplici ma un po 'esotici.

Ecco perché ho creato la mia configurazione Nginx ed ecco un estratto:

upstream pet_project {
  server localhost:3000;
}

server {
  listen 80;
  listen [::]:80;
  server_name frontend;

  location /demo/pet-project {
    alias /opt/demo/pet-project/public/;
    try_files $uri $uri/ @pet-project;
  }

  location @pet-project {
    rewrite /demo/pet-project(.*) $1 break;

    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $proxy_host;
    proxy_set_header X-NginX-Proxy true;

    proxy_pass http://pet_project;
    proxy_redirect http://pet_project/ /demo/pet-project/;
  }
}

Da questo esempio puoi notare che monto la mia applicazione Nodo Progetto Pet in esecuzione sulla porta 3000 su http: // myhost / demo / pet-project .

In primo luogo Nginx verifica se la risorsa richiesta è un file statico disponibile in / opt / demo / pet-project / public / e in tal caso lo serve così come è altamente efficiente, quindi non abbiamo bisogno di avere un livello ridondante come Connect middleware statico.

Quindi tutte le altre richieste vengono sovrascritte e inoltrate all'applicazione Pet Project Node , quindi l'applicazione Node non ha bisogno di sapere dove è effettivamente montata e quindi può essere spostata ovunque puramente tramite la configurazione.

proxy_redirect è un must per gestire correttamente l'intestazione della posizione. Ciò è estremamente importante se si utilizza res.redirect () nell'applicazione Node.

È possibile replicare facilmente questa configurazione per più applicazioni Node in esecuzione su porte diverse e aggiungere più gestori di posizione per altri scopi.

Da: http://skovalyov.blogspot.dk/2012/07/deploy-multiple-node-applications-on.html


1
Perché e come dovresti farlo nei sottodomini: skovalyov.blogspot.dk/2012/10/…
skovalyov,

Link solo risposta ... puoi riassumere le parti pertinenti nella tua risposta nel caso in cui il tuo blog non sia più disponibile?
Kaiser

11

Node.js con configurazione Nginx.

$ sudo nano /etc/nginx/sites-available/subdomain.your_domain.com

aggiungere la seguente configurazione in modo che Nginx funga da reindirizzamento del proxy al traffico della porta 3000 dal server quando arriviamo da "sottodominio.tuo_dominio.com"

upstream subdomain.your_domain.com {
  server 127.0.0.1:3000;
}
server {
  listen 80;
  listen [::]:80;
  server_name subdomain.your_domain.com;
  access_log /var/log/nginx/subdomain.your_domain.access.log;
  error_log /var/log/nginx/subdomain.your_domain.error.log debug;
  location / {
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarder-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_set_header X-NginX-Proxy true;
    proxy_pass http://subdomain.your_domain.com;
    proxy_redirect off;
  }
}

9

rispondendo alla tua domanda 2:

Vorrei usare l'opzione bsemplicemente perché consuma molte meno risorse. con l'opzione 'a', ogni client farà consumare molta memoria al server, caricando tutti i file necessari (anche se mi piace php, questo è uno dei problemi con esso). Con l'opzione 'b' puoi caricare le tue librerie (codice riutilizzabile) e condividerle tra tutte le richieste del client.

Ma sappi che se hai più core dovresti modificare node.js per usarli tutti.


2
Segui questo consiglio se le risorse sono il tuo problema più importante (improbabile). Esistono diversi compromessi tra (a) e (b). L'opzione (a) è probabilmente migliore se si desidera che i siti siano più indipendenti, ad es. Riavvio o manutenzione del sito, connessioni db, base di codice, dipendenze delle librerie, spostamento di siti tra server, ecc.
robocat

8

Ho creato un repository in Github che puoi clonare, vagrant-node-nginx-boilerplate

in pratica l'app node.js /var/www/nodeappè

var http = require('http');
http.createServer(function (req, res) {
  res.writeHead(200, {'Content-Type': 'text/plain'});
  res.end('Hello World\n');
}).listen(4570, '127.0.0.1');

console.log('Node Server running at 127.0.0.1:4570/');

e la configurazione di nginx /etc/nginx/sites-available/è

server {
        listen 80 default_server;
        listen [::]:80 default_server;

        root /var/www/nodeapp;
        index index.html index.htm;

        server_name localhost;

        location / {
          proxy_pass http://127.0.0.1:4570;
          proxy_http_version 1.1;
          proxy_set_header Upgrade $http_upgrade;
          proxy_set_header Connection 'upgrade';
          proxy_set_header Host $host;
          proxy_cache_bypass $http_upgrade;
        }
}

5

È inoltre possibile utilizzare node.js per generare file statici in una directory servita da nginx. Naturalmente, alcune parti dinamiche del tuo sito potrebbero essere servite da nodo, e alcune da nginx (statico).

Avere alcuni di essi serviti da nginx aumenta le tue prestazioni.


5

Possiamo facilmente configurare un'app Nodejs da Nginx che funge da proxy inverso.
La seguente configurazione presuppone che l'applicazione NodeJS sia in esecuzione su 127.0.0.1:8080,

  server{
     server_name domain.com sub.domain.com; # multiple domains

     location /{ 
      proxy_pass http://127.0.0.1:8080;  
      proxy_set_header Host $host;
      proxy_pass_request_headers on;  
     }

     location /static/{
       alias /absolute/path/to/static/files; # nginx will handle js/css
     }
   } 

nella configurazione sopra la tua app Nodejs,

  • ottenere l' HTTP_HOSTintestazione in cui è possibile applicare la logica specifica del dominio per servire la risposta. '
  • L'applicazione deve essere gestita da un gestore di processo come pm2 o un supervisore per la gestione di situazioni / riutilizzo di socket o risorse, ecc.

  • Configurare un servizio di segnalazione errori per ottenere errori di produzione come sentinella o rollbar

NOTA: è possibile impostare la logica per la gestione di route di richieste specifiche del dominio, creare un middleware per l'applicazione expressjs


1
Un altro motivo per usare pm2 è che puoi eseguire la tua app 'per sempre' dopo essere uscito dalla shell e avviarla automaticamente se dovessi mai aver bisogno di riavviare il tuo server, vedi: pm2.keymetrics.io/docs/usage/startup
SeanQuinn781

3

Nginx può agire come un server proxy inverso che funziona proprio come un project manager. Quando riceve una richiesta, la analizza e inoltra la richiesta a monte (membri del progetto) o si gestisce da sola. Nginx ha due modi per gestire una richiesta in base alla sua configurazione.

  • servire la richiesta
  • inoltra la richiesta a un altro server

    server{
     server_name mydomain.com sub.mydomain.com;
    
     location /{ 
      proxy_pass http://127.0.0.1:8000;  
      proxy_set_header Host $host;
      proxy_pass_request_headers on;  
     }
    
     location /static/{
       alias /my/static/files/path;
     }

    }

Server la richiesta

Con questa configurazione, quando l'URL della richiesta è mydomain.com/static/myjs.jsrestituisce il myjs.jsfile nella /my/static/files/pathcartella. Quando si configura nginx per servire file statici, gestisce la richiesta stessa.

inoltra la richiesta a un altro server

Quando l'URL della richiesta è mydomain.com/dothisnginx, inoltra la richiesta a http://127.0.0.1:8000 . Il servizio in esecuzione sulla porta localhost 8000 riceverà la richiesta e restituirà la risposta a nginx e nginx restituirà la risposta al client.

Quando si esegue il server node.js sulla porta 8000 nginx inoltrerà la richiesta a node.js. Scrivi la logica node.js e gestisci la richiesta. Ecco fatto che hai il tuo server nodejs in esecuzione dietro il server nginx.

Se desideri eseguire altri servizi diversi da nodejs, esegui un altro servizio come Django, pallone, php su porte diverse e configuralo in nginx.


1

È possibile eseguire nodejs utilizzando pm2 se si desidera gestire ciascun mezzo microservizio ed eseguirlo. Il nodo sarà in esecuzione in una porta, basta configurare quella porta in nginx (/etc/nginx/sites-enabled/domain.com)

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

  location / {
     return 403;
  }
    location /url {
        proxy_pass http://localhost:51967/info;
    }
}

Controlla se localhost è in esecuzione o meno utilizzando ping.

E

Create one single Node.js server which handles all Node.js requests. This reads the requested files and evals their contents. So the files are interpreted on each request, but the server logic is much simpler.

Questo è il migliore e come hai detto anche più facile


1

La configurazione migliore e più semplice con Nginx e Nodejs è utilizzare Nginx come un bilanciamento del carico HTTP e TCP con proxy_protocol abilitato. In questo contesto, Nginx sarà in grado di delegare le richieste in arrivo a nodejs e anche di terminare le connessioni SSL ai server Nginx back-end e non al server proxy stesso. (SSL-PassThrough)

A mio avviso, non ha senso fornire esempi non SSL, dal momento che tutte le app Web utilizzano (o dovrebbero utilizzare) ambienti sicuri.

Esempio di configurazione per il server proxy, in /etc/nginx/nginx.conf

user  nginx;
worker_processes  1;
error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;
events {
    worker_connections  1024;
}
http {
  upstream webserver-http {
    server 192.168.1.4; #use a host port instead if using docker
    server 192.168.1.5; #use a host port instead if using docker
  }
  upstream nodejs-http {
    server 192.168.1.4:8080; #nodejs listening port
    server 192.168.1.5:8080; #nodejs listening port
  }
  server {
    server_name example.com;
    location / {
      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;
      proxy_set_header Host $http_host;
      proxy_set_header X-Forwarded-Host $server_name;
      proxy_set_header Connection "";
      add_header       X-Upstream $upstream_addr;
      proxy_redirect     off;
      proxy_connect_timeout  300;
      proxy_http_version 1.1;
      proxy_buffers 16 16k;
      proxy_buffer_size 16k;
      proxy_cache_background_update on;
      proxy_pass http://webserver-http$request_uri;
    }
  }
  server {
    server_name node.example.com;
    location / {
      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;
      proxy_set_header Host $http_host;
      proxy_set_header X-Forwarded-Host $server_name;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "Upgrade";
      add_header       X-Upstream $upstream_addr;
      proxy_redirect     off;
      proxy_connect_timeout  300;
      proxy_http_version 1.1;
      proxy_buffers 16 16k;
      proxy_buffer_size 16k;
      proxy_cache_background_update on;
      proxy_pass http://nodejs-http$request_uri;
    }
  }
}
stream {
  upstream webserver-https {
    server 192.168.1.4:443; #use a host port instead if using docker
    server 192.168.1.5:443; #use a host port instead if using docker
  }

  server {
    proxy_protocol on;
    tcp_nodelay on;
    listen 443;
    proxy_pass webserver-https;
  }
  log_format proxy 'Protocol: $protocol - $status $bytes_sent $bytes_received $session_time';
  access_log  /var/log/nginx/access.log proxy;
  error_log /var/log/nginx/error.log debug;
}

Ora gestiamo il server web back-end. /etc/nginx/nginx.conf :

user  nginx;
worker_processes  1;
error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;
load_module /etc/nginx/modules/ngx_http_geoip2_module.so; # GeoIP2
events {
    worker_connections  1024;
}
http {
    variables_hash_bucket_size 64;
    variables_hash_max_size 2048;
    server_tokens off;
    sendfile    on;
    tcp_nopush  on;
    tcp_nodelay on;
    autoindex off;
    keepalive_timeout  30;
    types_hash_bucket_size 256;
    client_max_body_size 100m;
    server_names_hash_bucket_size 256;
    include         mime.types;
    default_type    application/octet-stream;
    index  index.php index.html index.htm;
    # GeoIP2
    log_format  main    'Proxy Protocol Address: [$proxy_protocol_addr] '
                        '"$request" $remote_addr - $remote_user [$time_local] "$request" '
                        '$status $body_bytes_sent "$http_referer" '
                        '"$http_user_agent" "$http_x_forwarded_for"';

    # GeoIP2
    log_format  main_geo    'Original Client Address: [$realip_remote_addr]- Proxy Protocol Address: [$proxy_protocol_addr] '
                            'Proxy Protocol Server Address:$proxy_protocol_server_addr - '
                            '"$request" $remote_addr - $remote_user [$time_local] "$request" '
                            '$status $body_bytes_sent "$http_referer" '
                            '$geoip2_data_country_iso $geoip2_data_country_name';

    access_log  /var/log/nginx/access.log  main_geo; # GeoIP2
#===================== GEOIP2 =====================#
    geoip2 /usr/share/geoip/GeoLite2-Country.mmdb {
        $geoip2_metadata_country_build  metadata build_epoch;
        $geoip2_data_country_geonameid  country geoname_id;
        $geoip2_data_country_iso        country iso_code;
        $geoip2_data_country_name       country names en;
        $geoip2_data_country_is_eu      country is_in_european_union;
    }
    #geoip2 /usr/share/geoip/GeoLite2-City.mmdb {
    #   $geoip2_data_city_name city names en;
    #   $geoip2_data_city_geonameid city geoname_id;
    #   $geoip2_data_continent_code continent code;
    #   $geoip2_data_continent_geonameid continent geoname_id;
    #   $geoip2_data_continent_name continent names en;
    #   $geoip2_data_location_accuracyradius location accuracy_radius;
    #   $geoip2_data_location_latitude location latitude;
    #   $geoip2_data_location_longitude location longitude;
    #   $geoip2_data_location_metrocode location metro_code;
    #   $geoip2_data_location_timezone location time_zone;
    #   $geoip2_data_postal_code postal code;
    #   $geoip2_data_rcountry_geonameid registered_country geoname_id;
    #   $geoip2_data_rcountry_iso registered_country iso_code;
    #   $geoip2_data_rcountry_name registered_country names en;
    #   $geoip2_data_rcountry_is_eu registered_country is_in_european_union;
    #   $geoip2_data_region_geonameid subdivisions 0 geoname_id;
    #   $geoip2_data_region_iso subdivisions 0 iso_code;
    #   $geoip2_data_region_name subdivisions 0 names en;
   #}

#=================Basic Compression=================#
    gzip on;
    gzip_disable "msie6";
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 6;
    gzip_buffers 16 8k;
    gzip_http_version 1.1;
    gzip_types text/css text/xml text/plain application/javascript image/jpeg image/png image/gif image/x-icon image/svg+xml image/webp application/font-woff application/json application/vnd.ms-fontobject application/vnd.ms-powerpoint;
    gzip_static on;

    include /etc/nginx/sites-enabled/example.com-https.conf;
}

Ora configuriamo l'host virtuale con questo SSL e proxy_protocol abilitato config in /etc/nginx/sites-available/example.com-https.conf :

server {
    real_ip_header proxy_protocol;
    set_real_ip_from 192.168.1.1; #proxy server ip address
    #set_real_ip_from proxy; #proxy container hostname if you are using docker
    server_name 192.168.1.4; #Your current server ip address. It will redirect to the domain name.
    listen 80;
    listen 443 ssl http2;
    listen [::]:80;
    listen [::]:443 ssl http2;
    ssl_certificate     /etc/nginx/certs/example.com.crt;
    ssl_certificate_key /etc/nginx/certs/example.com.key;
    ssl_dhparam /etc/nginx/ssl/dhparam.pem;
    return 301 https://example.com$request_uri;
}
server {
    real_ip_header proxy_protocol;
    set_real_ip_from 192.168.1.1; #proxy server ip address
    #set_real_ip_from proxy; #proxy container hostname if you are using docker
    server_name  example.com;
    listen       *:80;
    return 301   https://example.com$request_uri;
}
server {
    real_ip_header proxy_protocol;
    set_real_ip_from 192.168.1.1; #proxy server ip address
    #set_real_ip_from proxy; #proxy container hostname if you are using docker
    server_name www.example.com;
    listen 80;
    listen 443 http2;
    listen [::]:80;
    listen [::]:443 ssl http2 ;
    ssl_certificate     /etc/nginx/certs/example.com.crt;
    ssl_certificate_key /etc/nginx/certs/example.com.key;
    ssl_dhparam /etc/nginx/ssl/dhparam.pem;
    return 301 https://example.com$request_uri;
}
server {
    real_ip_header proxy_protocol;
    set_real_ip_from 192.168.1.1; #proxy server ip address
    #set_real_ip_from proxy; #proxy container hostname if you are using docker
    server_name example.com;
    listen 443 proxy_protocol ssl http2;
    listen [::]:443 proxy_protocol ssl http2;
    root /var/www/html;
    charset UTF-8;
    add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload';
    add_header X-Frame-Options SAMEORIGIN;
    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";
    add_header Referrer-Policy no-referrer;
    ssl_prefer_server_ciphers on;
    ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
    ssl_protocols TLSv1.2 TLSv1.1 TLSv1;
    ssl_session_cache   shared:SSL:10m;
    ssl_session_timeout 10m;
    keepalive_timeout   70;
    ssl_buffer_size 1400;
    ssl_dhparam /etc/nginx/ssl/dhparam.pem;
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8 8.8.4.4 valid=86400;
    resolver_timeout 10;
    ssl_certificate     /etc/nginx/certs/example.com.crt;
    ssl_certificate_key /etc/nginx/certs/example.com.key;
    ssl_trusted_certificate /etc/nginx/certs/example.com.crt;
location ~* \.(jpg|jpe?g|gif|png|ico|cur|gz|svgz|mp4|ogg|ogv|webm|htc|css|js|otf|eot|svg|ttf|woff|woff2)(\?ver=[0-9.]+)?$ {
    expires modified 1M;
    add_header Access-Control-Allow-Origin '*';
    add_header Pragma public;
    add_header Cache-Control "public, must-revalidate, proxy-revalidate";
    access_log off;
    }
    location ~ /.well-known { #For issuing LetsEncrypt Certificates
        allow all;
    }
location / {
    index index.php;
    try_files $uri $uri/ /index.php?$args;
    }
error_page  404    /404.php;

location ~ \.php$ {
    try_files       $uri =404;
    fastcgi_index   index.php;
    fastcgi_pass    unix:/tmp/php7-fpm.sock;
    #fastcgi_pass    php-container-hostname:9000; (if using docker)
    fastcgi_pass_request_headers on;
    fastcgi_split_path_info ^(.+\.php)(/.+)$;
    fastcgi_param   SCRIPT_FILENAME  $document_root$fastcgi_script_name;
    fastcgi_intercept_errors on;
    fastcgi_ignore_client_abort off;
    fastcgi_connect_timeout 60;
    fastcgi_send_timeout 180;
    fastcgi_read_timeout 180;
    fastcgi_request_buffering on;
    fastcgi_buffer_size 128k;
    fastcgi_buffers 4 256k;
    fastcgi_busy_buffers_size 256k;
    fastcgi_temp_file_write_size 256k;
    include fastcgi_params;
}
location = /robots.txt {
    access_log off;
    log_not_found off;
    }
location ~ /\. {
    deny  all;
    access_log off;
    log_not_found off;
    }
}

E, infine, un esempio di 2 server web nodejs : Primo server:

var http = require('http');

http.createServer(function (req, res) {
    res.writeHead(200, {'Content-Type': 'text/plain'});
    res.end('Hello From Nodejs\n');
}).listen(8080, "192.168.1.4");
console.log('Server running at http://192.168.1.4:8080/');

Secondo server:

var http = require('http');

http.createServer(function (req, res) {
    res.writeHead(200, {'Content-Type': 'text/plain'});
    res.end('Hello From Nodejs\n');
}).listen(8080, "192.168.1.5");
console.log('Server running at http://192.168.1.5:8080/');

Ora tutto dovrebbe funzionare perfettamente e bilanciare il carico.

Qualche tempo fa ho scritto su Come impostare Nginx come bilanciamento del carico TCP in Docker . Dai un'occhiata se stai usando Docker.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.