Nginx конфигурационный файл. Тонкая настройка Nginx. Защита, оптимизация. Отключи показ версии сервера на всех ошибочных страницах

В этом руководстве даётся начальное введение в nginx и описываются некоторые простые задачи, которые могут быть решены с его помощью. Предполагается, что nginx уже установлен на компьютере читателя. Если нет, см. Установка nginx . В этом руководстве описывается, как запустить и остановить nginx и перезагрузить его конфигурацию, объясняется, как устроен конфигурационный файл, и описывается, как настроить nginx для раздачи статического содержимого, как настроить прокси-сервер на nginx, и как связать nginx с приложением FastCGI.

У nginx есть один главный и несколько рабочих процессов. Основная задача главного процесса - чтение и проверка конфигурации и управление рабочими процессами. Рабочие процессы выполняют фактическую обработку запросов. nginx использует модель, основанную на событиях, и зависящие от операционной системы механизмы для эффективного распределения запросов между рабочими процессами. Количество рабочих процессов задаётся в конфигурационном файле и может быть фиксированным для данной конфигурации или автоматически устанавливаться равным числу доступных процессорных ядер (см. worker_processes).

Как работают nginx и его модули, определяется в конфигурационном файле. По умолчанию, конфигурационный файл называется nginx.conf и расположен в каталоге /usr/local/nginx/conf , /etc/nginx или /usr/local/etc/nginx .

Запуск, остановка, перезагрузка конфигурации

Чтобы запустить nginx, нужно выполнить исполняемый файл. Когда nginx запущен, им можно управлять, вызывая исполняемый файл с параметром -s . Используйте следующий синтаксис:

nginx -s сигнал

Где сигнал может быть одним из нижеследующих:

  • stop - быстрое завершение
  • quit - плавное завершение
  • reopen - переоткрытие лог-файлов

Например, чтобы остановить процессы nginx с ожиданием окончания обслуживания текущих запросов рабочими процессами, можно выполнить следующую команду:

Команда должна быть выполнена под тем же пользователем, под которым был запущен nginx.

Изменения, сделанные в конфигурационном файле, не будут применены, пока команда перезагрузить конфигурацию не будет вручную отправлена nginx’у или он не будет перезапущен. Для перезагрузки конфигурации выполните:

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

Посылать сигналы процессам nginx можно также средствами Unix, такими как утилита kill . В этом случае сигнал отправляется напрямую процессу с данным ID. ID главного процесса nginx записывается по умолчанию в файл nginx.pid в каталоге /usr/local/nginx/logs или /var/run . Например, если ID главного процесса равен 1628, для отправки сигнала QUIT, который приведёт к плавному завершению nginx, нужно выполнить:

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

Дополнительную информацию об отправке сигналов процессам nginx можно найти в Управление nginx .

Структура конфигурационного файла

nginx состоит из модулей, которые настраиваются директивами, указанными в конфигурационном файле. Директивы делятся на простые и блочные. Простая директива состоит из имени и параметров, разделённых пробелами, и оканчивается точкой с запятой (;). Блочная директива устроена так же, как и простая директива, но вместо точки с запятой после имени и параметров следует набор дополнительных инструкций, помещённых внутри фигурных скобок ({ и }). Если у блочной директивы внутри фигурных скобок можно задавать другие директивы, то она называется контекстом (примеры: events , http , server и location).

Директивы, помещённые в конфигурационном файле вне любого контекста, считаются находящимися в контексте main . Директивы events и http располагаются в контексте main , server - в http , а location - в server .

Часть строки после символа # считается комментарием.

Раздача статического содержимого

Одна из важных задач конфигурации nginx - раздача файлов, таких как изображения или статические HTML-страницы. Рассмотрим пример, в котором в зависимости от запроса файлы будут раздаваться из разных локальных каталогов: /data/www , который содержит HTML-файлы, и /data/images , содержащий файлы с изображениями. Для этого потребуется отредактировать конфигурационный файл и настроить блок server внутри блока http с двумя блоками location .

Во-первых, создайте каталог /data/www и положите в него файл index.html с любым текстовым содержанием, а также создайте каталог /data/images и положите в него несколько файлов с изображениями.

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

В общем случае конфигурационный файл может содержать несколько блоков server , различаемых по портам, на которых они слушают , и по имени сервера . Определив, какой server будет обрабатывать запрос, nginx сравнивает URI, указанный в заголовке запроса, с параметрами директив location , определённых внутри блока server .

В блок server добавьте блок location следующего вида:

location / { root /data/www; }

Этот блок location задаёт “ / ” в качестве префикса, который сравнивается с URI из запроса. Для подходящих запросов добавлением URI к пути, указанному в директиве root , то есть, в данном случае, к /data/www , получается путь к запрашиваемому файлу в локальной файловой системе. Если есть совпадение с несколькими блоками location , nginx выбирает блок с самым длинным префиксом. В блоке location выше указан самый короткий префикс, длины один, и поэтому этот блок будет использован, только если не будет совпадения ни с одним из остальных блоков location .

location /images/ { root /data; }

Он будет давать совпадение с запросами, начинающимися с /images/ (location / для них тоже подходит, но указанный там префикс короче).

Итоговая конфигурация блока server должна выглядеть следующим образом:

server { location / { root /data/www; } location /images/ { root /data; } }

