NGinx Best Practices

46

Какие лучшие практики вы используете при использовании NGinx?

The Pixel Developer
источник
Просто обратите внимание, что это не работает для установки Magento. Все еще исследую причины, но я думаю, что это как-то связано со строкой запроса.
Jauder Ho
location / wordpress должен быть полезен, если у вас есть wordpress в подкаталоге с именем "wordpress". Как насчет того, когда у нас есть WordPress в веб-корне "/"?
rahul286

Ответы:

21

Как объединить блоки HTTP и HTTPS.

server {
    listen 80;
    listen 443 default ssl;

    # other directives
}

Это было опубликовано как ответ на другой вопрос. Смотрите здесь .

Джодер Хо
источник
15

Как правило, использование «если» является плохой практикой (по мнению автора nginx). если возможно, лучше использовать try_file директив error_page вместо "if (-f ...)"

Объединяя tip с файлом maintenence.html и tip с try_files, мы получаем:

место нахождения / {
    try_files /maintenance.html $ uri $ uri / @wordpress;
}

Когда обслуживание закончится, просто запустите mv maintenance.html из $ root.

Слава К
источник
16
Это не идеально, так как /maintenance.html будет использоваться как ответ 200. Возможно, вы хотите, чтобы поисковые системы распознали, что страница обслуживания не является вашим реальным веб-сайтом. Возможно, вы захотите вернуть 503 (служба временно недоступна). Единственный способ выяснить, как это сделать, это с помощью if (-f ...) { return 503; }и error_page 503 /maintenance.html. Как вы думаете?
Аарон Гибралтер
11

Настройте nginx для использования более надежных шифров SSL. По умолчанию SSLv2 включен (который вы должны отключить, если это возможно).

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

Джодер Хо
источник
8

Часто более эффективно использовать mapдирективу вместо регулярных выражений при переключении корня для соответствующих поддоменов:

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;

}
Филипп Б. Олдем
источник
5
вы знаете, что можете сделать имя_сервера mysite.tld * .mysite.tld
Неизвестно
8

empty_gifМодуль также очень полезно, особенно если вам нужно ответов монитор с веб - сервера ( с помощью Nagios / монит / и т.д.):

location /token {
    empty_gif;
}

location /favicon.ico {
    empty_gif;
}

location /img/1px.gif {
    empty_gif;
} 
Филипп Б. Олдем
источник
1
Можете ли вы привести пример из реальной жизни для этого? Я до сих пор не до конца понимаю, как это полезно.
Pixel Developer
1
@ The Pixel Developer, он действительно полезен только для скорости. Nginx хранит данные для пустого GIF в памяти, поэтому он никогда не загружается с диска.
Неизвестно
5
также access_log off;для этих мест является обычной практикой
SaveTheRbtz
6

Мы настроили Nginx с помощью Chef, используя эту кулинарную книгу, которая содержит сценарии для обработки конфигурации nginx, аналогичные тому, как Debian выполняет Apache2, а также некоторые примеры шаблонов со стандартными значениями по умолчанию.

jtimberman
источник
5

Вот хороший способ вернуть страницу обслуживания. Все запросы переписываются и возвращается правильный http-код. (сервис 503 недоступен)

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;
}
The Pixel Developer
источник
1
На самом деле, я не согласен - я добавил комментарий на serverfault.com/questions/18994/nginx-best-practices/… . По сути, вы хотите вернуть ошибку 503, иначе боты и индексаторы будут думать, что ваша страница обслуживания является частью вашего реального сайта ... Нет ничего плохого в ifутверждении, если вы его правильно используете - в документах говорится, что ifs безопасны, если вы просто делаешь return xxx;.
Аарон Гибралтер
Кроме того, это location = /maintenance.html { break; }необходимо?
Аарон Гибралтер
4

Начиная с nginx 0.7.12 и более поздних, в server_name можно использовать «» для перехвата запросов без заголовка «Host».

Вы можете использовать следующее как ловушку для неопределенных виртуальных хостов.

server {
  server_name _ "";
}
неизвестный
источник
Ваш пример работает только для запросов с неопределенным vhost или он также будет работать с запросами с неизвестным (неправильным) vhost?
Бенуа
@ Бенуа это работает для всего, что не определено.
неизвестно
Является ли "имя_сервера _ *" не поддерживается nginx 0.7 года?
rahul286
1
Обратите внимание, что это только частично верно. "" будет перехватывать заголовок MISSING Host, но не будет перехватывать запрос с заголовком Host, который ничего не соответствует. Если вам нужен универсальный блок сервера, посмотрите флаг default_server в директиве listen.
Мартин Фьордвальд,
3

Некоторое время назад я также писал о том, как правильно обрабатывать сжатие gzip с помощью nginx, так как в старых браузерах могут возникнуть проблемы только с общим выражением gzip. НТН.

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

Джодер Хо
источник
3

Я не знаю, является ли это наилучшей практикой, но, безусловно, это хороший способ получить вложенные условия в nginx. Вот пример из вики 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.
  } 
}
сажал
источник
3
Я бы отнес это к категории «некрасивой, но иногда необходимой практики» - конечно, не то, чтобы ее поощряли.
womble
2

Если вам нужно контекстно переключаться между http и https для поддоменов, обрабатываемых одним и тем же блоком сервера, вы можете использовать переменные для этого. Возможно, это не самый эффективный способ, но он работает:

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

}
Филипп Б. Олдем
источник
2

Я всегда стараюсь использовать rootдирективу в верхней части блока сервера, чтобы иметь возможность использовать $document_rootпеременную и никогда, но никогда, не включать rootдирективу в блок локации.

Ловушки Страница из Nginx вики имеет некоторые отличные советы о лучших практиках.

pablox
источник
1

Если вы используете nginx в качестве прокси-сервера, то изменение настроек тайм-аута может быть важно, чтобы убедиться, что у вас нет сбрасывающих соединений nginx до того, как ваше приложение будет с ними работать, особенно если вы работаете с приложением с высоким трафиком:

proxy_connect_timeout
proxy_send_timeout
wjimenez5271
источник