В этой статье мы продолжим настраивать Nginx и напишем конфигурацию для сайта на основе WordPress. С предыдущей статьей можно ознакомиться здесь.
Во время установки Nginx был создан набор каталогов для конфигурационных файлов. Сейчас нас интересуют следующие каталоги: /etc/nginx/sites-enabled и /etc/nginx/sites-available.
В каталоге /etc/nginx/sites-available создадим файл test, в котором будет конфигурация будущего сайта.
touch /etc/nginx/sites-available/test
Создадим символическую ссылку на файл test в каталоге /etc/nginx/sites-enabled, таким образом мы включим файл в конфигурацию сервера.
ln -s /etc/nginx/sites-available/test /etc/nginx/sites-enabled/test
Откроем файл test в редакторе и начнем писать конфигурацию сайта.
nano /etc/nginx/sites-available/test
Пропишем первый блок server {}, в который добавим запрет на обращение к серверу по ip-адресу.
# Запрет на обращение к серверу по ip-адресу
server {
listen 80 default_server;
server_name _;
return 444;
}
Теперь все попытки вызова сервера по ip-адресу на 80-м порту будут пресекаться, сервер будет возвращать таким клиентам ошибку 444 и разрывать с ними соединение.
Во втором блоке server {} пропишем редирект с www на основной домен. Если у вас есть доменное имя вида test.com, то будьте уверены что всегда найдется какой-нибудь умник, который добавит к нему в начало www. Если не добавить редирект в конфигурацию сайта, то такие люди не смогут попасть на него.
# Редирект с www на основное доменное имя
server {
listen 80;
server_name www.test.com;
return 301 $scheme://test.com$request_uri;
}
При обращении к серверу по имени вида www.test.com, клиенту будет возвращен 301-ый ответ с указанием перейти по адресу test.com.
return 301 $scheme://test.com$request_uri;
Здесь можно использовать два варианта ответов - 301 и 302, они имеют существенное различие.
Ответ 301 (Moved Permanently - Перемещено навсегда) кэшируется браузером клиента и в следующий раз браузер пойдет по адресу из кэша и так будет происходить все время, пока кэш не будет очищен. Ответ 302 (Moved Temporarily - Перемещено временно) не кэшируется браузером клиента и в следующий раз запрос к серверу будет послан заново.
Добавим третий блок server {}, в котором будет находиться все оставшееся.
Начнем с указания порта, который будет слушать сервер. По умолчанию это 80-й порт.
listen 80;
Укажем доменное имя сайта, для примера я использую test.com.
server_name test.com;
Добавим корневую директорию сайта и тип индексного файла.
root /var/www/test/public; index index.php;
Укажем местонахождение лог-файлов доступа (access) и ошибок (error).
access_log /var/www/test/logs/access.log; error_log /var/www/test/logs/error.log;
Основная часть почти готова, уже в таком виде сервер может обслуживать простенькие сайты на html, только тогда index.php нужно будет заменить на index.html.
Но поскольку сайт будет работать на WordPress, то необходимо добавить набор некоторых опций и правил, согласно WordPress-документации для Nginx.
Поскольку я не люблю кашу в конфигурационных файлах и мне нравится когда все разложено по своим местам, то следующие опции я буду подключать дополнительными файлами, через include. Такой способ удобен и практичен, однажды написанный файл может включаться в другие сайты, существенно экономя время написания конфигов.
Создадим два дополнительных файла в каталоге /etc/nginx/conf.
touch /etc/nginx/conf/restrictions.conf touch /etc/nginx/conf/wordpress.conf
Подключим созданные файлы внутри третьего блока server {}, сразу после лог-файлов. Подобное подключение выполняется там где оно прописано и равносильно записи внутри самого блока. Файлы должны включаться в такой последовательности.
# Подключение restrictions.conf include /etc/nginx/conf/restrictions.conf; # Подключение wordpress.conf include /etc/nginx/conf/wordpress.conf;
Готовый файл test выглядит так.
### хост-файл test ###
### Включается в контекст http {}, файла nginx.conf
### Располагается в /etc/nginx/sites-available
# Запрет на обращение к серверу по ip-адресу
server {
listen 80 default_server;
server_name _;
return 444;
}
# Редирект с www на основное доменное имя
server {
listen 80;
server_name www.test.com;
return 301 $scheme://test.com$request_uri;
}
server {
# Порт который будет слушать nginx
listen 80;
# Имя сайта
server_name test.com;
# Корневая директория и индексный файл
root /var/www/test/public;
index index.php;
# Лог-файлы
access_log /var/www/test/logs/access.log;
error_log /var/www/test/logs/error.log;
# Подключение restrictions.conf
include /etc/nginx/conf/restrictions.conf;
# Подключение wordpress.conf
include /etc/nginx/conf/wordpress.conf;
}
restrictions.conf
Добавляем содержимое в restrictions.conf.
nano /etc/nginx/conf/restrictions.conf
Немного облегчим работу сервера снизив на него нагрузку. Не будем отмечать в логах доступа запросы к файлам favicon.ico и robots.txt. Также не станем фиксировать 404-ю ошибку в случае их отсутствия.
location = /favicon.ico {
log_not_found off;
access_log off;
}
location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}
Немного обезопасим работу сервера путем запрета доступа к скрытым файлам и запрета выполнения php-файлов в директории uploads.
# Запрещаем доступ к скрытым файлам
location ~ /\. {
deny all;
}
# Запрещаем доступ к файлам .php в директории uploads
location ~* /(?:uploads|files)/.*\.php$ {
deny all;
}
Готовый файл restrictions.conf выглядит так.
### restrictions.conf ###
### Включается в контекст server {}
### Располагается в /etc/nginx/conf
location = /favicon.ico {
log_not_found off;
access_log off;
}
location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}
# Запрещаем доступ к скрытым файлам
location ~ /\. {
deny all;
}
# Запрещаем доступ к файлам .php в директории uploads
location ~* /(?:uploads|files)/.*\.php$ {
deny all;
}
wordpress.conf
Добавляем содержимое в wordpress.conf.
nano /etc/nginx/conf/wordpress.conf
Первым делом установим правило обработки входящих запросов и дальнейшей их передачи на обработку PHP. Работает оно примерно так. Все запросы поступающие к серверу должны передаваться на обработку PHP/Wordpress, но если запрос обращен к конкретному файлу существующему на сервере, то такой файл следует отдать самостоятельно, не прибегая к помощи PHP.
Правило задается директивой try_files, сначала проверяется существование нужного файла $uri, потом на его наличие проверяются директории $uri/, а если запрос не является запросом конкретного файла, то он передается на index.php, для обработки силами WordPress. Правило задается внутри контекста "location/".
location / {
try_files $uri $uri/ /index.php?$args;
}
Следующее выражение добавляет конечный слэш "/" к запросам содержащим "/wp-admin".
rewrite /wp-admin$ $scheme://$host$uri/ permanent;
Настроим передачу запросов к FastCGI-серверу.
location ~ \.php$ {
try_files $uri =404;
include fastcgi_params;
fastcgi_index index.php;
fastcgi_pass unix:/var/run/php-fpm.sock;
fastcgi_param SCRIPT_FILENAME
$document_root$fastcgi_script_name;
}
Теперь запросу "index.php" будет соответствовать не только префиксный location "/", а еще и регулярное выражение "\.php$". Следовательно запрос будет обработан в контексте регулярного выражения и передан FastCGI-серверу через 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". Теперь FastCGI-сервер знает местонахождение файла для выполнения.
Готовый файл wordpress.conf выглядит так.
### wordpress.conf ###
### Включается в контекст server {}
### Располагается в /etc/nginx/conf
location / {
try_files $uri $uri/ /index.php?$args;
}
rewrite /wp-admin$ $scheme://$host$uri/ permanent;
location ~ \.php$ {
try_files $uri =404;
include fastcgi_params;
fastcgi_index index.php;
fastcgi_pass unix:/var/run/php-fpm.sock;
fastcgi_param SCRIPT_FILENAME
$document_root$fastcgi_script_name;
}
Написанную конфигурацию можно проверить. Ответ должен быть таким как у меня.
nginx -t nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful
Если все в порядке, то можно перезапустить сервер и переходить к установке WordPress.
systemctl restart nginx
