Menu

Рекомендации по настройке Nginx

Nginx представляет собой постоянно развивающийся веб-сервер, стремительно набирающий популярность. В июле 2013 года nginx стал самым используемым веб-сервером среди 1000 самых популярных сайтов. К сожалению, в документации nginx описан интерфейс приложения и не расписано, как работает сам nginx. В этой статье рассмотрим наиболее важные аспекты настройки nginx в логическом порядке.

Основы настройки Nginx

Nginx является простым сервером HTTP, однако, большинство людей раньше использовали Apache привыкли к LAMP, поэтому существует несколько вещей в настройке nginx, которых нужно остерегаться при использовании данного веб-сервера. Важными факторами является, во-первых, то, что nginx является инвертированным прокси-сервером и во-вторых HTTP сервером, в первую очередь это касается не файлов, а URL, что изменяет способ, которым будет настраиваться nginx.

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

Существует 3 иерархии, которые обычно называют блоками: блок HTTP, блок server и блок location, в этих блоках иерархия построены следующим образом: http ->server -> location.

Более того, существует 2 специальных блока location: блок event и root, в котором находятся блоки location и http. Оба они содержат небольшое количество директив. Большинство времени уйдёт на остальные 3 блока.

Блоки имеют смысловое значение. Блок server в Apache рассматривается, как виртуальный хост. Блок location относится к URI.

При использовании документации ключевые слова определяют, в каком блоке может использоваться директива, как говорилось ранее, директиву лучше использовать в самом верхнем блоке.

Виртуальные хосты

Наиболее важные директивы server_name и root. Это заставляет nginx использовать блок server конфигурационного файла, когда заголовок HOST совпадает с именем сервера, и сообщает, какую директорию на локальной машине использовать при поиске файлов сайта..

Эти формы основные для виртуальных хостов, пример:

 

server {
listen 80;
server_name drach.pro *.drach.pro;
return 301 $scheme://www.drach.pro$request_uri;
}
server {
listen 80;
server_name www.drach.pro;
index index.html;
root /home/drach.pro;
}

Здесь имеется два виртуальных хоста. Первый, когда drach.pro или любой под домен drach.pro, кроме www передаётся, как заголовок HOST в браузере. Дело в том, что nginx всегда будет выбирать наиболее точное соответствие и при посещении www.drach.pro это точно будет относиться ко второму блоку.

Это также означает, что можно создать виртуальных хост, который будет ловить все домены, без необходимого совпадения. Thankfully this is as simple as adding the default_server flag to the listen directive. This causes all request without a HOST header or without another vhost matching the HOST header to be sent to this vhost instead. Examples are requests accessing the IP directly or if someone points a random domain at your IP. Использование директивы server_name позволяет избежать подмены (использования фальшивых адресов) на уровне заголовка. Если Вас этот вопрос не волнует, конечно, можно не использовать эту директиву.

 

server {
listen 80 default_server;
index index.html;
root /var/www/default;
}

Блок Location

Nginx как правило, не использует сложные перезаписи, обычно тоже самое можно сделать используя блок location.

Важным фактором является то, что location, за исключением location с именем, работают с URI без каких-либо параметров запроса и только блок location не будет запущен, поэтому директивы должны находится в верхнем блоке. Директива root, определяется в location/ недоступна в location/изображения/ – до тех пор, пока не будет определена в блоке server. Определение самого верхнего блока предотвратит дублирование кода.

Другим важным фактором является директива server_name, nginx будет использовать наиболее определённый блок location. Более подробную информацию можно найти в официальной документации nginx

Рассмотрим несколько примеров, как использовать блок location. В этом примере существует форум по адресу URI /forum/, который недавно переехал на под домен. Теперь требуется перенаправить старые URL на новые. Для этого будем использовать регулярное выражение location c именованной переменной.

 

server {
listen 80 default;
server_name www.drach.pro;

root /home/drach.pro;

# This will match any URI beginning with /forum
location ~ ^/forum/(?P.*)$ {
return 301 $scheme://forum.drach.pro/$1;
}
}

server {
listen 80;
server_name forum.drach.pro;

index index.php;
root /home/drach.pro/forum;
}

Запросы на /forum теперь успешно передаются на новый под домен, в то время, как запросы к файлам, не находящимся в /forum подаются по стандартному /home/drach.pro.

Обработка PHP

В PHP или любом сервере, связанном с location можно определить блок location, для получения всех файлов PHP.

 

server {
listen 80;
server_name forum.drach.pro;

index index.php;
root /home/drach.pro/forum;

location ~* \.php$ {
include fastcgi.conf # I include this in http context, it's
just here to show it's required for fastcgi!
try_files $uri =404; # Это не требуется, если у Вас уже
cgi.fix_pathinfo = 0 в файле php.ini (что подразумевается)
fastcgi_pass 127.0.0.1:9000;
}
}

Как упоминалось ранее, nginx связан не с файлами, а с location, именно поэтому существует директива try_files внутри блока php. Этот блок location соответствует URI, который заканчивается на. php, но при этом не важно файл это или нет. Поэтому запрос /forum/avatars/user2.jpg/index.php будет соответствовать и будет отправлен в PHP, а если and PHP не настроен должным образом, то PHP выполняет /forum/avatars/user2.jpg когда /forum/avatars/user2.jpg/index.php не существует. В связи с этим возникает угроза безопасности. Обратите внимание, что это не ошибка nginx, а запланированное поведение, которые не может быть “исправлено”.

Однако ошибку можно исправить в PHP, задав cgi.fix_pathinfo=0 в файле php.ini.

В результате существующие файлы с расширением.php будут переданы через fastcgi на процессы PHP, запущенные на порте 9000.

Поисковая оптимизация

Когда выполнены установка и настройка, и уже всё работает, каждый из нас спрашивает себя, а будут ли поддерживаться ЧПУ (понятные человеку адреса) на моём сайте? Ведь в настоящее время использование ЧПУ существенно отражается на отношении поисковых систем к любым сайтам в интернете. Обычно, на сервере Apache используются перенаправления, прописанные в файле. htaccess, однако на сервере nginx нужно доработать файл конфигурации, причём зачастую получаем изящное решение в одну строку:

server {
listen 80;
server_name forum.drach.pro;

index index.php;
root /home/drach.pro/forum;

location / {
try_files $uri $uri/ /index.php;
}

location ~* \.php$ {
include fastcgi.conf; # Это требуется для fastcgi!
try_files $uri =404; # уже комментировали в примере выше!
fastcgi_pass 127.0.0.1:9000;
}
}

Изменения минимальны; строка try files означает, что сначала произойдёт попытка получить доступ к полному URI, это значит, что статический запрос файла здесь закончится. Во-вторых, будет произведена попытка перейти по полному адресу URL + слеш, таким образом производя поиск в директории. Наконец, если ни один из запросов не найден, будет отправлен запрос в /index.php и будет выполнено новое согласование location, которое, естественно, обратится к location PHP и произойдёт запрос fastcgi_pass. PHP будет иметь полный URI в $_SERVER[‘REQUEST_URI’]. Элегантно и просто для понимания.

Запросы отладки

Nginx время от времени является сложным сервером, но благодаря журналу ошибок всегда можно понять, что пошло не так. Директива журнала ошибок в документации принимает второй аргумент. Это позволяет определить количество выходной информации nginx. Значение ошибок позволит Вам отладить большинство проблем.

Авторизуйтесь, чтобы получить возможность оставлять комментарии
Go to top