Доброго времени суток читатели и гости моего блога. В этой статье мы продолжим настраивать Nginx и напишем конфигурацию для будущего сайта на основе Word­Press. С предыдущей статьей можно ознакомиться здесь.

Во время установки Nginx был создан набор каталогов для размещения конфигурационных файлов. Сейчас нас интересуют следующие каталоги: /etc/nginx/sites-enabled и /etc/nginx/sites-avail­able.

В каталоге /etc/ng­inx/sites-avail­able создадим файл test, в котором будет задана конфигурация будущего сайта.

Те, кто внимательно читал предыдущую статью, могут заметить что файл test создан в каталоге sites-avail­able, а в nginx.conf был подключен каталог sites-enabled. Следовательно создадим символическую ссылку на файл test в каталоге /etc/ng­inx/sites-enabled, таким образом мы включим файл в конфигурацию сервера.

Откроем файл test в редакторе и начнем писать конфигурацию сайта.

Пропишем первый блок serv­er {}, в который добавим запрет на обращение к серверу по ip-адресу.

Теперь все попытки вызова сервера по ip-адресу на 80-м порту будут пресекаться, сервер будет возвращать таким клиентам ошибку 444 и разрывать с ними соединение.

Во втором блоке serv­er {} пропишем редирект с www на основной домен. Если у вас есть доменное имя вида test.com, то будьте уверены что всегда найдется какой-нибудь умник, который добавит к нему в начало www. Если не добавить редирект в конфигурацию сайта, то такие люди не смогут попасть на него.

При обращении к серверу по имени вида www.test.com, клиенту будет возвращен 301-ый ответ с указанием перейти по адресу test.com.

Здесь можно использовать два варианта ответов - 301 и 302, но они имеют существенное различие. Ответ 301 (Moved Per­ma­nent­ly - Перемещено навсегда) кэшируется браузером клиента и в следующий раз браузер пойдет по адресу из кэша и так будет происходить все время, пока кэш не будет очищен. Ответ 302 (Moved Tem­porar­i­ly - Перемещено временно) не кэшируется браузером клиента и в следующий раз запрос к серверу будет послан заново.

Добавим третий блок serv­er {}, в котором будет находиться все оставшееся.

Начнем с указания порта, который будет слушать сервер. По умолчанию это 80-й порт.

Укажем доменное имя сайта, для примера я использую test.com.

Добавим корневую директорию сайта и тип индексного файла.

Укажем местонахождение лог-файлов доступа (access) и ошибок (error).

Основная часть почти готова, уже в таком виде сервер может обслуживать простенькие сайты на html, только тогда index.php нужно будет заменить на index.html.

Но поскольку сайт будет работать на Word­Press, то необходимо добавить набор некоторых опций и правил, согласно Word­Press-документации для Nginx.

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

Создадим два дополнительных файла в каталоге /etc/nginx/conf.

Подключим созданные файлы внутри третьего блока serv­er {}, сразу после лог-файлов. Подобное подключение выполняется там где оно прописано и равносильно записи внутри самого блока. Файлы должны включаться в такой последовательности.

Готовый файл test выглядит так.

restrictions.conf

Добавляем содержимое в restrictions.conf.

Немного облегчим работу сервера снизив на него нагрузку. Не будем отмечать в логах доступа запросы к файлам favicon.ico и robots.txt. Также не станем фиксировать 404-ю ошибку в случае их отсутствия.

Немного обезопасим работу сервера путем запрета доступа к скрытым файлам и запрета выполнения php-файлов в директории uploads.

Готовый файл restrictions.conf выглядит так.

wordpress.conf

Добавляем содержимое в wordpress.conf.

Первым делом установим правило обработки входящих запросов и дальнейшей их передачи на обработку PHP. Работает оно примерно так. Все запросы поступающие к серверу должны передаваться на обработку PHP/Wordpress, но если запрос обращен к конкретному файлу существующему на сервере, то такой файл следует отдать самостоятельно, не прибегая к помощи PHP.

Правило задается директивой try_files, сначала проверяется существование нужного файла $uri, потом на его наличие проверяются директории $uri/, а если запрос не является запросом конкретного файла, то он передается на index.php, для обработки силами Word­Press. Правило задается внутри контекста "location/".

Следующее выражение добавляет конечный слэш "/" к запросам содержащим "/wp-admin".

Настроим передачу запросов к FastC­GI-серверу.

Теперь запросу "index.php" будет соответствовать не только префиксный loca­tion "/", а еще и регулярное выражение "\.php$". Следовательно запрос будет обработан в контексте регулярного выражения и передан FastC­GI-серверу через UNIX-сокет - /var/run/php-fpm.sock. Сокет задается в значении директивы fastcgi_pass.

В fastcgi_param SCRIPT_FILENAME задается значение двух переменных: $document_root и $fastcgi_script_name. Переменная $document_root задает директорию /var/www/test/public, переменная $fastcgi_script_name задает значение "/index.php". Теперь FastC­GI-сервер знает местонахождение файла для выполнения.

Готовый файл wordpress.conf выглядит так.

Написанную конфигурацию можно проверить. Ответ должен быть таким как у меня.
Если все в порядке, то можно перезапустить сервер и переходить к установке Word­Press.
Описание установки Word­Press в следующей статье. До встречи.