Настройте nginx + PHP — FIPM и HTTPS с помощью Let’s Encrypt на Ubuntu Server 16.04 LTS

Кэширование в nginx

Тема кэширования очень обширна. Много копий сломано о том, какое и где кэширование лучше применять. В том же wordpress существует огромное множество плагинов для кэширования. Nginx может самостоятельно хранить и управлять кэшом. В некоторых случаях это будет эффективнее, чем использовать плагины. Но все сильно зависит от конкретного проекта.

Кэшировать Nginx может разные вещи:

• Статику, которую получает с удаленного сервера, сохраняет себе и раздает быстрее, чем удаленный сервер.
• Динамику, превращая ее в статику и раздавая самостоятельно, без обращения к бэкенду.

Конкретно с WordPress я обычно поступаю следующим образом. Кэширование nginx я не использую. Вместо этого я использую плагин WP Total Cache. Он формирует статические html страницы по заданным в его настройках параметрам. А дальше я эти страницы отдаю напрямую через nginx, минуя вообще ядро WordPress. За счет этого достигается максимальное быстродействие. Вот пример настроек Nginx из секции server виртуального хоста для отдачи кэша WordPress.

set $cache_uri $request_uri;
if ($request_method = POST) { set $cache_uri 'null cache';
}
if ($query_string != "") { set $cache_uri 'null cache';
}
if ($request_uri ~* "(/wp-admin/|/xmlrpc.php|/wp-(app|cron|login|register|mail).php|wp-.*.php|/feed/|index.php|wp-comments-popup.php|wp-links-opml.php|wp-locations.php|sitemap(_index)?.xml|[a-z0-9_-]+-sitemap([0-9]+)?.xml)") { set $cache_uri 'null cache';
}
if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_logged_in") { set $cache_uri 'null cache';
}
location / { try_files /wp-content/cache/supercache/$http_host/$cache_uri/index-https.html $uri $uri/ /index.php?$args;
}

Сначала идут проверки для добавления исключений к некоторым запросам, для которых кэширование не будет работать. А потом отдается статика из директории с кэшом. Если для заданного URI кэша нет, он уходит дальше в обработку.

В данном случае используется именно плагин WP, а не кэш nginx только из-за удобства управления кэшом через панель управления сайтом. Сам плагин делает ровно то же самое, что может делать nginx. Кэш в самом nginx настраивается следующим образом.

Сначала добавляются настройки кэширования в nginx.conf. Дальше речь пойдет о кэшировании динамики через fastcgi.

http {
... fastcgi_cache_path /var/cache/nginx/php levels=1:2 keys_zone=php_cache:32m max_size=3g; fastcgi_cache_key "$scheme$request_method$host$request_uri";
...
}

• fastcgi_cache_path — директива для объявления кэша для fatcgi;
• /var/cache/nginx/php — директория, где будут храниться файлы кэша;
• levels=1:2 — уровень вложенности каталогов в директории с кэшом;
• keys_zone=php_cache — название зоны;
• max_size=3g — размер директории с кэшом в 3Гб.

Не забудьте создать указанную директорию для кэша /var/cache/nginx/php. В конфигурацию виртуального хоста добавляем параметры кэширования в location с php.

location ~ \.php$ { fastcgi_pass unix:/var/run/php-fpm.sock; fastcgi_index index.php; include fastcgi_params; fastcgi_cache php_cache; fastcgi_cache_valid 200 120m; }
}

Кэшируем ответы с кодом 200 на 120 минут.

Для кэширования запросов с ответами от бэкенда через proxy_pass, необходимо использовать директиву proxy_cache_path.

proxy_cache_path /var/cache/nginx/proxy levels=1:2 keys_zone=proxy_cache:32m max_size=3G;

И далее в вирутальном хосте.

location / { proxy_pass http://backend; proxy_cache proxy_cache; proxy_cache_valid 200 120m;
}

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

Настройка UFW

Перед предоставлением доступа к сервису, следует настроить файрвол.

Для просмотра приложений, с которыми будет взаимодействовать UFW, вводим следующую команду:

$ sudo ufw app list

Будет выведена следующая информация:

Это означает, что UFW может работать с тремя вариантами протоколов веб-сервера:

1. Full – открыты два порта (80 и 443).
2. HTTP – открыт только 80 порт.
3. HTTPS – открывается только 443 порт.

Пока не настроен SSL протокол, открываем 80 порт. Вводим команды:

$ sudo ufw allow 'Nginx HTTP'

Чтобы не потерять доступ по SSH, вводим команду:

$ sudo ufw allow ssh
$ sudo ufw enable

Будет выведено предупреждение:

Command may disrupt existing ssh connections. Proceed with operation (y|n)?

Нужно согласиться (нажать «y»).

$ sudo ufw status

На экране будет выведено:

Status: active
To                               Action             From
--                               ------     ----
Nginx HTTP               ALLOW           Anywhere
22/tcp                         ALLOW           Anywhere
Nginx HTTP (v6)                  ALLOW           Anywhere (v6)
22/tcp (v6)                  ALLOW           Anywhere (v6)

HTTP протокол открыт.

Запуск

После настройки конфигурации, можно Nginx запустить с помощью команды sudo service nginx start.

Любое изменение необходимо подтверждать перезагрузкой через service nginx reload. Проверка статуса осуществляется через команду service nginx status.

Настройка виртуальных хостов

Создадим папку для сайта:

sudo mkdir -p /var/www/testsite.dev/html

После добавим индексный файл:

sudo nano /var/www/testsite.dev/html/index.html

Заполним его минимальными данными для отображения сайта:

После создадим конфигурационный файл сайта в папке sites-available:

sudo nano /etc/nginx/sites-available/testsite.dev.conf

Заполним его простейшей конфигурацией:

Последнее, что осталось сделать, — это создать ссылку в директории sites-enabled на конфигурацию сайта testsite.dev, чтобы добавить его из доступных во включенные:

sudo ln -s /etc/nginx/sites-available/

