Práticas recomendadas do NGinx

Quais práticas recomendadas você usa ao usar o NGinx?

Como combinar blocos HTTP e HTTPS.

server {
    listen 80;
    listen 443 default ssl;

    # other directives
}

Isso foi postado como resposta a uma pergunta diferente. Veja aqui .

De longe, as melhores dicas que eu já vi são do autor em sua página de armadilhas: https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/

Geralmente, usar "se" é uma má prática (de acordo com o autor do nginx). se possível, é melhor usar o try_file das diretivas error_page em vez de "if (-f ...)"

Combinando dica com o arquivo maintenence.html e dica com try_files, obtemos:

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

Quando a manutenção terminar, apenas mv maintenance.html de $ root.

Configure o nginx para usar cifras SSL mais fortes. Por padrão, o SSLv2 está ativado (que você deve desativar, se possível).

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

Geralmente é mais eficiente usar a mapdiretiva no lugar de expressões regulares ao alternar a raiz para subdomínios correspondentes:

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;

}

O empty_gifmódulo também é muito útil, especialmente se você precisar monitorar as respostas do servidor da web (usando nagios / monit / etc):

location /token {
    empty_gif;
}

location /favicon.ico {
    empty_gif;
}

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

Nós configuramos o Nginx com o Chef, usando este livro de receitas que contém scripts para lidar com a configuração do nginx semelhante à maneira como o Debian faz o Apache2, e também alguns modelos de amostra com padrões saudáveis.

Aqui está um bom método para retornar uma página de manutenção. Todas as solicitações são reescritas e o código http correto é retornado. (503 serviço indisponível)

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

A partir do nginx 0.7.12 e posterior, um "" é utilizável em server_name para capturar solicitações sem um cabeçalho "Host".

Você pode usar o seguinte como uma catchall para hosts virtuais indefinidos.

server {
  server_name _ "";
}

Também publiquei há um tempo atrás sobre como lidar adequadamente com a compressão gzip com o nginx, pois navegadores mais antigos podem ter problemas com apenas uma declaração geral do gzip. HTH.

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

Não sei se é uma prática recomendada, mas definitivamente um truque interessante para obter condições aninhadas no nginx. Aqui está um exemplo do wiki 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 você precisar alternar contextualmente entre http e https para subdomínios manipulados pelo mesmo bloco de servidor, poderá usar variáveis ​​para fazer isso. Pode não ser a maneira mais eficiente de fazer as coisas, mas funciona:

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

}

Eu sempre tento usar a rootdiretiva na parte superior do bloco do servidor para tirar proveito da $document_rootvariável e nunca, mas nunca, incluir a rootdiretiva dentro de um bloco de localização.

A página Pitfalls do wiki Nginx tem ótimas dicas sobre práticas recomendadas.

Se você estiver usando o nginx como proxy, ajustar as configurações de tempo limite pode ser importante para garantir que você não tenha conexões de queda do nginx antes que seu aplicativo seja concluído, especialmente se você estiver lidando com um aplicativo de alto tráfego:

proxy_connect_timeout
proxy_send_timeout

Você deu uma olhada aqui?

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