Это уже работающая конфигурация сервера, слушающего на стандартном порту 80 и доступного на локальном компьютере по адресу http://localhost/ . В ответ на запросы, URI которых начинаются с /images/ , сервер будет отправлять файлы из каталога /data/images . Например, на запрос http://localhost/images/example.png nginx отправит в ответ файл /data/images/example.png . Если же этот файл не существует, nginx отправит ответ, указывающий на ошибку 404. Запросы, URI которых не начинаются на /images/ , будут отображены на каталог /data/www . Например, в результате запроса http://localhost/some/example.html в ответ будет отправлен файл /data/www/some/example.html .

Чтобы применить новую конфигурацию, запустите nginx, если он ещё не запущен, или отправьте сигнал reload главному процессу nginx, выполнив:

В случае если что-то работает не как ожидалось, можно попытаться выяснить причину с помощью файлов access.log и error.log из каталога /usr/local/nginx/logs или /var/log/nginx .

Настройка простого прокси-сервера

Одним из частых применений nginx является использование его в качестве прокси-сервера, то есть сервера, который принимает запросы, перенаправляет их на проксируемые сервера, получает ответы от них и отправляет их клиенту.

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

Во-первых, создайте проксируемый сервер, добавив ещё один блок server в конфигурационный файл nginx со следующим содержимым:

server { listen 8080; root /data/up1; location / { } }

Это будет простой сервер, слушающий на порту 8080 (ранее директива listen не указывалась, потому что использовался стандартный порт 80) и отображающий все запросы на каталог /data/up1 в локальной файловой системе. Создайте этот каталог и положите в него файл index.html . Обратите внимание, что директива root помещена в контекст server . Такая директива root будет использована, когда директива location , выбранная для выполнения запроса, не содержит собственной директивы root .