После создания виртуального хоста проведем тестирование конфигурации:

sudo nginx -t

Отключим сайт по умолчанию, удалив запись о дефолтном виртуальном хосте:

sudo rm /etc/nginx/sites-enabled/default

sudo systemctl restart nginx

Другой вариант — воспользоваться командой curl:

Работа nginx с php-fpm

В предыдущих разделах я уже показал примеры конфигурации, где запросы по определенным URI перенаправляются на php-fpm. Еще более подробно я рассмотрел этот вопрос в отдельной статье по настройке php-fpm. Сейчас просто покажу на реальном примере, как выглядит взаимодействие nginx и php-fpm.

Php-fpm может слушать как сокет unix, так и tcp порт. Эти настройки задаются в конфиге пула. Это может быть либо

listen = 127.0.0.1:9000

listen = /var/run/php-fpm/php-fpm.sock

В зависимости от того, в каком режиме работает php-fpm, зависят настройки в nginx.

Вот примерный конфиг php-fpm для пула www.conf на виртуальной машине с 1Gb памяти.

[www]
listen = /var/run/php-fpm/php-fpm.sock
listen.allowed_clients = 127.0.0.1
listen.mode = 0660
listen.owner = nginx
listen.group = nginx
user = nginx
group = nginx
; как будут создаваться новые рабочие процессы
pm = dynamic
; максимальное количество рабочих процессов
pm.max_children = 15
; число запущенных процессов при старте сервера
pm.start_servers = 6
; минимальное и максимальное количество процессов в простое
pm.min_spare_servers = 4
pm.max_spare_servers = 8
slowlog = /var/log/php-fpm/www-slow.log
pm.max_requests = 250
php_admin_value[error_log] = /var/log/php-fpm/www-error.log
php_admin_flag[log_errors] = on
php_value[session.save_handler] = files
php_value[session.save_path] = /var/lib/php/session
pm.status_path = /status

Чтобы заработал php в nginx через php-fpm, достаточно убедиться, что php-fpm работает и указать в виртуальном хосте location для php. Пример реальных настроек для wordpress сайта.

location ~ \.php$ { try_files $uri =404; fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock; #fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include fastcgi_params; fastcgi_param DOCUMENT_ROOT /web/sites/example.com/www/; fastcgi_param SCRIPT_FILENAME /web/sites/example.com/www$fastcgi_script_name; fastcgi_param PATH_TRANSLATED /web/sites/example.com/www$fastcgi_script_name; fastcgi_param QUERY_STRING $query_string; fastcgi_param REQUEST_METHOD $request_method; fastcgi_param CONTENT_TYPE $content_type; fastcgi_param CONTENT_LENGTH $content_length; fastcgi_param HTTPS on; # включать, если сайт по https работает fastcgi_intercept_errors on; fastcgi_ignore_client_abort off; fastcgi_connect_timeout 60; fastcgi_send_timeout 180; fastcgi_read_timeout 180; fastcgi_buffer_size 128k; fastcgi_buffers 4 256k; fastcgi_busy_buffers_size 256k; fastcgi_temp_file_write_size 256k;
}

В целом все. Этого достаточно для настройки связки nginx + php-fpm. Типовой ошибкой в данном случае является то, что nginx не имеет доступа к unix сокету php-fpm. По-умолчанию после установки он запускается с правами apache. Если пользователя не исправить на nginx, то у веб сервера не будет доступа к сокету, php не заработает. В своем примере конфига php-fpm я указал пользователя правильно.

Важные элементы конфигурации

• worker_processes — количество рабочих процессов, которые будет использовать сервер. Число должно соответствовать количеству ядер процессора.
• worker_connections — это максимальное количество подключений каждого рабочего процесса. Чем выше показатель, тем больше человек обслуживается одновременно.
• access_log & error_log — эти файлы используется для регистрации любой ошибки и попыток получения доступа. Журналы изучаются для устранения неполадок и при аварийном завершении работы.
• gzip — это настройки для «сжатия» запросов Nginx. Включение параметра позволит повысить производительность. По умолчанию поднастройки закомментированы.
• gzip_comp_level — уровень сжатия от 1 до 10. Этот показатель обычно не превышает 6.
• gzip_types — это перечень типов ответов, к которым применяется сжатие.

Сервер может обслуживать множество сайтов. Файлы, которые определяют какие именно, находятся в директории /etc/nginx/sites-available.

Чтобы Nginx работал с сайтами, их необходимо слинковать с /etc/nginx/sites-enabled.

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

Символьная ссылка — это путь к файлу. Общий синтаксис для неё выглядит так:

ln -s <на какой существующий объект будет вести> <создаваемый симлинк>

Примеры ссылок для каталога и файла:

• ;
• .

Директория sites-available содержит конфигурацию виртуальных хостов. Это позволяет веб-серверу настраиваться для множества сайтов с разной конфигурацией. Сайты в этой директории не задействуются и будут обслуживаться только, если сделать символьную ссылку на папку sites-enabled.

DNS

Для простой схемы получения бесплатного https сертификата от Let’s Encrypt нам понадобится доступ к DNS серверу. Прописываем в нем IP адрес нашего Ubuntu сервера с именем, скажем, xyz. Давайте, для определенности, предположим, что у вас есть домен mydomain.com, т.е. DNS имя нашего сервера будет xyz.mydomain.com

Подготовка сервера

Откроется оснастка создания сервера, где необходимо задать понятное для дальнейшей работы имя сервера, в примере это «WebSrv01». Регион и зону можно оставить без изменения. Для выбора операционной системы необходимо нажать кнопку «Выбрать другой источник».

Откроется меню «Выбор источника».

В поле «Операционные системы», выбираем Ubuntu, в левом поле появится список всех доступных образов операционных систем на базе данной ОС, выбираем «Ubuntu 20.04 LTS 64-bit» и нажимаем кнопку «Выбрать».

Перемещаемся вниз по странице. В нашем примере используется только «Локальный диск», флажок установлен, в поле «Сетевые диски» нажимаем кнопку «Удалить диск».

