Best practice di NGinx

Quali best practice usi durante l'utilizzo di NGinx?

Come combinare blocchi HTTP e HTTPS.

server {
    listen 80;
    listen 443 default ssl;

    # other directives
}

Questo è stato pubblicato come risposta a una domanda diversa. Vedi qui .

Di gran lunga, i migliori consigli che io abbia mai visto provengono dall'autore nella sua pagina di trabocchetto: https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/

Generalmente, usare "if" è una cattiva pratica (secondo l'autore di nginx). se possibile, meglio usare try_file delle direttive error_page invece di "if (-f ...)"

Combinando tip con file maintenence.html e tip con try_files otteniamo:

Posizione / {
    try_files /maintenance.html $ uri $ uri / @wordpress;
}

Al termine della manutenzione, basta mv maintenance.html da $ root.

Configura nginx per usare cifrature SSL più forti. Per impostazione predefinita, SSLv2 è abilitato (che è necessario disabilitare se possibile).

ssl_ciphers DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:EDH-RSA-DES-CBC3-SHA:AES256-SHA:DES-CBC3-SHA:AES128-SHA:RC4-SHA:RC4-MD5;

http://tumblelog.jauderho.com/post/121851623/nginx-and-stronger-ssl

Spesso è più efficiente utilizzare la mapdirettiva al posto delle espressioni regolari quando si cambia root per abbinare i sottodomini:

server {

    server_name mysite.tld ~^.+\.mysite\.tld$;

    map $host $files {
        default            common;
        mysite.tld         common;
        www.mysite.tld     common;
        admin.mysite.tld   admin;
        system.mysite.tld  system;
        *.mysite.tld       users;
    }

    root /var/www/mysite/$files;

}

Il empty_gifmodulo è anche molto utile, specialmente se hai bisogno di monitorare le risposte dal server web (usando nagios / monit / etc):

location /token {
    empty_gif;
}

location /favicon.ico {
    empty_gif;
}

location /img/1px.gif {
    empty_gif;
} 

Abbiamo impostato Nginx con Chef, usando questo ricettario che contiene script per gestire la configurazione di nginx in modo simile a come Debian fa Apache2, e anche alcuni modelli di esempio con impostazioni predefinite corrette.

Ecco un buon metodo per restituire una pagina di manutenzione. Tutte le richieste vengono riscritte e viene restituito il codice http corretto. (503 servizio non disponibile)

error_page 503 /maintenance.html;

location /
{
    if (-f $document_root/maintenance.html)
    {
        return 503;
    }

    try_files $uri /index.php?$args;
}

location = /maintenance.html
{
    rewrite ^ /maintenance.html break;
}

Da nginx 0.7.12 e versioni successive, un "" è utilizzabile in nome_server per catturare richieste senza un'intestazione "Host".

È possibile utilizzare quanto segue come catchall per host virtuali non definiti.

server {
  server_name _ "";
}

Ho anche pubblicato qualche tempo fa su come gestire correttamente la compressione gzip con nginx poiché i browser più vecchi potrebbero avere problemi con una semplice dichiarazione gzip. HTH.

http://tumblelog.jauderho.com/post/27655495/gzip-compression-with-nginx

Non so se sia una buona pratica, ma sicuramente un trucco accurato per ottenere condizioni nidificate in nginx. Ecco un esempio dal wiki di nginx .

location /xxxx/ {
  set $test "";

  if ($request_method = POST) {
    set $test  P;
  }

  if ($http_cookie ~* "CCCC=.+(?:;|$)" ) {
    set $test  "${test}C";
  }

  if ($test = PC) {
    #rewrite rule goes here.
  } 
}

Se è necessario passare contestualmente tra http e https per i sottodomini gestiti dallo stesso blocco server, è possibile utilizzare le variabili per farlo. Potrebbe non essere il modo più efficiente di fare le cose, ma funziona:

server {
  server mysite.tld ~^.+\.mysite\.tld$;

  set $req_ssl = 0;

  map $host $files {
      default            common;
      mysite.tld         common;
      www.mysite.tld     common;
      admin.mysite.tld   admin;
      system.mysite.tld  system;
      *.mysite.tld       users;
  }

  root /var/www/mysite/$files;

  if ( $files = "admin" ){
    set $req_ssl 1;
  }

  if ( $files = "common" ){
    set $req_ssl 2;
  }

  if ( $scheme = http )
  {
    set $req_ssl $req_ssl.1;
  }

  if ( $scheme = https )
  {
    set $req_ssl $req_ssl.2;
  }

  if ($req_ssl = 1.1){
    rewrite ^ https://$host$uri;
  }

  if ($req_ssl = 2.2){
    rewrite ^ http://$host$uri;
  }

}

Cerco sempre di utilizzare la rootdirettiva nella parte superiore del blocco server in modo da poter sfruttare la $document_rootvariabile e mai, ma mai, includere la rootdirettiva all'interno di un blocco di posizione.

La pagina delle insidie del wiki di Nginx contiene alcuni ottimi consigli sulle migliori pratiche.

Se si utilizza nginx come proxy, la modifica delle impostazioni di timeout può essere importante per assicurarsi che non si disponga di connessioni drop nginx prima che l'applicazione venga eseguita con esse, soprattutto se si ha a che fare con un'applicazione ad alto traffico:

proxy_connect_timeout
proxy_send_timeout

Hai dato un'occhiata qui?

http://www.directadmin.com/forum/showthread.php?p=137288