Далее, используйте конфигурацию сервера из предыдущего раздела и видоизмените её, превратив в конфигурацию прокси-сервера. В первый блок location добавьте директиву proxy_pass , указав протокол, имя и порт проксируемого сервера в качестве параметра (в нашем случае это http://localhost:8080):

server { location / { proxy_pass http://localhost:8080; } location /images/ { root /data; } }

Мы изменим второй блок location , который на данный момент отображает запросы с префиксом /images/ на файлы из каталога /data/images так, чтобы он подходил для запросов изображений с типичными расширениями файлов. Изменённый блок location выглядит следующим образом:

location ~ \.(gif|jpg|png)$ { root /data/images; }

Параметром является регулярное выражение, дающее совпадение со всеми URI, оканчивающимися на.gif , .jpg или.png . Регулярному выражению должен предшествовать символ ~ . Соответствующие запросы будут отображены на каталог /data/images .

Когда nginx выбирает блок location , который будет обслуживать запрос, то вначале он проверяет директивы location , задающие префиксы, запоминая location с самым длинным подходящим префиксом, а затем проверяет регулярные выражения. Если есть совпадение с регулярным выражением, nginx выбирает соответствующий location , в противном случае берётся запомненный ранее location .

Итоговая конфигурация прокси-сервера выглядит следующим образом:

server { location / { proxy_pass http://localhost:8080/; } location ~ \.(gif|jpg|png)$ { root /data/images; } }

Этот сервер будет фильтровать запросы, оканчивающиеся на.gif , .jpg или.png , и отображать их на каталог /data/images (добавлением URI к параметру директивы root) и перенаправлять все остальные запросы на проксируемый сервер, сконфигурированный выше.

Чтобы применить новую конфигурацию, отправьте сигнал reload nginx’у, как описывалось в предыдущих разделах.

Существует множество других директив для дальнейшей настройки прокси-соединения.

Настройка проксирования FastCGI

nginx можно использовать для перенаправления запросов на FastCGI-серверы. На них могут исполняться приложения, созданные с использованием разнообразных фреймворков и языков программирования, например, PHP.

Базовая конфигурация nginx для работы с проксируемым FastCGI-сервером включает в себя использование директивы fastcgi_pass вместо директивы proxy_pass , и директив fastcgi_param для настройки параметров, передаваемых FastCGI-серверу. Представьте, что FastCGI-сервер доступен по адресу localhost:9000 . Взяв за основу конфигурацию прокси-сервера из предыдущего раздела, замените директиву proxy_pass на директиву fastcgi_pass и измените параметр на localhost:9000 . В PHP параметр SCRIPT_FILENAME используется для определения имени скрипта, а в параметре QUERY_STRING передаются параметры запроса. Получится следующая конфигурация:

server { location / { fastcgi_pass localhost:9000; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param QUERY_STRING $query_string; } location ~ \.(gif|jpg|png)$ { root /data/images; } }

Таким образом будет настроен сервер, который будет перенаправлять все запросы, кроме запросов статических изображений, на проксируемый сервер, работающий по адресу localhost:9000 , по протоколу FastCGI.

Будем работать под учетной записью обычного пользователя с sudo правами. Так же вам понадобится установленный веб-сервер Nginx. При желании можно установить полностью LEMP (Linux, Nginx, MySQL и PHP). Чтобы установить Nginx достаточно выполнить следующую команду:

Sudo apt-get update sudo apt-get install nginx

Прежде чем продолжить читать статью, настоятельно рекомендуем выполнить вышеописанные условия. Для примера, мы настроим два домена на нашем сервере. Их имена - example.com, test.com. Если в наличии у вас нет двух свободных имен, то просто придумайте два, а позднее мы покажем как настроить ваш локальный сервер, чтобы проверить их работоспособность.

Шаг 1 - настройка новой корневой директории

По-умолчанию на вашем Nginx сервере активирован только один виртуальный хост. Он работает с документами по адресу: /usr/share/nginx/html . Мы изменим эту настройку, так как чаще всего приходится работать с каталогом /var/www . Nginx не использует эту директорию по-умолчанию, так как это противоречит политике Debian по использованию пакетов в каталоге /var/www .

Но так как мы простые пользователи, и с вопросами хранения пакетов редко сталкиваемся, проигнорируем эту политику и установим этот каталог в качестве корневого. Точнее говоря, каждый каталог внутри корневой директории должен соответствовать отдельному сайту. А все файлы сайта разместим в директории /var/www/site_name/html . Сначала создадим все необходимые подкаталоги. Для этого выполним следующую команду:

Sudo mkdir -p /var/www/example.com/html sudo mkdir -p /var/www/test.com/html

Флаг -р указывает оболочке, чтобы она создавала новые каталоги если их не существует в указанном пути. Теперь передадим права на этот каталог обычному пользователю. Воспользуемся переменной окружения $USER , чтобы не вводить имя своего аккаунта. После этих действий мы сможем создавать в каталоге /var/www/ файлы, а посетители сайта - нет.

Sudo chown -R $USER:$USER /var/www/example.com/html sudo chown -R $USER:$USER /var/www/test.com/html

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

Sudo chmod -R 755 /var/www

Мы полностью подготовили структуру для нашего сервера, можем двигаться дальше.

Шаг 2 - Создаём шаблон страницы для каждого сайта

Давайте создадим страницу, которая будет отображаться по-умолчанию при создании нового сайта. Создайте файл index.html в каталоге первого домена:

Nano /var/www/example.com/html/index.html

Внутри сделаем минимальное наполнение, чтобы понимать на каком сайте мы находимся. Вот примерное содержание:

Добро пожаловать на Example.com!

Это виртуальный хост example.com!

Сохраните и закройте файл. Так как второй файл будет с похожим содержанием, просто скопируем его:

Cp /var/www/example.com/html/index.html /var/www/test.com/html/

Внесём в него небольшие изменения:

Nano /var/www/test.com/html/index.html Добро пожаловать на Test.com!

Это виртуальный хост test.com!

Сохраните и закройте этот файл. Теперь мы будем видеть правильно ли настроены наши сайты.

Шаг 3 - создание файлов виртуальных хостов для каждого домена

Теперь у нас есть содержимое для каждого сайта, настало время создать виртуальный хосты (точнее в Nginx они называются server block, но мы будет пользоваться термином виртуальный хост). По-умолчанию, Nginx использует один виртуальный хост под названием default . Используем его в качестве шаблона для нашей конфигурации. Сначала проработаем настройку для первого домена, которую потом просто скопируем и внесем минимальные изменения для второго домена.

Создание первого файла виртуального хоста

Как я уже сказал, скопируем файл настройки default :

Sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/example.com

Откроем этот файл с правами администратора:

Sudo nano /etc/nginx/sites-available/example.com

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

Server { listen 80 default_server; listen [::]:80 default_server ipv6only=on; root /usr/share/nginx/html; index index.html index.htm; server_name localhost; location / { try_files $uri $uri/ =404; } }

Для начала разберемся с директивой listen . Только одному блоку server мы можем установить значение default_server . Блок с таким значением будет обслуживать запросы, если не было найдено подходящего блока (блок - это всё что находится в server). Мы отключим эту директиву в виртуальном хосте default , чтобы использовать default_server на одном из наших доменов. Я оставлю эту функцию активированной для первого домена, но при желании вы можете её перенести на второй.

Следующее что мы сделаем - настроим корневой каталог при помощи директивы root . Она должна указывать на каталог, где лежат все документы вашего сайта:

Root /var/www/example.com/html;

Заметка : каждая инструкция Nginx должна заканчиваться символом “;”.

Server_name example.com www.example.com;

Server { listen 80 default_server; listen [::]:80 default_server ipv6only=on; root /var/www/example.com/html; index index.html index.htm; server_name example.com www.example.com; location / { try_files $uri $uri/ =404; } }

На этом базовая настройка окончена. Сохраните и закройте файл.

Создание второго виртуального хоста

Для этого просто скопируем файл настроек для первого сайта:

Sudo cp /etc/nginx/sites-available/example.com /etc/nginx/sites-available/test.com

Откройте этот файл с правами администратора

Sudo nano /etc/nginx/sites-available/test.com

В этом файле также начнем с директивы listen . Если опцию default_server вы оставили в первом файле, то здесь её следует удалить. Также необходимо убрать опцию ipv6only=on, так как её указывают только для одной комбинации адрес/порт:

Listen 80; listen [::]:80;

Установите корневой каталог для второго сайта:

Root /var/www/test.com/html;

Теперь укажем server_name для второго домена:

Server_name test.com www.test.com;

Окончательная настройка должна выглядеть следующим образом:

Server { listen 80; listen [::]:80; root /var/www/test.com/html; index index.html index.htm; server_name test.com www.test.com; location / { try_files $uri $uri/ =404; } }

Сохраните и закройте файл.

Шаг 4 - активация виртуальных хостов и перезапуск Nginx

Мы настроили наши виртуальные хосты, теперь настало время активировать их. Для этого надо создать символические ссылки на эти файлы и положить их в каталог sites-enabled , которые Nginx считывает при запуске. Создать ссылки можно следующей командой:

Sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/ sudo ln -s /etc/nginx/sites-available/test.com /etc/nginx/sites-enabled/

Теперь Nginx обработает эти файлы. Но виртуальный хост default , также активирован, поэтому мы получим конфликт параметра default_server . Отключить эту настройку можно просто удалив ссылку на файл. Сам файл останется в каталоге sites-available , так что при необходимости мы всегда сможем вернуть его на место.

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

Осталось ещё одна настройка, которую требуется выполнить в конфигурационном файле Nginx. Откройте его:

Sudo nano /etc/nginx/nginx.conf

Надо снять комментарий с одной из строк:

Server_names_hash_bucket_size: 64;

Эта директива применяется когда задано большое число имён серверов, либо заданы необычно длинные имена. Например, если значение по умолчанию равно 32 и имя сервера задано как “too.long.server.name.example.org”, то nginx откажется запускаться и выдаст сообщение об ошибке:

Could not build the server_names_hash, you should increase server_names_hash_bucket_size: 32

Поэтому лучше увеличить это значение до 64. Теперь можно перезапустить веб сервер, чтобы изменения вступили в силу:

Sudo service nginx restart

Ваш сервер теперь должен обрабатывать запросы к обоим доменам.

Шаг 5 - Настройка локального файла hosts (дополнительно)

Если вы использовали свои доменные имена, то необходимо настроить ваш локальный сервер, чтобы тот распознавал их и вы смогли бы проверить свои виртуальные хосты (будем прописывать свои доменные имена в локальный файл hosts). Конечно, интернет пользователи не смогут таким образом просматривать ваш сайт, но для проверки хостов этого будет достаточно. Таким образом мы перехватываем запрос, который должен быть отправлен DNS серверу. По идее мы указываем по какому ip адресу наш компьютер должен перейти при обращении к определенному доменному имени.

Обратите внимание, что эти изменения следует производить только на локальной машине, а не на VPS сервере. Вам понадобятся root права, также необходимо иметь право изменять системные файлы.

Если вы используете Mac или Linux систему, то исправления можно внести следующим образом:

Sudo nano /etc/hosts

Если же вы пользуетесь Windows, то инструкции по этой ОС вы найдете на официальном сайте производителя (или в google). Вам необходимо знать открытый IP адрес вашего сервера и доменные имена, которые вы хотите привязать к нему. Допустим мой адрес 111.111.111.111 , тогда мне надо добавить следующие строки в файл hosts:

127.0.0.1 localhost 127.0.0.1 guest-desktop 111.111.111.111 example.com 111.111.111.111 test.com

Таким образом мы перехватим все запросы к этим доменным именам и перенаправим их на наш сервер. Сохраните и закройте файл когда закончите.

Шаг 6 - Проверка

На данном этапе вы должны получить полностью рабочую настройку. Осталось только её проверить. Для этого перейдем в браузере по адресу: http://example.com { :target="_blank"} . Если оба сайта отображаются корректно, то вас можно поздравить с полной настройкой сервера Nginx. На этом этапе, если вы вносили изменения в файл hosts , то их следует удалить т.к. проверка прошла успешно и они уже не нужны. Чтобы открыть доступ к сайтам для интернет пользователей, придется приобрести доменные имена.

Заключение

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

|

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

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

Каждый раздел может использоваться независимо от других, поэтому вы можете пропустить разделы, которые вам не нужны. Все условные значения в командах выделены красным; вместо этих значений вы можете подставить свои данные.

Примечание : Предполагается, что вы работаете с версией Nginx, установленной из репозитория по умолчанию в Debian-подобном дистрибутиве. Некоторые из команд и директив, описанных в этом руководстве, отсутствуют в других дистрибутивах или в версиях Nginx, установленных из других источников.

Установка Nginx

Обновите индекс пакетов, а затем установите Nginx:

sudo apt-get update
sudo apt-get install nginx

Проверка состояния Nginx

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

sudo systemctl status nginx

Автозагрузка Nginx

По умолчанию сервис Nginx запускается автоматически. Если вы хотите изменить это поведение, введите:

sudo systemctl disable nginx

Чтобы снова добавить Nginx в автозагрузку, введите:

sudo systemctl enable nginx

Управление сервисом Nginx

Чтобы остановить сервер Nginx, введите следующую команду:

sudo systemctl stop nginx

Чтобы запустить сервер Nginx, введите:

sudo systemctl start nginx

Чтобы остановить сервис и запустить его снова, введите:

sudo systemctl restart nginx

Если вы изменили конфигурацию, вы можете перезагрузить Nginx в текущей сессии. Введите следующую команду:

sudo systemctl reload nginx

Создание корневого каталога для статического контента

При создании сайтов на Nginx разработчики часто используют виртуальные хосты (или блоки server) – это хосты, которые обслуживают отдельные сайты или домены. Для этого нужно создать document root, каталог верхнего уровня, который Nginx проверяет при обслуживании контента.

Команды в приведенном ниже блоке создадут новый корневой каталог, передадут права на него пользователю sudo и изменят права доступа к каждому подкаталогу в подкаталога в /var/www/.


sudo chown -R $USER:$USER /var/www/example.com/html
find /var/www -type d -exec chmod 775 {} \;

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

Помните, что права доступа должны меняться в соответствии с ситуацией.

Создание корневого каталога для динамических файлов

Если ваш сайт использует динамические модули типа PHP-FPM, вам может понадобиться передать права на некоторые файлы группе www-data. Если группе нужно право на запись в каталоге, передайте группе права собственности на каталог.

Предложенные ниже команды создают новый document root, передают его группе www-data и изменяют права на каждый подкаталог в /var/www.

sudo mkdir -p /var/www/example.com/html
sudo chown -R www-data:www-data /var/www/example.com
sudo find /var/www -type d -exec chmod 775 {} \;

Включение и отключение конфигурационных файлов

Чтобы включить виртуальный хост, нужно создать симлинк из каталога sites-available в каталог sites-enabled, который Nginx читает во время запуска.

Для этого введите комнаду:

sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/

После этого нужно перезагрузить Nginx, чтобы настройки обновились.

Устранение неполадок с хэш-таблицей

Nginx использует хэш-таблицы, чтобы быстро обрабатывать статические данные (имена серверов, MIME-типы). Если вы добавили несколько имен серверов, есть вероятность, что заданного размера хэша имени сервера будет не хватать, и при внесении изменений вы увидите ошибку server_names_hash_bucket_size. Ее можно устранить, отредактировав одно значение в файле /etc/nginx/nginx.conf.

Откройте этот файл:

sudo nano /etc/nginx/nginx.conf

Найдите в файле директиву server_names_hash_bucket_size. Удалите символ #, чтобы раскомментировать строку, и увеличьте значение директивы:

http {
. . .
server_names_hash_bucket_size 64 ;
. . .
}

Это увеличит размер хэш-таблиц имен серверов Nginx и позволит сервису обрабатывать все имена серверов, которые вы добавили. Сохраните и закройте файл, а затем перезапустите Nginx, чтобы обновить настройки.

Тестирование конфигурации

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

Если в конфигурации есть ошибки, вывод команды укажет, где именно они обнаружены. Если же в конфигурационных файлах нет синтаксических ошибок, вы увидите примерно такой вывод:

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

Если ошибок нет, вы можете перезагрузить сервис:

sudo systemctl restart nginx

Важные файлы и каталоги Nginx

Контент

Каталог /var/www/html хранит весь контент сайта (это корневой каталог сайта). Вы можете изменить стандартные настройки Nginx и указать другие каталоги в var/www.

Конфигурация сервера

  • /etc/nginx/: конфигурационный каталог Nginx (здесь хранятся все конфигурационные файлы веб-сервера).
  • /etc/nginx/nginx.conf: главный конфигурационный файл веб-сервера, в котором находятся все глобальные параметры.
  • /etc/nginx/sites-available/default: виртуальный хост Nginx по умолчанию. Другие виртуальные хосты также должны храниться в каталоге sites-available (но они не будут работать без симлинка в sites-enabled).
  • /etc/nginx/sites-enabled/: здесь хранятся файлы включенных виртуальных хостов. При запуске или перезагрузке Nginx читает конфигурационные файлы и ссылки в этом каталоге, чтобы собрать полную конфигурацию.

Логи

  • /var/log/nginx/access.log: это лог, который регистрирует все запросы Nginx (если в конфигурации веб-сервера не сказано другого).
  • /var/log/nginx/error.log: это лог ошибок.

Чтобы получить доступ к логам systemd процесса Nginx, запустите эту команду:

sudo journalctl -u nginx

Заключение

Данный мануал перечислил общие процедуры по поддержке сервера Nginx. Чтобы узнать больше о работе с Nginx, ознакомьтесь со следующими руководствами.

Tags:

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

В одной из предыдущих статей мы уже рассматривали и настройку его основных параметров, в этой же статье я хочу больше остановиться на производительности и подготовке веб-сервера к использованию в боевых условиях. Что касается дистрибутива Linux, то сегодня мы будем рассматривать CentOS, эта система часто используется на серверах и с настройкой Nginx тут могут возникнуть некоторые сложности. Дальше будет рассмотрена настройка Nginx CentOS, поговорим как включить полную поддержку http2, google pagespeed, и настроить основной конфигурационный файл.

В официальных репозиториях CentOS есть Nginx и он, скорее всего, уже установлен в вашей системе. Но мы хотим чтобы сайт работал по протоколу http2, который позволяет передавать все данные одним подключением, а это увеличивает производительность. Для работы по http2 вам понадобиться настроить SSL сертификат, но об этом уже написано в статье получение сертификата Lets Encrypt Nginx. Но это еще не все. для переключения с обычного SSL на HTTP2.0 в большинстве браузеров сейчас используется протокол ALPN, а он поддерживается начиная с OpenSSL 1.02. В то время, как в репозиториях есть только OpenSSL 1.01. Поэтому нам нужно установить версию Nginx, собранную с OpenSSL 1.02. Для этого можно использовать Broken Repo:

sudo yum -y install yum-utils
# sudo yum-config-manager --add-repo https://brouken.com/brouken.repo

Если вы используете репозиторий EPEL, то нужно указать что не надо из него брать Nginx:

sudo yum-config-manager --save --setopt=epel.exclude=nginx*;

Теперь для установки правильной версии Nginx достаточно набрать:

sudo yum install nginx

Будет установлена самая последняя версия Nginx 1.13.2, с полной поддержкой ALPN. Дальше перейдем к настройке.

2. Настройка Nginx

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

глобальные опции
events {}
http{
server {
location{}
}
server {}
}

Сначала идут глобальные опции, которые задают основные параметры программы, например, от какого пользователя она будет запущена и количество процессов. Дальше есть секция events , в которой описано как Nginx будет реагировать на входящие подключения, затем идет секция http , которая объединяет все настройки касаемо работы протокола http. В ней находится секция server , каждая такая секция отвечает за отдельный домен, в секции server размещаются секции location , каждая из которых отвечает за определенный URL запроса, обратите внимание, что не файл на сервере, как в Apache, а именно URL запроса.

Основные глобальные настройки мы будем делать в файле /etc/nginx/nginx.conf. Дальше рассмотрим что именно будем менять и какие значения желательно установить. Начнем с глобальных опций:

  • user - пользователь, от имени которого будет запущен сервер, должен быть владельцем каталога с файлами сайта, и от имени его же нужно запускать php-fpm;
  • worker_processes - количество процессов Nginx, которые будут запущены, нужно установить ровно столько, сколько у вас есть ядер, например, у меня - 4;
  • worker_cpu_affinity - этот параметр позволяет закрепить каждый процесс за отдельным ядром процессора, установите значение auto, чтобы программа сама выбрала что и к чему крепить;
  • worker_rlimit_nofile - максимальное количество файлов, которые может открыть программа, на каждое соединение нужно как минимум два файла и каждый процесс будет иметь указанное вами количество соединений, поэтому формула такая: worker_processes * worker_connections* 2, параметр worker_connections разберем чуть ниже;
  • pcre_jit - включите этот параметр для ускорения обработки регулярных выражений с помощью JIT компиляции;

В секции events стоит настроить два параметра:

  • worker_connections - количество соединений для одного процесса, должно быть достаточным для обработки входящих соединений. Сначала нам нужно знать сколько этих входящих соединений есть, для этого смотрим статистику по адресу ip_сервера/nginx_status. Как включить рассмотрим ниже. В строке Active Connections видим количество активных соединений с сервером, также нужно учесть что соединения с php-fpm тоже считаются. Дальше обратите внимание на поля accepted и handled, первое отображает обработанных подключений, второе - количество принятых. Из значения должны быть одинаковыми. Если отличаются значит соединений не хватает. Смотрите примеры, первый снимок проблема, второй - порядок. Для моей конфигурации оптимальной может быть цифра в 200 соединений (всего 800, учитывая 4 процесса):

  • multi_accept - позволяет программе принимать несколько соединений одновременно, тоже ускоряет работу, при большом количестве соединений;
  • accept_mutex - установите значение этого параметра в off, чтобы сразу все процессы получали уведомление про новые соединения;

Также в секции events рекомендуется использовать директиву use epoll, так как этот самый эффективный метод обработки входящих соединений для Linux, но этот метод применяется по умолчанию, поэтому не вижу смысла добавлять его вручную. Рассмотрим еще несколько параметров из секции http:

  • sendfile - использовать метод отправки данных sendfile. Самый эффективный метод для Linux.
  • tcp_nodelay, tcp_nopush - отправляет заголовки и тело запроса одним пакетом, работает немного быстрее;
  • keepalive_timeout - таймаут поддержания соединения с клиентом, если у вас нет очень медленных скриптов, то будет достаточно будет 10 секунд, устанавливаем значение сколько нужно чтобы пользователь мог быть подключен к серверу;
  • reset_timedout_connection - разрывать соединения после таймаута.
  • open_file_cache - кэшировать информацию об открытых файлах. Например, open_file_cache max=200000 inactive=120s; max - максимальное количество файлов в кэше, время кэширования.
  • open_file_cache_valid - когда нужно проверить актуальность файлов. Например: open_file_cache_valid 120s;
  • open_file_cache_min_uses - кэшировать только файлы, которые были открыты указанное количество раз;
  • open_file_cache_errors - запоминать ошибки открытия файлов.
  • if_modified_since - устанавливает каким образом будут обрабатываться заголовки if-modified-since. С помощью этого заголовка браузер может получить ответ 304 если страница не изменилась с момента последнего просмотра. Возможны варианты - не отправлять - off, отправлять при точном совпадении времени - exact, отправлять если время совпадает точно или больше - before;

Вот как-то так будет выглядеть настройка nginx conf:

User nginx;
worker_processes 4;
worker_cpu_affinity auto;
worker_rlimit_nofile 10000;
pcre_jit on;
error_log /var/log/nginx/error.log warn;
load_module "modules/ngx_pagespeed.so";
events {
multi_accept on;
accept_mutex off;
worker_connections 1024;
}
http {
sendfile on;
tcp_nopush on;
tcp_nodelay on;
open_file_cache max=200000 inactive=20s;
open_file_cache_valid 120s;
open_file_cache_errors on;
reset_timedout_connection on;
client_body_timeout 10;
keepalive_timeout 65;
include /etc/nginx/sites-enabled.*.conf
}

3. Настройка http2

Я не буду подробно описывать настройку секции server, потому что делал это уже в статье установка Nginx в Ubuntu и здесь мне нечего добавить, настройка SSL это достаточно обширная тема и тоже будет рассмотрена в отдельной статье. Но чтобы настроить http2 вам нужно иметь уже SSL. Далее, просто подправьте директиву listen в вашей секции server:

listen 194.67.215.125:443 default_server;

listen 194.67.215.125:443 http2 default_server;

Вот таким простым способом можно включить http2 если перед этим была установлена правильная версия Nginx.

4. Настройка PageSpeed

Google Pagespeed - это модуль Nginx, который выполняет различные оптимизации для того, чтобы страницы грузились быстрее, веб-сервер работал эффективнее, а пользователи не чувствовали дискомфорта. Сюда входит кэширование, оптимизация html кода, оптимизация картинок, объединение javascript и css кода и многое другое. Все это выполняется на уровне Nginx, поэтому эффективнее, чем если бы вы это делали в php. Но тут есть один недостаток, модуль удаляет заголовок Last Modified.

Дело в том, что PageSpeed устанавливает очень долгий строк кэширования для всех файлов, а в имя файла добавляет его хэш. Так скорость загрузки ресурсов выходит намного выше, поскольку браузер будет запрашивать файлы только с новым хэшем, а LastModified удаляется чтобы пользователи смогли увидеть изменения в случае если какой-либо файл будет изменен. А теперь рассмотрим как установить модуль. Нам придется собрать его из исходных кодов.

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

yum install wget gcc cmake unzip gcc-c++ pcre-devel zlib-devel

Скачайте и распакуйте исходники Nginx для вашей версии, например, 1.13.3:

wget -c https://nginx.org/download/nginx-1.13.3.tar.gz
# tar -xzvf nginx-1.13.3.tar.gz

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

wget -c https://github.com/pagespeed/ngx_pagespeed/archive/v1.12.34.2-stable.zip
# unzip v1.12.34.2-stable.zip

Скачайте и распакуйте библиотеку оптимизации PageSpeed в папку с исходниками модуля:

cd ngx_pagespeed-1.12.34.2-stable/
# wget -c https://dl.google.com/dl/page-speed/psol/1.12.34.2-x64.tar.gz
# tar -xvzf 1.12.34.2-x64.tar.gz

Скачайте и распакуйте исходники OpenSSL 1.02:

wget -c https://www.openssl.org/source/openssl-1.0.2k.tar.gz -O /opt/lib/$OPENSSL.tar.gz
# tar xvpzf openssl-1.0.2k.tar.gz

Теперь нам нужно собрать модуль. Сначала смотрим опции, с которыми собран текущий Nginx:

А теперь переходим в папку с Nginx, подставляем все полученные опции, опцию --add-dynamic-module для PageSpeed, OpenSSL и пробуем собрать:

cd nginx-1.13.3
# ./configure --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt="-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic" --with-ld-opt= --with-openssl=$HOME/openssl-1.0.2k --add-dynamic-module=$HOME/ngx_pagespeed-1.12.34.2-stable ${PS_NGX_EXTRA_FLAGS}
# make

Если все было сделано правильно, то на выходе вы получите модуль ngx_pagespeed.so в папке obj, его нужно скопировать в папку /etc/nginx/modules:

cp ngx_pagespeed.so /etc/nginx/modules/ngx_pagespeed.so

Создаем папку для кэша:

mkdir -p /var/ngx_pagespeed_cache
# chown -R nginx:nginx /var/ngx_pagespeed_cache

Теперь добавьте такую строчку для включения модуля в /etc/nginx/nginx.conf:

load_module "modules/ngx_pagespeed.so";

Один из самых популярных веб-серверов

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

Иерархия каталогов

Все конфигурационные файлы сервера располагаются в каталоге /etc/nginx. Кроме того, внутри директории расположены еще несколько папок, а также модульные конфигурационные файлы.

cd /etc/nginx
ls -F
conf.d/ koi-win naxsi.rules scgi_params uwsgi_params
fastcgi_params mime.types nginx.conf sites-available/ win-utf
koi-utf naxsi_core.rules proxy_params sites-enabled/

Если вы пользовались Apache, то должны быть знакомы с каталогами sites-enabled и sites-available. Они и определяют конфигурацию сайтов. Созданные файлы хранятся в последнем каталоге. Папка sites-enabled нужна для хранения конфигураций только активированных страниц. Чтобы их связать, нужна символическая ссылка между папками. Конфигурации можно также хранить в каталоге conf.d. При этом, во время запуска Nginx каждый файл с расширением.conf будет читаться по новой. При написании конфигурационных файлов, набирайте код без ошибок и соблюдайте синтаксис. Все остальные файлы располагаются в /etc/nginx. Конфигуратор содержит сведения о конкретных процессах, а также дополнительных компонентах.

Главный конфигурационный файл Nginx - это nginx.conf.

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

sudo nano /etc/nginx/nginx.conf

На экране появятся вот такие строки:

user www-data;
worker_processes 4;
pid /var/run/nginx.pid;
events {
worker_connections 768;
# multi_accept on;
}
http {
. . .

Первая - это общие сведения о Nginx. Фраза user www-data указывает на пользователя, который запускает сервер. Директива pid показывает, где располагаются PID-процессы, предназначенные для внутреннего использования. Строчка worker_processes показывает сколько процессов может одновременно запускать Nginx. Кроме того, здесь можно указать логи (например, лог ошибок определяется за счет директивы error_log). Ниже располагается раздел events. Он нужен для обработки соединений сервера. После него располагается блок http.

Структура конфигурационного файла Nginx

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

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

gzip on;
gzip_disable "msie6";

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

Последними строками файла nginx.conf выступают:

include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;

Они свидетельствуют о том, что блоки location и server хранятся вне данного файла. Они определяют настройки url-адресов и конкретных файлов. Такая структура необходима для поддерживания модульной структуры конфигураций. Внутри нее получится создавать новые директории, файлы для различный сайтов. Кроме того, похожие файлы вы сможете сгруппировать. После рассмотрения вы можете закрывать файл nginx.conf.

Виртуальные блоки

Они являются аналогами виртуальных хостов в Apache. Блоки раздела server включают в себя характеристики отдельных сайтов, которые располагаются на сервере. В папке sites-available вы найдете файл блока server, который применяется по умолчанию. Внутри него можно найти вне нужные данные, которые могут потребоваться при обслуживании сайтов.

cd sites-available
sudo nano default
server {
root /usr/share/nginx/www;
index index.html index.htm;
server_name localhost;
location / {
try_files $uri $uri/ /index.html;
}
location /doc/ {
alias /usr/share/doc/;
autoindex on;
allow 127.0.0.1;
deny all;
}
}

В вышеуказанном примере было намеренно убрано комментирование. Это было сделано для удобства восприятия. Внутри блоки server располагаются настройки, заключенные в фигурные скобки:

Этот блок размещается с помощью директивы include в конце http, прописанном в файле nginx.conf. Посредством директивы root определяется каталог, где будет располагаться контент сайта. В нем программа и будет искать файлы, которые пользователь будет запрашивать. Путь такой по умолчанию: /usr/share/nginx/www. Nginx отделяет строчки или директивы одна от другой посредством точки с запятой. Если знак препинания не проставить, несколько строчек прочтуться как одна. Чтобы прописать правила, которые будут использоваться в качестве индекса, воспользуйтесь директивой index. Сервер проверит их в порядке перечисления. Если ни одна из имеющихся страничек не была запрошена пользователем, вернется index.html. Если его не будет, то сервер будет искать index.htm.

Правило server_name

Она включает в себя список доменных имен, которые должен будет обработать блок server. Их можно прописать любое количество, разделяя пробелами. Если поставить * в конце или начале домена, удастся задать имя с маской. Звездочка соответствует части имени. Если прописать *.com.ua, то сюда будут относиться все адреса указанной доменной зоны. Если адрес подходит под описание нескольких директив, то он ответит той, которой подходит полностью. При отсутствии совпадений ответ будет на самое длинное имя, у которого есть маска. В противном случае будет выполнено соответствие регулярным выражениям. Имена сервера, которые используют регулярные выражения, начинаются с тильды (~).

Location-блоки

Следующий на очереди у нас будет блок location. Он нужен для определения способа обработки определенных запросов. Если ресурсы не соответствуют никаким иным блокам location, то к ним будут применяться директивы, указанные в скобках. Эти блоки могут включать путь вроде /doc/. Для установления полного соответствия между uri и location, применяется знак =. Применяя тильду, получится задать соответствие регулярным выражениям. Вы также можете установить чувствительность к регистру, поставив ~. Если добавить звездочку, регистр не будет играть никакой роли.

Имейте ввиду: когда запрос будет полностью соответствовать блоку location, он будет использован, а поиск остановится. Когда совпадение неполное, URI будет сравниваться с параметрами директив location. Используется блок с сочетанием ^~, совпадающий с URI для выбора блока. Если данную опцию не задействовать, сервер выбирает оптимальное совпадение, а также произведет поиск с использованием регулярных выражений. Это необходимо для подбора одного из подходящих шаблонов. Если подходящее выражение будет найдено, оно будет использовано. В противном случае, применится предыдущее совпадение с URI. Однако имейте ввиду, что Nginx больше любит полные соответствия. Если их нет, начнется поиск регулярных выражений, а потом по URI. Паритетность поиска задается комбинацией символов ^~.

Правило try_files

Это весьма полезный инструмент, способный проверять наличие файлов в установленном порядке. Он применяет первый соответствующий критериям для обработки запроса. Вы можете использовать дополнительные параметры, чтобы задать, каким образом сервер обслужит запросы. В конфигураторе есть вот такая строка по умолчанию:

try_files $uri $uri/ /index.html;

Что же она означает? Если поступает запрос, который обслуживается блоком location, сервер сначала попытается обработать uri как файл. Это обеспечивает переменная $uri. Когда соответствий ей не будет, uri будет обработан как каталог. Можно проверить его существование, задав слеш в конце: $uri/. Бывают ситуации, когда ни файл, ни каталог не будет найден. В таком случае загрузится файл по умолчанию - index.html. Правило try_files применяет последний параметр как запасной вариант. Именно поэтому данный файл должен быть в системе. Однако, если совпадений вообще не найдено, Nginx вернет страничку ошибки. Чтобы ее задать, пропишите = и код ошибки:

Дополнительные опции

Если применить правило alias, получится обслужить страницы блока location вне каталога root, например. Когда нужны файлы из doc, они будут запрошены из /usr/share/doc/. Кроме того, правило autoindеx on запускает листинг директорий сервера, для указанной директивы location. Если прописать строки deny и allow, получится изменить доступ к каталогам.

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

Похожие публикации
© 2024 Компьютерные подсказки для начинающих