В поле «Сеть», поскольку это наш первый сервер выбираем «Приватная подсеть + 1 плавающий IP», после выбора значение в поле сменится на «Новый плавающий IP адрес».

Необходимо скопировать «Пароль для root», он понадобиться для первоначальной настройки сервера через SSH протокол.

Нажимаем кнопку «Создать», сервер будет доступен примерно через 1 минуту. Переходим в меню «Облачная платформа» — «Серверы».

В списке появится сервер с именем, что задали ранее, его IP адрес, который будем использовать для удаленного подключения, на скриншоте в области с цифрой 3, статус сервера ALIVE, означает готовность сервера. Подключаемся к серверу, используя любой SSH-клиент.

Проведем небольшую первоначальную настройку сервера. Обновим информацию о доступных пакетах из подключенных репозиториев:

apt update

adduser webuser

usermod -aG sudo webuser

Открываем конфигурационный файл SSH-сервера:

nano /etc/ssh/sshd_config

В открывшемся текстовом файле ищем строку #Port 22 и удаляем в начале строки символ комментария #, стандартный номер порта 22 рекомендуется сменить в целях безопасности, пускай это будет 22100. В конечном итоге строка должна выглядеть следующим образом:

Port 22100

Переходим к строке PermitRootLogin yes, меняем значение на no, тем самым запретив вход пользователя root напрямую:

PermitRootLogin no

Находясь в редакторе, нажимаем комбинацию клавиш Ctrl+O, внизу появится строка подтверждения: File Name to Write: /etc/ssh/sshd_config, нажимаем ENTER для сохранения изменений, затем Ctrl+X для выхода из редактора.

После изменений файла конфигурации SSH сервера, необходимо выполнить его перезапуск для того, чтобы изменения вступили в силу:

service sshd restart

Установка сервера nginx может быть выполнена как непосредственно на машину, так и в виде docker контейнера. У каждого метода есть свои преимущества и недостатки, описание которых выходит за рамки данной статьи. Мы посмотрим оба варианта.

Начнем с непосредственной установки на сервер:

apt install nginx

Дожидаемся окончания процесса установки.

Разрешим автозапуск сервера:

systemctl enable nginx

systemctl is-enabled nginx

Если в ответ получили «enabled», значит nginx успешно добавлен в автозагрузку.

Настройка nginx

Рассмотрим главный конфигурационный файл nginx — /etc/nginx/nginx.conf. По умолчанию он выглядит следующим образом:

user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;
events { worker_connections 768;
}
http { sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; types_hash_max_size 2048; include /etc/nginx/mime.types; default_type application/octet-stream; ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; ssl_prefer_server_ciphers on; access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log; gzip on; include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*;
}

Конфигурационный файл состоит из директив. О них и пойдет речь дальше.

Директивы

Переменные в nginx

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

Установка и настройка php-fpm

Для работы веб приложений, написанных на языке PHP необходимо установить php-fpm в качестве бэкэнда:

apt install php-fpm php-mysql

После установки сервис будет автоматически запущен и добавлен в автозагрузку. Создаем файл пула для конкретного сайта sampledomain.ru:

touch /etc/php/7.4/fpm/pool.d/sampledomain.ru.conf

nano /etc/php/7.4/fpm/pool.d/sampledomain.ru.conf

Создаем следующую конфигурацию:

[sampledomain.ru]
listen = /var/run/php/sampledomain.ru.sock
listen.mode = 0666
user = webuser
group = webuser
chdir = /home/webuser/www/sampledomain.ru
php_admin_value[upload_tmp_dir] = /home/webuser/tmp
php_admin_value[soap.wsdl_cache_dir] = /home/webuser/tmp
php_admin_value[date.timezone] = Europe/Moscow
php_admin_value[upload_max_filesize] = 100M
php_admin_value[post_max_size] = 100M
php_admin_value[open_basedir] = /home/webuser/www/sampledomain.ru/
php_admin_value[session.save_path] = /home/webuser/tmp
php_admin_value[disable_functions] = exec,passthru,shell_exec,system,proc_open,popen,curl_multi_exec,parse_ini_file,show_source
php_admin_value[cgi.fix_pathinfo] = 0
php_admin_value[apc.cache_by_default] = 0
pm = dynamic
pm.max_children = 7
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 4

Нажимаем комбинацию клавиш Ctrl+O, внизу появится строка подтверждения: File Name to Write: /etc/php/7.4/fpm/pool.d/sampledomain.ru.conf, нажимаем ENTER для сохранения изменений, затем Ctrl+X для выхода из редактора.

Перезагружаем сервис php-fpm, чтобы он мог перечитать файлы конфигураций:

service php7.4-fpm restart

Проверяем, что сервис перезапустился корректно и наша новая конфигурация sampledomain.ru обслуживается:

service php7.4-fpm status

О том, что сервис запущен, свидетельствует наличие строки Active: active (running), чуть ниже список обслуживаемых конфигураций в виде дерева, где можно увидеть php-fpm: pool sampledomain.ru, значит все работает.

Конфигурация nginx

У нас имеется главный конфигурационный файл, содержимое которого оставляем неизменным для примера. Создадим файл виртуального хоста:

touch /etc/nginx/sites-available/sampledomain.ru.conf

nano /etc/nginx/sites-available/sampledomain.ru.conf

Заполняем его следующим содержимым:

