Какие передовые практики вы используете при использовании NGinx?
Безусловно, лучшие советы, которые я когда-либо видел от автора на странице с ошибками: https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/
Как объединить блоки HTTP и HTTPS.
server {
listen 80;
listen 443 default ssl;
# other directives
}
Это было отправлено как ответ на другой вопрос. Посмотреть здесь.
Как правило, использование «if» - плохая практика (по словам автора nginx). по возможности лучше использовать try_file директив error_page вместо "if (-f ...)"
Комбинируя подсказку с файлом maintenence.html и подсказку с файлом try_files, мы получаем:
location / {
try_files /maintenance.html $uri $uri/ @wordpress;
}
По окончании обслуживания просто введите mv maintenance.html из $ root.
Настройте 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
Часто более эффективно использовать 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;
}
В empty_gif модуль также очень полезно, особенно если вам нужно отслеживать ответы с веб-сервера (используя nagios / monit / etc):
location /token {
empty_gif;
}
location /favicon.ico {
empty_gif;
}
location /img/1px.gif {
empty_gif;
}
Мы настраиваем Nginx с Chef, используя эта поваренная книга который содержит сценарии для обработки конфигурации nginx, аналогичные тому, как Debian делает Apache2, а также некоторые образцы шаблонов с разумными значениями по умолчанию.
Вот хороший способ вернуть страницу обслуживания. Все запросы переписываются, и возвращается правильный 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;
}
Начиная с nginx 0.7.12 и новее, в server_name можно использовать "" для перехвата запросов без заголовка "Host".
Вы можете использовать следующее в качестве общего для неопределенных виртуальных хостов.
server {
server_name _ "";
}
Некоторое время назад я также писал о том, как правильно обрабатывать сжатие gzip с помощью nginx, поскольку в старых браузерах могут возникать проблемы с использованием простого оператора gzip. HTH.
http://tumblelog.jauderho.com/post/27655495/gzip-compression-with-nginx
Я не знаю, является ли это лучшей практикой, но определенно отличный способ получить вложенные условия в 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.
}
}
Если вам нужно переключаться контекстно между 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;
}
}
Я всегда стараюсь использовать root директиву в верхней части серверного блока, чтобы я мог воспользоваться $document_root переменная и никогда, но никогда не включайте root директива внутри блока местоположения.
В Страница ловушек из вики Nginx есть несколько отличных советов о лучших практиках.
Если вы используете nginx в качестве прокси, настройка параметров тайм-аута может быть важна, чтобы гарантировать, что у вас не будет сбоев соединений nginx до того, как ваше приложение будет с ними работать, особенно если вы имеете дело с приложением с высоким трафиком:
proxy_connect_timeout
proxy_send_timeout
Вы сюда смотрели?