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 уже установлен на компьютере читателя. Если нет, см. Установка 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 -s сигнал

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

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

nginx -s quit

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

nginx -s reload

kill -s QUIT 1628

ps -ax | grep nginx

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

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

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

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

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

http {

Server {

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

location / {

Root /data/www;

location /images/ {

Root /data;

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

server {

Location / {

Root /data/www;

Location /images/ {

Root /data;

nginx -s reload

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

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

server {

Listen 8080;

Root /data/up1;

Location / {

server {

Location / {

Proxy_pass http://localhost:8080;

Location /images/ {

Root /data;

Root /data/images;

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

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

server {

Location / {

Proxy_pass http://localhost:8080/;

Location ~ \.(gif|jpg|png)$ {

Root /data/images;

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

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

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

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

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;

Nginx? Назначение, особенности, варианты настроек - это вещи, с которыми должен быть ознакомлен каждый веб-разработчик, чтобы тестировать свои наработки.

О nginx замолвим слово

Данный инструмент обладает одним главным и несколькими рабочими процессами. Первый занимается чтением и проверкой конфигурации. Также под его контролем находится управление рабочими процессами. Задача последних - обрабатывать поступающие запросы. В nginx применяется модель, что базируется на событиях. Также используются механизмы, зависимые от операционной системы, чтобы добиться эффективного распределения запросов непосредственно между рабочими процессами. Их количество всегда обозначено в конфигурационном файле. Значение может быть как фиксированным, так и устанавливаться автоматически, ориентируясь по числу процессорных ядер, с которыми можно работать. В nginx настройка системы и модулей проводится с помощью конфигурационного файла. Поэтому, если надо что-то изменить, то искать необходимо именно его. Обычно он находится в директиве /etc/nginx (но путь может меняться при использовании других систем) и имеет расширение.conf.

Запуск, перезагрузка и логи

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

nginx -s сигнал

В данном случае подставлять можно такие команды (должны поступать от пользователя, что запустил инструмент):

Stop. Используется для быстрого завершения работы.
Reload. Команда необходима, чтобы перезагрузить конфигурационный файл. Дело в том, что любые изменения не будут применены, пока файл работает. И чтобы они вступили в силу, необходима перезагрузка. Как только будет получен этот сигнал, главный процесс начнёт проверять правильность синтаксической составляющей конфигурационного файла и попробует применить имеющиеся там указания. В случае неудачи он откатит изменения и будет работать со старыми параметрами. Если всё произошло успешно, то будут запущены новые рабочие процессы, а старым будет отправлено требование завершиться.
Quit. Применяется для плавного завершения работы. Применяется, если необходимо подождать, пока закончат обслуживаться текущие запросы.
Reopen. Закрыть и открыть лог-файлы.

Использование утилит

Настройка процессов может осуществляться также с помощью средств Unix (в качестве примера будет рассмотрена утилита kill). Обычно они используют механизм отправки процессу сигнала напрямую с данными. Увязываются они с помощью ID. Эти данные хранятся в файле nginx.pid. Допустим, что нас интересует процесс №134. Тогда для плавного завершения нам необходимо отправить следующую информацию:

kill -s QUIT 1628

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

ps -ax | grep nginx

То есть, как видите, при использовании дополнительного инструментария указывается, что идёт именно его применение. А теперь давайте сконцентрируемся на том, как совершается nginx-настройка.

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

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

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

Это одна их самых важных задач, которая стоит перед конфигурацией nginx. Под раздачей статистического содержимого подразумевают изображения и HTML-страницы (не динамические). Допустим, что нам нужна разовая работа по настройке nix nginx кластера. Сложно ли это сделать? Нет, и давайте рассмотрим пример. Прежде чем приступать к нему, необходимо детализировать условия задачи. Так, зависимо от запросов, файлы будут идти из разных локальных каталогов. Так, в /data/www мы имеем HTML-документы. А в каталоге /data/images содержатся изображения. Оптимальная настройка nginx в данном случае требует редактирования конфигурационного файла, в котором необходимо настроить блок server внутри http. Для поддержки будет использоваться также два location.

Реализация: server

Итак, для начала нам необходимо создать сами каталоги и разместить в них файлы с необходимыми расширениями (в html необходимо добавить содержимое). Затем открываем конфигурационный файл. В нём по умолчанию уже есть несколько блоков server, которые в массе своей закомментированы. Чтобы добиться оптимального результата, этот процесс необходимо проделать по отношению ко всем составляющим по умолчанию. Затем добавляем новый блок server с помощью такого кода:

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

Реализация: location

Определяется внутри server:

Наличие знака «/» необходимо, чтобы сравнивать получаемые данные и смотреть, есть ли такой адрес из обработанного запроса здесь. Если никаких проблем нет, то указываем путь /data/www к необходимому файлу, что находится в данной локальной системе. Если совпадение есть с несколькими блоками, то выбирается тот, у которого самый длинный префикс. В приведённом примере его длина равняется единице, то есть использование будет исключительно в том случае, если нет «конкурентов». Теперь давайте его усовершенствуем:

location /images/ {

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

location /images/ {

Это рабочий вариант, который случает стандартный Этот сервер без проблем может быть доступный на локальном компьютере, если пройти по адресу: http://localhost/. Как же это всё будет работать?

Принцип функционирования примера

Итак, когда придут запросы, что начинаются с с /images, то сервером файлы из соответствующего каталога будут отправляться пользователю. При его отсутствии будет передана информация, указывающая на ошибку 404. Если проводится настройка nginx на локальном компьютере, то при запросе http://localhost/images/example.png нами будет получен файл, месторасположение которого /data/images/example.png. При указании одного символа «/» поиск будет проводиться в директории /data/www. Но мы только изменили конфигурацию. Чтобы она начала работать, её необходимо перезагрузить. Для этого используйте команду nginx -s reload. В случае когда нормальная работа не является возможной, то в файлах error.log и access.log, расположенных в директиве /usr/local/nginx/logs, вы сможете поискать причину неисправностей.

Создание простого прокси-сервера

Можно сказать относительно nginx - настройка данного объекта является одним из частых применений (и довольно легким, между прочим). Здесь используется принцип сервера, который принимает запрос, а потом осуществляет перенаправление их к необходимым сайтам. После этого ожидается ответ от них, который направляет их к тому, кто поставил задачу. Поэтому давайте рассмотрим пример создания базовой точки. Она будет заниматься обслуживанием запросов пользователей и предоставлять им изображения из локального каталога. Итак, к блоку http добавляем ещё один server с таким содержимым:

А теперь давайте для вас расшифрую: создаётся простой сервер. Он будет прослушивать Не указать listen, то сервер будет работать на 80-м. Отображаться будут все запросы в рамках локальной файловой системы, которые направлены на каталог /data/up1 (конечно, его перед этим необходимо будет создать). Для возможности проверки там необходимо поместить файл index.html. Благодаря размещению директивы root в контексте server мы сможем воспользоваться location при любых условиях (поскольку, таким образом, снимаются ограничения доступа). Теперь работаем над созданием прокси-сервера. Для его работы нам понадобится директива proxy_pass, для которой будут указаны протокол, имя, а также порт объекта как параметры (при локальном подключении это будет выглядеть как http://localhost:8080). Получится такой результат:

proxy_pass http://localhost:8080;

location /images/ {

Если вы рассматриваете код и анализируете его, то можете заметить, что второй блок location был изменён. Так, в данном случае он может работать с типичными расширениями изображений. Немного по-другому его можно было бы отобразить таким образом:

location ~ \.(gif|jpg|png)$ {

root /data/images;

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

proxy_pass http://localhost:8080/;

location ~ \.(gif|jpg|png)$ {

root /data/images;

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