server { listen 80; server_name sampledomain.ru www.sampledomain.ru; charset utf-8; root /home/webuser/www/sampledomain.ru; index index.php index.html index.htm; # Static content	location ~* ^.+.(jpg|jpeg|gif|png|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|mp3|bmp|flv|rtf|js|swf|iso)$ { root /home/webuser/www/sampledomain.ru; } location ~ \.php$ { include fastcgi.conf; fastcgi_intercept_errors on; try_files $uri =404; fastcgi_pass unix://var/run/php/sampledomain.ru.sock; } location / { try_files $uri $uri/ /index.php?q=$uri$args; } }

Нажимаем комбинацию клавиш Ctrl+O, внизу появится строка подтверждения: File Name to Write: /etc/nginx/sites-available/sampledomain.ru.conf, нажимаем ENTER для сохранения изменений, затем Ctrl+X для выхода из редактора.

Создаем символическую ссылку на данный виртуальный хост из директории /etc/nginx/sites-available в директорию /etc/nginx/sites-enabled, чтобы nginx его обслуживал:

ln -s /etc/nginx/sites-available/sampledomain.ru.conf /etc/nginx/sites-enabled/

Необходимо создать структуру каталогов веб проекта:

mkdir -p /home/webuser/www/sampledomain.ru

mkdir -p /home/webuser/tmp

Создаем файл для тестирования работы связки nginx и php-fpm:

echo "<?php phpinfo(); ?>" > /home/webuser/www/sampledomain.ru/index.php

Задаем владельца каталогов и находящихся внутри файлов:

chown -R webuser:webuser /home/webuser/www/

chown -R webuser:webuser /home/webuser/tmp/

usermod -aG webuser www-data

Конфиги написаны, директории созданы, перезапускаем nginx для того, чтобы он перечитал файлы конфигураций:

service nginx restart

Переходим в браузере по адресу http://sampledomain.ru и должны увидеть такую картину:

Все настроили правильно.

Настройка системы

sudo apt-get install nginx mysql-server
sudo mysql_secure_installation

Nginx и MySQL

mysql_secure_installation задает несколько вопросов по настройке.

Would you like to setup VALIDATE PASSWORD plugin? n
Change the password for root? n
Remove anonymous users? y
Disallow root login remotely? y
Remove test database and access to it? y
Reload privilege tables now? y

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

sudo add-apt-repository ppa:ondrej/php && sudo apt-get update
sudo apt-get install php7.1 php7.1-cli php7.1-common php7.1-mysql php7.1-fpm php7.1-curl php7.1-gd php7.1-bz2 php7.1-mcrypt php7.1-json php7.1-tidy php7.1-mbstring php-redis php-memcached php7.1-zip php7.1-dom php7.1-gmp

PHP 7.1 и 7.2 пока нет в стандартных репозиториях.

sudo apt-get install mc
mc

Устанавливать необязательно, если вам больше нравится другой редактор и способ передвижения по файловой системе.

Не стоит после установки запускать в первый раз через sudo mc, так как файлы конфигурации создадутся от пользователя root, и при запуске от обычного пользователя будет ошибка доступа.

sudo mcedit /etc/php/7.1/fpm/php.ini
# cgi.fix_pathinfo=0
sudo systemctl restart php7.1-fpm

Найти настройку cgi.fix_pathinfo, раскомментировать и поставить 0. Это закрытие уязвимости, подробнее можно почитать здесь.

sudo mcedit /etc/nginx/sites-available/default
server { listen 80 default_server; listen [::]:80 default_server; root /var/www/html;
#! index index.php index.html index.htm index.nginx-debian.html; server_name _;
#! location / { try_files $uri $uri/ /index.php?$query_string; }
#! location ~ \.php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php7.1-fpm.sock; }
#! location ~ /\.ht { deny all; }
}

Восклицательными знаками отмечены места, где надо поменять.

— index — добавить index.php
— try_files — убрать =404, добавить /index.php?$query_string
— location ~ \.php$ — раскомментировать секцию, поменять название файла с сокетом
— location ~ /\.ht — раскомментировать секцию для файлов *.htaccess

sudo nginx -t
sudo systemctl reload nginx

Проверить правильность конфигурации, если все нормально, перезагрузить ее.

echo "<?php phpinfo();" | sudo tee /var/www/html/info.php > /dev/null
# check http://11.22.33.44/info.php
sudo rm /var/www/html/info.php

sudo chown -R "$USER":www-data /var/www/
sudo find /var/www/ -type f -exec chmod 660 {} \; && sudo find /var/www/ -type d -exec chmod 2770 {} \;
sudo usermod -a -G www-data ubuntu

Сейчас в веб-каталоге все создано от рута, надо изменить на обычного пользователя. Nginx запускает PHP от пользователя www-data из группы www-data, SSH подключается с пользователем ubuntu. Надо добавить ubuntu в эту группу, иначе могут быть проблемы с доступом. Например, когда какая-то консольная команда создает папку, куда будет идти запись и при открытии сайта через веб.

Установка nginx

В своей статье я не буду привязываться к конкретному дистрибутиву, так как настройка nginx одинакова везде. Формат файла один и тот же, поэтому конфигурация без проблем может мигрировать на разные системы. Править придется только пути к файлам и директориям. Тем не менее, я расскажу, как выполнить установку на популярные дистрибутивы.

Установку nginx на CentOS 7 я подробно разбирал в соответствующей статье про настройку web сервера на centos. Здесь просто перечислю необходимые шаги.

Подключаем репозиторий nginx для CentOS 7:

# rpm -Uvh http://nginx.org/packages/centos/7/noarch/RPMS/nginx-release-centos-7-0.el7.ngx.noarch.rpm

# yum install nginx

Вот и все. На этом установка на Centos 7 закончена. Пример установки nginx на Debian.

Подключаем репозиторий для Debian:

# echo "deb http://nginx.org/packages/debian `lsb_release -cs` nginx" | tee /etc/apt/sources.list.d/nginx.list

Импортируем ключ для проверки подлинности пакетов:

# curl -fsSL https://nginx.org/keys/nginx_signing.key | sudo apt-key add -

Устанавливаем nginx на Debian:

# apt update && apt install nginx

Установим nginx на Ubuntu. Подключаем репозиторий:

# echo "deb http://nginx.org/packages/ubuntu `lsb_release -cs` nginx" | tee /etc/apt/sources.list.d/nginx.list

# curl -fsSL https://nginx.org/keys/nginx_signing.key | sudo apt-key add -

Выполняем установку nginx на Ubuntu:

# apt update && apt install nginx

На всех указанных системах запуск веб сервера выполняется командой:

# systemctl start nginx

Добавляем nginx в автозагрузку:

# systemctl enable nginx

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

Nginx в Docker

Неоспоримые преимущества от использования docker получают разработчики, поэтому они очень часто его используют. В том числе в виде контейнеров docker с nginx. Установка nginx через docker может быть выполнена из официального образа nginx в Docker Hub. Если не умеете работать с docker, смотрите мою статью по этой теме — установка docker в centos. Установить и запустить nginx в docker можно примерно такой командой:

# docker run --name nginx01 -p 80:80 -d nginx

В данной команде:

• nginx01 — имя созданного контейнера, основанного на базовом образе nginx
• -p 80:80 — сопоставление порта на локальной машине, порту в контейнере. Сначала указывается локальный порт, потом внутри контейнера.
• -d — ключ, обозначающий запуск контейнера в режиме службы.

Это общий случай установки. Образ nginx в данном случае будет скачан автоматически при создании первого контейнера. Для удобства используется большее количество параметров. Для примера запустим еще один контейнер с другим названием и с расширенными параметрами.

# docker run --name nginx02 -p 81:80 -v ~/nginx/www:/usr/share/nginx/html -v ~/nginx/conf:/etc/nginx -v ~/nginx/logs:/var/log/nginx -d nginx

В данном примере мы создали еще один контейнер naginx02, назначили ему порт 81 на локальной машине, в контейнер смонтировали 3 локальные директории:

1. ~/nginx/www — здесь будут лежать исходники сайта.
2. ~/nginx/conf — полная конфигурация nginx. Ее нужно будет скопировать откуда-то.
3. ~/nginx/logs — логи nginx.

Не обязательно выносить на хост все эти папки. Я показываю для примера. Вы выбирайте только то, что вам действительно нужно.

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

Настройка Nginx

Администрирование веб-сервера представляет из себя изменение и поддержку конфигурационных файлов. Среди них 1 файл конфигурации и 2 каталога. Это nginx.conf, sites-available и sites-enabled соответственно. Все они лежат в директории /etc/nginx.

Рассмотрим более детально главный файл конфигурации. Для этого откроем его для просмотра, используя редактор:

sudo nano /etc/nginx/nginx.conf

После выполнения команды откроется файл, разделенный на модули. По умолчанию он выглядит так, как показано на рисунке ниже:

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

Перечислим некоторую часть директив главного конфигурационного файла:

• worker_processes — число рабочих процессов сервера. Оно должно быть не больше, чем количество ядер процессора. Параметр auto установит число автоматически.
• pid — файл с номером главного процесса.
• include — отвечает за подключение иных файлов конфигурации, удовлетворяющих заданной маске.
• events — контекст, состоящий из директив, влияющих на работу сетевого соединения.
• worker_connections — максимальное число одновременно работающих соединений одного рабочего процесса.
• multi_accept — флаг, который может быть как включен (on), так и выключен (off). Если он включен, то рабочий процесс будет принимать все новые соединения, иначе только одно.
• use — указывает метод обработки соединений. По умолчанию сервер выбирает наиболее подходящий и эффективный.
• http — контекст, состоящий из директив, отвечающих за работу HTTP-сервера.
• sendfile — включает (on) или отключает (off) метод отправки данных sendfile().
• tcp_nopush, tcp_nodelay — параметры, влияющие на производительность. Первый заставляет сервер отправлять заголовки HTTP-ответов одним пакетом, а второй позволяет не буферизировать данные и отправлять их короткими очередями.
• keepalive_timeout — параметр, отвечающий за время ожидания keep-alive соединения до его разрыва со стороны сервера.
• keepalive_requests — максимальное число запросов по одному keep-alive соединению.
• error_log — лог ошибок веб-сервера. Для сбора ошибок в определенной секции (http, server и т.д.) необходимо разместить директиву внутри нее.
• gzip — сжатие контента. 

Настройка

Nginx

Настраиваем Nginx’у прописанный ранее в DNS server name (файл /etc/nginx/sites-available/default)

server_name xyz.mydomain.com; 

Прописываем ссылку на установленный Apache Tomcat (если Вы ничего не меняли, то он «живет» на порту 8080). Нам нужно добавить блок upstream до блока server.

upstream tomcat { server 127.0.0.1:8080 fail_timeout=0;
}
server {
...

Вносим изменения в блок location и перенаправляем весь трафик на Apache Tomcat

server {
... location / {
# try_files $uri $uri/ =404; include proxy_params; proxy_pass http://tomcat/; }

Проверяем, что все внесли корректно

service nginx configtest

и рестартуем nginx

service nginx restart

Apache Tomcat

В принципе эта часть опциональная и если Вам не важно чтобы на tomcat «приходили» реальные ip адреса, порты, схема по которой идет запрос (я про https) и запрашиваемый сервер, то этот шаг можно опустить. Однако, в некоторых случаях этот шаг обязателен (например, для технологии Java Web Start aka JNLP).

В файл /etc/tomcat8/server.xml в блок <Host/> добавляем.

<Host>
... <Valve className="org.apache.catalina.valves.RemoteIpValve" remoteIpHeader="x-forwarded-for" remoteIpProxiesHeader="x-forwarded-by" protocolHeader="x-forwarded-proto" />
</Host>

service tomcat8 restart

Настройка SSL сертификата

Далее рассмотрим момент с настройкой ssl сертификатов в nginx. В общем случае с этим не должно быть каких-то проблем. Тут все просто. Можно глобально задать настройки ssl для всех виртуальных хостов, а можно отдельно в каждом. Вот пример настроек ssl для nginx.conf.

ssl_session_cache shared:SSL:50m;
ssl_session_timeout 1d;
ssl_session_tickets on;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
ssl_ciphers 'TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-256-GCM-SHA384:ECDHE:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/ssl/certs/dhparam.pem;
ssl_stapling on;
ssl_stapling_verify on;
add_header Strict-Transport-Security max-age=15768000;
resolver 8.8.8.8;

Здесь уже включена поддержка TLS 1.3 и соответствующие шифры. Сейчас не готов прокомментировать именно такой выбор шифров. В свое время, перед настройкой TLS 1.3 я изучил этот вопрос и собрал такой набор, который везде использую.

Часто возникают споры насчет директивы resolver. На dns сервер 8.8.8.8 есть нарекания по стабильности. Так что выбор dns сервера остается за вами. С подобными настройками ssl вы получите рейтинг A+.

Для генерации файла dhparam.pem, воспользуйтесь командой:

# openssl dhparam -out /etc/ssl/certs/dhparam.pem 4096

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

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

server { listen 443 ssl http2; ........................ ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; ........................ location ~ \.php$ { ........................ fastcgi_param HTTPS on; ........................ }
}

Редирект с http на https

Добавим переадресацию с http на https. Для этого добавляем в настройки виртуального хоста еще одну директиву server.

server { listen 80; server_name example.com www.example.com; access_log /var/log/nginx/example.com.access.log main; root /var/www/example.com/public; location / { return 301 https://example.com$request_uri; }
}

Проксирование запросов

Nginx очень производительный веб сервер, поэтому его часто используют в качестве Reverse Proxy для других служб и серверов. Подробно вопрос проксирования запросов в nginx с помощью proxy_pass я рассмотрел отдельно. Сейчас же в двух словах объясню, что это такое. Допустим, у вас есть какой-то сервис на отдельном сервере и вы ходите перенаправлять на него часть запросов с вашего сайта. Для этого вы делаете отдельный location и указываете, что все запросы по определенному правилу нужно перенаправлять на этот сервер.

location /forum/ { proxy_pass http://192.168.13.31; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Real-IP $remote_addr; proxy_redirect default;
}

Все запросы с урлами, содержащими /forum/ будут перенаправлены на отдельный сервер, где трудится тяжелый форум со своей базой данных и своими настройками. Им может управлять другой администратор и вообще он не имеет к вам никакого отношения. Таким образом, большой проект можно разделить на части с делегированием полномочий. Но это отдельная история.

Nginx proxy_pass удобно использовать разработчикам для проксирования запросов в разные docker контейнеры, которые подняты на рабочей машине на разных портах. Можно перенаправлять не только отдельные урлы, но и весь сайт. Допустим, вы делаете какие-то фильтрации трафика на стороне сервера с nginx, а потом все запросы отправляете на исходный сайт. Тогда делаете простую настройку для проксирования:

location / {
proxy_pass http://192.168.13.31;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr; }

Все запросы уходят на сторонний сервер. Частным случаем проксирования в nginx является работа в связке с Apache, о чем я расскажу далее.

502 bad gateway и другие ошибки nginx

Ошибка 502 bad gateway знакома многим пользователям интернета, не только системным администраторам. Ее рано или поздно можно увидеть на любом сайте. Что она означает?  В общем случае, это значит, что на веб сервере какие-то проблемы.

Ошибка 502 описана в RFC Hypertext Transfer Protocol (HTTP/1.1) в разделе 6.6.3. Там говорится, что во время обработки запроса веб сервер, в данном случае nginx, не получил ответ от какого-то бэкенда. Расскажу, что это обычно значит на практике.

Допустим, у вас nginx работает в связке с apache или php-fpm. Вы видите описываемую ошибку. Причин может быть две:

1. Службы php-fpm или apache перестали отвечать, потому что просто упали. В таком случае, nginx будет показывать всем пользователям ошибку 502, пока бэкенд не начнет отвечать.
2. Служба просто не справляется с нагрузкой. Ошибка будет только у части пользователей, а у других все будет нормально.

То же самое может произойти, если вы настроили проксирование запросов через proxy_pass на какой-то другой сервер и этот сервер перестал отвечать. Nginx будет показывать ошибку 502 bad gateway в данном случае.

Для того, чтобы исправить 502-ю ошибку, надо разобраться, с чем конкретно она связана. Если бэкенд просто упал, то надо его поднять. Если же причина не в этом, то надо более детально разбираться. Чаще всего в логах ошибок nginx есть вся информация для решение проблем с ошибкой 502. Наиболее распространенная ситуация с этой ошибкой при работе в связке с php-fpm в том, что php-fpm просто не выдерживает нагрузки, либо неправильно настроен. Возможно, у него не хватает процессов для обработки всех запросов. Тогда часть запросов будут возвращать ошибку.

Вот типичный пример ошибки 502 при работе с php-fpm. Пользователь видит ошибку. Идем смотреть лог ошибок виртуального хоста. Видим там такую строку:

2019/03/29 15:00:42 [error] 2058#2058: *18 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.13.16, server: localhost, request: "GET /1.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "192.168.13.34"

В данном случае php-fpm просто упал и перестал обрабатывать запросы.

Я достаточно часто встречаюсь с этой серверной ошибкой. Иногда разработчики напрограммируют таких конструкций, что они валят php-fpm по какой-то причине. Причем, если проект уже сдали и он давно работает, никто с этими ошибками разбираться уже не хочет. Тогда я просто ставлю костыль — автоматически перезапускаю php-fpm с помощью zabbix, ели вылезает ошибка 502 bad gateway в nginx. Такие вещи иногда годами работают и в целом всех устраивают.

Вы можете настроить внешний вид страницы с ошибкой. То, что я показал на скрине — стандартный вид ошибки 502 bad gateway в nginx при отсутствии каких-то настроек на этот счет. Вы же можете установить свою страницу при возникновении этой ошибки. На ней можно написать, к примеру, что на сервере ведутся технические работы и скоро он заработает вновь. В каждый виртуальный хост можно установить свою страницу с ошибкой. Настраивается она в секции server.

error_page 500 502 503 504 /error50x.html; location = /50x.html { root /usr/share/nginx/html;
}

Ошибка 404 not found

Еще одна популярная ошибка nginx — 404 not found.

Тут все понятно и без объяснений — пользователь открывает ссылку, а документа по этой ссылке нет. Иногда бывает не очевидно, почему по ссылке выходит 404 ошибка. В таком случае рекомендую сразу смотреть лог ошибок. Вот пример.

2019/03/29 15:18:48 [error] 2058#2058: *20 open() "/usr/share/nginx/html/502" failed (2: No such file or directory), client: 192.168.13.16, server: localhost, request: "GET /502 HTTP/1.1", host: "192.168.13.34"

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

В данном случае внешний вид страницы с ошибкой формирует сам wordpress. Но вы так же можете это настроить самостоятельно через nginx.

Команды nginx

nginx -t

Если все хорошо, в результате получим сообщение:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

В случае обнаружения ошибок, сервер уведомит об этом. Чтобы узнать используемую версию сервера, нужно ввести:

nginx –v

Можно получить расширенную информацию об nginx – его версию, параметры конфигурации сборки:

nginx –V

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

service nginx reload

Балансировка нагрузки

Для улучшения отказоустойчивости, масштабируемости, уменьшения время отклика, распределения полезной нагрузки придумали балансировщики нагрузок. На примере посмотрим, как приспособить для этого nginx.

Открываем файл виртуального хоста:

nano /etc/nginx/sites-available/sampledomain.ru.conf

Над блоком server добавляем следующее:

upstream backends { server 127.0.0.1:8080; server 127.0.0.1:8081;
}

Также вносим изменения в блок location /:

location / { proxy_pass http://backends; proxy_set_header Host $host; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Real-IP $remote_addr; }

Сохраняем результат Ctrl+O, подтверждаем нажатием ENTER, выходим из редактора Ctrl+X. Перезапускаем веб-сервер:

service nginx restart

Директива upstream перечисляет все back-end сервера, между которыми следует распределить нагрузку. В блоке location / изменился параметр директивы proxy_pass на http://backends, где backends – имя, которое присвоили группе серверов директивы upstream.

Ранее мы запустили два контейнера: первый с nginx на порту 8080, второй с apache на порту 8081. Теперь перейдя в браузере по ссылке http://sampledomain.ru и несколько раз обновляя страницу можно наблюдать чередование ответов «It works!» и «Hello from NGINX in Docker!», значит балансировка работает.

Существует несколько методов балансировки:

round-robin – используется по умолчанию, нагрузка распределяется равномерно между серверами с учетом веса.

least_conn – запросы поступают к менее загруженным серверам.

upstream backends { least_conn; server 127.0.0.1:8080; server 127.0.0.1:8081;
}

upstream backends { ip_hash; server 127.0.0.1:8080; server 127.0.0.1:8081;
}

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

Разберем на примере:

upstream backends { server 127.0.0.1:8080 weight=5; server 127.0.0.1:8081 weight=2;
}

В данной конфигурации, из 7 запросов, 5 будет обработано сервером 127.0.0.1:8080, а 2 машиной 127.0.0.1:8081

Как работает Nginx

В отличие от обычного веб-сервера, Nginx не создаёт один поток под каждый запрос, а разделяет его на меньшие однотипные структуры, называемые рабочими соединениями. Каждое такое соединение обрабатывается отдельным рабочим процессом, а после выполнения они сливаются в единый блок, возвращающий результат в основной процесс обработки данных. Одно рабочее соединение может обрабатывать до 1024 запросов одного вида одновременно.

Практическое применение

1. Отдельный порт/IP. При наличии большого количества статичного контента или файлов для загрузки, можно настроить на отдельном порту или IP-адресу, чтобы осуществлять раздачу. При большом количестве запросов рекомендуется ставить отдельный сервер и подключать к нему Nginx.
2. Акселерированное проксирование. В таком случае все пользовательские запросы на статичный контент (картинки, простой HTML, JavaScript, CSS-файлы) поступают сначала на Nginx, а он их обрабатывает самостоятельно. При этом никаких изменений исходного кода не требуется.
3. Nginx и FastCGI. Если поддерживается технология FastCGI, Apache вообще можно не использовать. Но в таком случае может потребоваться модификация кодов скриптов.

Запуск nginx

Стартуем наш веб-сервер:

service nginx start

service nginx status

Если в статусе присутствует строка Active: active (running), значит сервер работает. Также в этом можно убедиться, набрав в адресной строке браузера IP адрес сервера, будет отображено приветственное сообщение от nginx, которое выглядит так:

Настройка проекта

sudo apt-get install git
curl -sS https://getcomposer.org/installer | sudo php -- --install-dir=/usr/local/bin --filename=composer

Git и Composer

Composer лучше не ставить через apt-get, там старая версия. На сайте Composer есть скрипт для более безопасной установки с проверкой хеша. Можно использовать его, или просто взять оттуда текущий хеш и проверить вручную.

cd /var && rm -rf www/html
# set repository URL here
git clone ... www
cd www
git checkout dev
ln -s public html
composer install

Клонируем проект и устанавливаем зависимости. Вставьте свой репозиторий и название ветки.
Nginx настроен на папку html, надо ее убрать и сделать симлинк на папку где в проекте находится index.php. В Laravel это папка public.

sudo chgrp -R www-data storage bootstrap/cache
sudo chmod -R ug+rwx storage bootstrap/cache
sudo chmod -R 0777 storage/framework/cache

Устанавливаем права на папки специально для Laravel. Подробнее здесь.

cp .env.example .env && php artisan key:generate

Создаем рабочий файл с настройками окружения. Далее все как обычно — создаем, настраиваем, прописываем.

Настройка конфигурации

Новые блоки server создаются через конфигурационные файлы в /etc/nginx/conf.d. Они буду загружаться при запуске Nginx, если заканчиваются на .conf.

Основной конфигурационный файл сервера находится в /etc/nginx/nginx.conf. Через него изменяются любые настройки.

Auth basic, доступ по паролю или ограничение по ip

Покажу на простых примерах, как в nginx настроить ограничения доступа по ip, имени пользователю и паролю (Auth basic авторизация). Начнем с простого. Закроем доступ к определенной папке на сайте всем подряд и разрешим только после ввода имени пользователя и пароля. Для этого добавляем в виртуальный хост, в нужный location следующие параметры.

location /secret {
... auth_basic "Unauthorized"; auth_basic_user_file /etc/nginx/htpasswd;
...
}

Теперь нам надо создать файл с именем пользователя и паролем.

htpasswd -c /etc/nginx/htpasswd user
New password:
Re-type new password:
Adding password for user user

Если получите сообщение, что у вас нет утилиты htpasswd, установите соответствующий пакет.

# apt install apache2-utils
# yum install httpd-tools

Перечитайте конфигурацию nginx и проверяйте. Теперь доступ к /secret возможен только после авторизации по имени пользователю и паролю.

Настроим ограничение доступа по ip в nginx. Для этого достаточно добавить в свойства location или всего виртуального хоста следующие правила доступа.

location /secret {
... allow 192.168.10.10/32 deny all;
...
}

Если нужен запрет доступа ко всему сайту сразу, то ставьте это ограничение в секцию server.

Если вам нужно настроить ограничение доступа по ip на основе стран или регионов, то читайте мою отдельную статью на эту тему — блокировка доступа к сайту по странам.

Подготовка

Перед началом установки Nginx заходим в ОС под пользователем root, и создаем новый аккаунт с расширенными привилегиями sudo.

Вводим следующую команду*:

adduser host

* Здесь «host» – имя пользователя, под которым будем работать.

Далее вбиваем свою информацию об аккаунте или принимаем настройки по умолчанию, нажав «Enter».

Настройка доступа в учетную запись созданного пользователя зависит от того, какая используется root-аутентификация. Это может быть просто пароль, либо же SSH-ключи.

Если вход выполняется под паролем, то подключиться к новому пользователю можно по SSH*:

ssh host@194.61.0.6

*IP сервера в примере () следует заменить на актуальный.

Когда вход в учетную запись осуществляется при помощи SSH-ключей, тогда их необходимо скопировать в созданный аккаунт. Для этого нужно следовать следующему алгоритму:

1. Открыть терминал и ввести команду:

rsync --archive --chown= host: host ~/.ssh /home/ host

2. Добавить созданного пользователя в группу sudo:

usermod -aG sudo  host

3. Авторизоваться под новым пользователем.

Инсталляцию будем выполнять прямо из репозитория Ubuntu, посредством пакетного менеджера apt:

$ sudo apt update
$ sudo apt install nginx

По завершению исполнения команд, обновление и установка Nginx на сервере будет окончена.

Мониторинг nginx

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

nginx -V 2>&1 | grep -o with-http_stub_status_module

Если в ответ получили with-http_stub_status_module – модуль доступен. Рассмотрим включение мониторинга на примере виртуального хоста, открываем файл:

nano /etc/nginx/sites-available/sampledomain.ru.conf

Добавляем location /nginx_status, в итоге файл выглядит следующим образом:

server { listen 80; server_name sampledomain.ru www.sampledomain.ru; root /home/webuser/www/sampledomain.ru; return 301 https://sampledomain.ru$request_uri; }
server { listen 443 ssl; server_name sampledomain.ru www.sampledomain.ru; # SSL support ssl_certificate /etc/letsencrypt/live/sampledomain.ru/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/sampledomain.ru/privkey.pem; charset utf-8; root /home/webuser/www/sampledomain.ru; index index.php index.html index.htm; # Static content location ~* ^.+.(jpg|jpeg|gif|png|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|mp3|bmp|flv|rtf|js|swf|iso)$ { root /home/webuser/www/sampledomain.ru; expires 1d; } location ~ \.php$ { include fastcgi.conf; fastcgi_intercept_errors on; try_files $uri =404; fastcgi_pass unix://var/run/php/sampledomain.ru.sock; } location / { try_files $uri $uri/ /index.php?q=$uri$args; } location /nginx_status { stub_status on; access_log off; } }

Сохраняем результат Ctrl+O, подтверждаем нажатием ENTER, выходим из редактора Ctrl+X. Перезапускаем веб-сервер:

service nginx restart

В браузере при переходе по адресу sampledomain.ru/nginx_status будет представлена статистика работы сервера:

Active connections: 2
server accepts handled requests 797 797 334
Reading: 0 Writing: 1 Waiting: 1

• Active connections – текущее количество клиентских соединений;
• accepts – принятые соединения;
• handled – обработанные, обычно равно количеству принятых;
• requests – количество клиентских запросов;
• Reading – текущее количество соединений, для которых сервер читает заголовок запроса;
• Writing – текущее количество соединений, для которых сервер отправляет ответ клиенту;
• Waiting – текущее количество простаивающих соединений, для которых сервер ожидает запроса.

Также статистику можно получить из командной строки:

curl https://sampledomain.ru/nginx_status

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

Настройка брандмауэра

Установка и настройка брандмауэра позволит закрыть все порты, кроме необходимых нам — 22 (SSH), 80 (HTTP), 443 (HTTPS). Первый протокол необходим для подключения к удаленному серверу. Второй и третий необходим для связи между клиентом и сайтом. Главное их отличие в том, что HTTPS — это зашифрованный HTTP. Шифрование данных происходит благодаря SSL-сертификату.

Установим утилиту UFW:

sudo apt install ufw

После успешной установки добавим веб-сервер в список доступных приложений брандмауэра:

sudo nano /etc/ufw/applications.d/nginx.ini

Заполним файл следующим образом:

Проверим список доступных приложений:

sudo ufw app list

Если среди них есть веб-сервер, значит всё сделано верно. Теперь нужно запустить брандмауэр и разрешить передачу трафика по вышеуказанным портам:

sudo ufw enable
sudo ufw allow 'Nginx Full'
sudo ufw allow 'OpenSSH'

Чтобы проверить изменения, вводим команду:

sudo ufw status

Если всё сделано правильно, то в статусе будут перечислены все порты, которые нам необходимы.