Настройка и конфигурация Nginx.
Сегодня я хочу поговорить о настройке веб сервера Nginx, установка которого была описана в предыдущей статье.
Функционирование nginx определяется конфигурационным файлом nginx.conf, находящимся в директории /etc/nginx. Nginx состоит из модулей, модули настраиваются директивами, директивы указываются в конфигурационном файле. Директивы могут быть простыми или блочными.
Простая директива состоит из имени и указанного рядом с ним параметра, имя и параметр разделяются между собой пробелом, в конце директивы ставится точка с запятой. Блочная директива устроена так же как и простая, но вместо точки с запятой, после имени и параметра идет набор дополнительных функций, помещенных внутри фигурных скобок <>.
Если в блочной директиве внутри фигурных скобок заданы другие директивы, то она называется контекстом, примерами могут служить: events, http, server, location.
Директивы расположенные вне любого контекста считаются принадлежащими контексту main. Контексты events и http всегда должны находиться внутри контекста main. Контекст server должен находиться внутри контекста http, а location внутри контекста server.
Строка начинающаяся с символа «#» является комментарием и не выполняется сервером, такие сроки используются для пояснения написанного.
Файл nginx.conf создаваемый по умолчанию, можно смело удалять, проще написать свой, чем править существующий.
Начинаем писать свою конфигурацию.
Контекст main
Укажем пользователя от имени которого будет работать сервер. При установке сервера был создан пользователь nginx, он и будет основным пользователем.
Определим число worker_processes или другими словами, рабочих процессов. Число процессов должно равняться числу процессорных ядер, хотя для последних версий nginx данный параметр рекомендуют устанавливать в значение auto. Поскольку на моем недорогом VPS/VDS сервере доступно одно ядро, то я устанавливаю значение равное единице.
Указываем местонахождение pid-файла и лог-файла ошибок. Отмечаться будут только ошибки критического уровня, другими словами фиксация ошибок практически прекращается, в логах будут только события связанные со стартом или перезагрузкой сервера. Чем меньше производится записей в лог-файлы, тем меньше нагрузка на сервер.
Контекст events
Директива worker_connections устанавливает максимальное количество возможных соединений для одного рабочего процесса, сюда входят все соединения, а не только соединения с клиентами.
Верхний предел количества процессов для одного пользователя можно узнать при помощи команды ulimit, просмотрев ограничения ядра операционной системы.
Значение скорее всего будет равно 1024, это значение можно задать для worker_connections.
Директива use задает метод обработки соединений, в Linux следует использовать метод epoll. Включение multi_accept позволяет принимать максимально возможное количество соединений.
Контекст http
Отдельно разберем директиву include подключающую в конфигурацию дополнительные файл или файлы. Рассмотрим несколько примеров чтобы понять как она работает.
Для включения в конфигурацию отдельного файла, например test.conf, нужно указать имя файла и каталог в котором он находится.
Для включения всех файлов из каталога, должен быть указан каталог и символ «*«, теперь все файлы из указанного каталога будут включены в конфигурацию.
Можно подключить только определенный вид файлов, например имеющих расширение «.conf», для этого нужно указать «*.conf».
Продолжаем писать конфигурацию и подключаем файл с MIME-типами данных. Данный файл содержит список MIME заголовков и расширений передающихся по сети в соответствии со стандартом MIME. По умолчанию файл mime.types находится в директории /etc/nginx, поэтому в include достаточно просто указать имя файла.
Задаем MIME-тип ответов по умолчанию.
Добавим системный вызов sendfile. Системный вызов активирует передачу данных между файловыми дескрипторами посредством ядра, а не при помощи связки read + write. Sendfile позволяет отправлять данные сразу в сеть, минуя процесс их копирования и тем самым повышая производительность.
Сразу добавим sendfile_max_chunk, для ограничения объема данных могущих передаваться за один вызов sendfile. Если этого не сделать, то одно соединение может подмять под себя весь рабочий процесс.
Поскольку sendfile активирована, то в таком случае нужно добавить tcp_nopush, директива позволяет передавать заголовок ответа и начало файла одним пакетом.
Отключаем буферизацию соединений перешедших в состояние keep-alive.
Установим временной промежуток в течении которого keep-alive соединение с клиентом не будет закрыто, если пользователь перестал отвечать. Поддерживая неактивное keep-alive соединение, мы тем самым занимаем соединение, которое может использоваться по другому.
Зададим максимальное число запросов для одного keep-alive соединения. После достижения максимального числа запросов соединение будет закрыто.
reset_timedout_connection закрывает подключения для переставших отвечать клиентов.
Установим временной промежуток для передачи ответа клиента. Если по истечении времени клиент не ответит, то соединение будет закрыто.
Зададим размер буфера для заголовка запроса от клиента.
Буферы выделяются по мере необходимости. Если по окончанию обработки запроса соединение переходит в состояние keep-alive буферы освобождаются. Может использоваться для защиты от различных ботов или DoS-атак.
Директивой client_body_buffer_size установим размер буфера для чтения тела запроса клиента.
client_max_body_size задает размер тела запроса клиента и ограничивает максимальный размер файла, который можно загрузить на сервер посредством PHP.
Для снижения нагрузки отключаем запись событий в логах доступа на уровне сервера.
В качестве меры защиты можно отключить вывод версии сервера в заголовках ответов и на страницах ошибок.
Укажем каталог в котором будут находиться конфигурационные файлы сайтов.
Подводя итог статьи, привожу готовый файл nginx.conf.
О конфигурационных файлах сайтов мы поговорим в следующей статье, в которой будет рассмотрена дальнейшая настройка Nginx для WordPress-сайта.
Установка и первичная настройка Nginx
Введение
Хоть Nginx и не был самым первым веб-сервером в мире, сейчас он крайне популярен и используется в проектах, ориентированных на большой поток пользователей. Nginx спроектирован и создан специально для того, чтобы «держать» большие нагрузки. В отличии от Apache, в Nginx рабочие процессы обслуживают одновременно множество соединений, мультиплексируя их вызовами операционной системы, что обеспечивает низкое потребление серверных ресурсов.
Технические требования
Шаг 1. Установка Nginx
Перед тем, как мы начнём устанавливать Nginx, стоит установить последние обновления ОС:
После этого можно приступать к установке Nginx:
Консоль выведет список устанавливаемых пакетов, а так же их объём. Нажмите Y и Enter, чтобы продолжить, после чего apt-get установит Nginx и все необходимые зависимости.
Шаг 2. Проверка веб-сервера
После установки веб-сервера Ubuntu автоматически запустит его на 80 порту. Проверить, запустился ли Nginx можно следующей командой:
На этом установка Nginx завершена.
Конфигурационные файлы веб-сервера
Рассмотрим расположение файлов и настройки, установленные по умолчанию в Nginx.
Конфигурация, файлы и папки Nginx
После установки все конфигурации и папки Nginx устанавливаются в папку:
Общая конфигурация Nginx находится в файле:
Конфигурация вашего веб-сайта будет храниться в папке:
Логи
Логи ошибок в работе веб-сервера хранятся в файле:
Логи http-запросов к веб-серверу хранятся в файле:
Директория с файлами веб-сайта
По умолчанию, данные вашего веб-сайта расположены в папке:
Изменение конфигурации
Откроем файл конфигурации вашего веб-сайта, находящегося в директории:
Там вы увидите много строк. Советую почистить конфиг для удобочитаемости, удалив все строки, начинающиеся с символа #. Этот символ обозначает комментарий и значит, что весь идущий после него код в строке не имеет никакой силы. После небольшой очистки конфиг выглядит следующим образом:
Управление работой Nginx
В случае, когда вам нужно будет что-либо перенастроить или исправить, Nginx придётся останавливать. А если вы совершаете правки в конфигурационном файле, то для применения изменений веб-сервер следует перезагрузить. Для этого предусмотрены следующие команды:
Остановка Nginx
Запуск Nginx
Перезагрузка Nginx
Nginx Reload
* команда подхватывает изменения конфигурационных файлов без необходимости перезагружать веб-сервер.
После изменения конфигурационных файлов веб-сайта не забывайте проверять их валидность:
Заключение
Вы установили производительный веб-сервер Nginx и разобрались в базовых принципах его работы. В случае, если одного лишь наличия веб-сервера вам недостаточно, можете почитать статью о том, как настроить LEMP(Linux, Nginx, MySQL, PHP).
Nginx расположение файла конфигурации
Настройка веб-сервера Nginx
Один из самых популярных веб-серверов
Nginx пользуется большой популярностью среди пользователей веб- и прокси-серверов благодаря своей производительности. Сервер имеет много преимуществ, но настроить его будет сложно для новичка. Мы хотим вам помочь разобраться с конфигурационными файлами, синтаксисом, а также настройкой основных параметров Nginx.
Иерархия каталогов
Все конфигурационные файлы сервера располагаются в каталоге /etc/nginx. Кроме того, внутри директории расположены еще несколько папок, а также модульные конфигурационные файлы.
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/
Главный конфигурационный файл Nginx – это nginx.conf.
Он считывает все конфигурационные файлы, объединяя их в один, запрашиваемый при запуске сервера. Откройте файл с помощью:
На экране появятся вот такие строки:
Первая – это общие сведения о Nginx. Фраза user www-data указывает на пользователя, который запускает сервер. Директива pid показывает, где располагаются PID-процессы, предназначенные для внутреннего использования. Строчка worker_processes показывает сколько процессов может одновременно запускать Nginx. Кроме того, здесь можно указать логи (например, лог ошибок определяется за счет директивы error_log). Ниже располагается раздел events. Он нужен для обработки соединений сервера. После него располагается блок http.
Структура конфигурационного файла Nginx
Понимание структуры форматирования файла поможет вам лучше разобраться с конфигурацией веб-сервера. Она делится на структурные блоки. Детали конфигурации блока http разделены на уровни посредством закрытых блоков. Они наследуют свойства из родительского, т.е. того, в котором располагаются. Данный блок хранит большую часть конфигураций сервера. Они делятся на блоки server, внутри которых расположены location.
Когда вы настраиваете сервер Nginx, помните, что чем ниже располагается блок конфигурации, тем меньше элементов будут наследовать свойства и наоборот. В файле присутствует большое количество опций, меняющих работу сервера. Вы можете установить сжатие файлов отправляющихся клиенту, например. Для этого пропишите параметры:
Имейте ввиду, что один и тот же параметр может принимать разные значения в различных блоках. Сначала задайте его вверху, в потом переопределите параметр на нужном уровне. Если последнее действие не выполнить, программа задаст значения в автоматическом режиме.
Последними строками файла 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 располагаются настройки, заключенные в фигурные скобки:
Этот блок размещается с помощью директивы 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
Это весьма полезный инструмент, способный проверять наличие файлов в установленном порядке. Он применяет первый соответствующий критериям для обработки запроса. Вы можете использовать дополнительные параметры, чтобы задать, каким образом сервер обслужит запросы. В конфигураторе есть вот такая строка по умолчанию:
Дополнительные опции
Если применить правило alias, получится обслужить страницы блока location вне каталога root, например. Когда нужны файлы из doc, они будут запрошены из /usr/share/doc/. Кроме того, правило autoindеx on запускает листинг директорий сервера, для указанной директивы location. Если прописать строки deny и allow, получится изменить доступ к каталогам.
В качестве заключения стоит сказать, что Nginx – это очень мощный многофункциональный инструмент. Но чтобы разобраться хорошо с принципом его работы, потребуются время и усилия. Если понять работу конфигураций, вы сможете в полной мере наслаждаться всеми возможностями программы.
Настройка веб-сервера Nginx
Nginx – это популярный и производительный веб-сервер и обратный прокси-сервер.
У Nginx много преимуществ, однако его настройки достаточно сложные и не всегда понятны новичкам. Данное руководство поможет разобраться с основными параметрами, синтаксисом и конфигурационными файлами Nginx.
Примечание: Руководство выполнено на Ubuntu 12.04.
Иерархия каталогов Nginx
Nginx хранит конфигурационные файлы в каталоге /etc/nginx.
В этом каталоге находится ещё несколько каталогов и модульных конфигурационных файлов.
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-available и sites-enabled. Эти каталоги определяют конфигурации сайтов. Файлы обычно создаются и хранятся в sites-available; в sites-enabled хранятся только конфигурации включенных сайтов. Для этого нужно создать символическую ссылку из sites-available в sites-enabled.
Почти все оставшиеся файлы хранятся в /etc/nginx, который содержит сведения о конфигурации конкретных процессов или дополнительных компонентов.
Главным конфигурационным файлом Nginx является nginx.conf.
Файл nginx.conf
Файл nginx.conf читает соответствующие конфигурационные файлы и объединяет их в единый файл конфигурации при запуске сервера.
sudo nano /etc/nginx/nginx.conf
Первые строки задают общие сведения о Nginx. Строка user www-data указывает пользователя, с помощью которого запускается сервер.
Директива pid указывает, где будут храниться PID процессов для внутреннего использования. Строка worker_processes определяет количество процессов, которое может одновременно поддерживать Nginx.
Также в этой части файла можно указать логи (например, лог ошибок определяется с помощью директивы error_log).
За общими сведениями о сервере следует раздел events. Он управляет обработкой соединений Nginx. За ним идёт блок http. Прежде чем продолжить ознакомление с конфигурациями веб-сервера, нужно понять, как отформатирован конфигурационный файл Nginx.
Структура конфигурационного файла Nginx
Конфигурационный файл Nginx делится на блоки.
Первый блок – events, за ним идёт http и начинается главная иерархия конфигураций.
Детали конфигурации блока http делятся на уровни при помощи закрытых блоков, которые наследуют свойства из блока, в котором они расположены. В блоке http хранится большая часть общих конфигураций Nginx, которые делятся на блоки server, которые, в свою очередь, делятся на блоки location.
Во время настройки Nginx важно помнить следующее правило: чем выше уровень конфигурации, тем больше блоков наследует эту конфигурацию; чем ниже уровень конфигурации, тем она «индивидуальнее». То есть, если параметр Х должен применяться в каждом блоке server, то такой параметр нужно поместить в блок http.
Если вы внимательно рассмотрите файл, вы заметите, что он содержит много опций, которые определяют поведение программы как единого целого.
Например, чтобы настроить сжатие файлов, нужно установить такие параметры:
gzip on;
gzip_disable «msie6»;
Это включит поддержку gzip для сжатия отправляемых клиенту данных и отключит gzip для Internet Explorer 6 (поскольку этот браузер не поддерживает сжатия данных).
Если какой-либо параметр должен иметь разное значение в нескольких блоках server, то такой параметр можно задать на высшем уровне, а затем переопределить его внутри самих блоков server. В результате Nginx выполнит параметр низшего уровня.
Такое разбиение конфигураций на уровни позволяет избежать необходимости управлять несколькими идентичными файлами. Кроме того, если вы забыли определить параметры на низшем уровне, Nginx просто выполнит параметры по умолчанию.
Блок http в файле nginx.conf заканчивается так:
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
Это говорит о том, что блоки server и location, которые определяют настройки конкретных сайтов и URL-адресов, будут храниться за пределами этого файла.
Это позволяет поддерживать модульную архитектуру конфигураций, в которой можно создавать новые файлы для обслуживания новых сайтов. Также это позволяет группировать похожие файлы.
Закройте файл nginx.conf. Теперь нужно изучить настройки отдельных сайтов.
Виртуальные блоки Nginx
Блоки server в Nginx являются аналогом виртуальных хостов Apache (но для удобства их тоже принято называть виртуальными хостами). По сути, блоки server – это технические характеристики отдельных веб-сайтов, размещённых на одном сервере.
В каталоге sites-available можно найти файл блока server по умолчанию, который поставляется вместе с сервером. Этот файл содержит все необходимые данные для обслуживания сайта.
cd sites-available
sudo nano default
root /usr/share/nginx/www;
index index.html index.htm;
server_name localhost;
location / <
alias /usr/share/doc/;
autoindex on;
allow 127.0.0.1;
deny all;
Файл по умолчанию очень хорошо закомментирован, но в примере выше комментарии опущены для простоты и удобства.
Блок server включает в себя все настройки, помещённые между фигурными скобками:
Этот блок размещён в файле nginx.conf ближе к концу блока http с помощью директивы include.
Директива root определяет каталог, в котором будет храниться контент сайта. В этом каталоге Nginx будет искать запрашиваемые пользователем файлы. По умолчанию это каталог /usr/share/nginx/www.
Обратите внимание: все строки заканчиваются точкой с запятой. Так Nginx отделяет одну директиву от другой. Если точки с запятой не будет, Nginx прочитает две директивы (или несколько директив) как одну директиву с дополнительными аргументами.
Директива index определяет файлы, которые будут использоваться в качестве индекса. Веб-сервер будет проверять файлы в порядке их перечисления. Если ни одна страница не была запрошена, блок server найдёт и вернёт файл index.html. Если он не сможет найти этот файл, он попытается обработать index.htm.
Директива server_name
Директива server_name содержит список доменных имен, которые будут обслуживаться этим блоком server. Количество доменов неограниченно; домены в списке следует разделять пробелами.
Символ звёздочки (*) в начале или конце домена задаёт имя с маской, где звёздочка соответствует части (или нескольким частям) имени. Например, имя *.example.com будет соответствовать именам forum.example.com и www.animals.example.com.
Если запрашиваемый url-адрес соответствует нескольким директивам server_name, он сначала ответит той, с которой совпадает полностью.
Если адрес не обнаружит совпадений, он будет искать самое длинное имя с маской, которое заканчивается звездочкой. Если он не найдёт такого имени, он вернёт первое соответствие с регулярными выражениями.
Имена сервера, которые используют регулярные выражения, начинаются с тильды (
). К сожалению, данная тема выходит за рамки данной статьи.
Блоки location
Далее в конфигурационном файле находится блок location. Такие блоки определяют, как обрабатываются определённые запросы.
Строка location / указывает, что директивы в скобках будут применяться ко всем запрашиваемым ресурсам, которые не соответствуют никаким другим блокам location.
Такие блоки могут содержать uri путь (например /doc/). Чтобы установить полное соответствие между location и uri, используется символ =. Символ
устанавливает соответствие с регулярными выражениями.
Тильда включает чувствительный к регистру режим, а тильда со звёздочкой – регистронезависимый режим.
Если запрос полностью соответствует блоку location, то сервер останавливает поиск и использует такой блок. Если сервер не находит полностью подходящего блока location, он сравнивает URI с параметрами директив location. Nginx выберет блок, в котором используется сочетание символов ^
и который совпадает с URI.
не используется, Nginx выберет наиболее близкое совпадение и выполнит поиск по регулярным выражениям, чтобы попробовать подобрать один из доступных шаблонов. Если он найдёт такое выражение, то он использует его. Если такого выражения нет, то сервер использует найденное ранее совпадение с URI.
В качестве заключения следует отметить, что Nginx предпочитает точные соответствия. Если таких соответствий нет, он ищет регулярное выражение, а затем выполняет поиск по URI. Чтобы изменить приоритетность поиска по URI, используйте комбинацию символов ^
Директива try_files
Директива try_files – очень полезный инструмент, который проверяет наличие файлов в заданном порядке и использует первый найденный файл для обработки запроса.
Это позволяет вам с помощью дополнительных параметров определить, как Nginx будет обслуживать запросы.
В конфигурационном файле по умолчанию есть строка:
Если ни один файл или каталог не найден, Nginx выполняет файл по умолчанию (в данном случае это index.html в root-каталоге блока server). Каждая директива try_files использует последний параметр в качестве запасного варианта, потому этот файл должен существовать в системе.
В случае, если веб-сервер не обнаружил совпадений в предыдущих параметрах, он может вернуть страницу ошибки. Для этого используется знак равно и код ошибки.
Например, если блок location / не может найти запрашиваемый ресурс, вместо файла index.html он может вернуть ошибку 404:
Для этого нужно поставить знак равно и задать код ошибки в качестве последнего параметра (=404).
Дополнительные параметры
Директива alias позволяет Nginx обслуживать страницы блока location вне заданного каталога (например, вне root).
Например, файлы, запрашиваемые в /doc/, будут обслужены из /usr/share/doc/.
Директива autoindex on позволяет включает листинг директорий Nginx для заданной директивы location.
Строки allow и deny управляют доступом к каталогам.
Заключение
Веб-сервер Nginx является многофункциональным и очень производительным средством, однако его терминология и параметры могут показаться запутанными.
Разобравшись с конфигурациями Nginx и научившись работать с ними, вы получите все преимущества этого мощного и легковесного инструмента.
