Как проверить установлен ли nginx

nginx устанавливается по-разному в зависимости от операционной системы.

Установка на Linux

Для установки nginx на Linux могут быть использованы пакеты с nginx.org.

Установка на FreeBSD

На FreeBSD можно установить nginx либо из пакетов, либо с помощью системы портов. Система портов даёт большую гибкость, позволяя выбирать из широкого набора настроек. Порт скомпилирует nginx с выбранными опциями и установит.

Сборка из исходных файлов

Если необходима специфическая функциональность, недоступная из пакетов или портов, можно скомпилировать 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 — плавное завершение
reload — перезагрузка конфигурационного файла
reopen — переоткрытие лог-файлов

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

nginx -s quit

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

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

nginx -s reload

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

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

kill -s QUIT 1628

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

ps -ax | grep nginx

Дополнительную информацию об отправке сигналов процессам 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 :

http < server < >>

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

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

location / < root /data/www; >

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

nginx -s reload

В случае если что-то работает не как ожидалось, можно попытаться выяснить причину с помощью файлов 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.

Освоение NGINX: полное руководство по настройке и оптимизации веб-сервера

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

В этом блоге мы рассмотрим различные аспекты NGINX: от установки и базовой настройки до продвинутых методов оптимизации. Независимо от того, являетесь ли вы новичком или опытным пользователем, эта серия даст вам четкое представление о NGINX и поможет раскрыть весь его потенциал. Итак, давайте вместе погрузимся и освоим NGINX!

Установка

Вот шаги по установке NGINX в Ubuntu:

Обновите список пакетов:

sudo apt update

Установите NGINX:

sudo apt install nginx

Проверьте статус NGINX:

sudo systemctl status nginx

Это должно отобразить статус NGINX, который должен быть «active (running)», если установка прошла успешно.

Настройте брандмауэр, чтобы разрешить трафик HTTP и HTTPS:

sudo ufw allow 'Nginx HTTP' sudo ufw allow 'Nginx HTTPS'

Убедитесь, что NGINX работает, посетив общедоступный IP-адрес вашего сервера в веб-браузере. Вы должны увидеть страницу приветствия NGINX по умолчанию.

Вот и все! NGINX теперь установлен и готов к использованию в вашей Ubuntu.

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

Nginx использует файл конфигурации, чтобы определить, как ему следует обрабатывать входящие запросы. Файл конфигурации находится по адресу /etc/nginx/nginx.conf в большинстве систем Linux. Файл конфигурации написан на языке конфигурации NGINX (NCL).

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

http: этот раздел определяет, как Nginx должен обрабатывать HTTP-запросы.
server: этот раздел определяет, как Nginx должен обрабатывать запросы к определенному серверу.
location: этот раздел определяет, как Nginx должен обрабатывать запросы по определенному URL-адресу.

Вот пример базового файла конфигурации Nginx:

http < server < listen 80; server_name example.com; location / < root /var/www/html; index index.html; >> >

Этот файл конфигурации определяет сервер, который прослушивает порт 80 на предмет запросов к example.com . При получении запроса Nginx обработает файл index.html из каталога /var/www/html .

Давайте начнем!

Если вы знакомы с сетями или даже новичок, я почти уверен, что вы слышали термин «обратный прокси-сервер», а также, возможно, слышали, что NGINX — это всего лишь обратный прокси-сервер. Так что же это за прокси и все такое, Давайте разберемся во всем шаг за шагом.

Прокси

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

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

Вот как это работает:

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

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

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

Существует несколько типов прокси, включая прямые прокси, обратные прокси и прозрачные прокси. Прямой прокси — это прокси, который используется клиентом для доступа к любому серверу в Интернете. Обратный прокси — это прокси-сервер, который используется сервером для доступа к любому клиенту в Интернете. Прозрачный прокси — это прокси, который каким-либо образом не изменяет запрос или ответ и часто используется для целей кэширования.

Прокси-серверы могут быть реализованы на различных уровнях сетевого стека, включая уровень приложений, транспортный уровень и сетевой уровень. Прокси-серверы прикладного уровня, также известные как прокси-серверы уровня шлюза или протокола, используются для проксирования определенных протоколов приложений, таких как HTTP или SMTP. Прокси транспортного уровня, также известные как прокси уровня канала, используются для проксирования TCP-соединений. Прокси-серверы сетевого уровня, также известные как прокси-серверы уровня пакетов, используются для проксирования IP-пакетов.

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

Прямой прокси

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

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

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

Вот пример использования прямого прокси в JavaScript с библиотекой axios :

const axios = require('axios'); const proxyUrl = 'http://my-forward-proxy.com:8080'; const axiosInstance = axios.create( < proxy: < host: proxyUrl, port: 8080 >>); axiosInstance.get('https://www.example.com') .then(response => < console.log(response.data); >) .catch(error => < console.error(error); >);

В этом примере мы используем библиотеку axios для отправки HTTP-запроса GET на https://www.example.com . Мы определили переменную proxyUrl , содержащую URL-адрес нашего прямого прокси. Затем мы создаем экземпляр библиотеки axios и устанавливаем для параметра конфигурации прокси объект, содержащий хост и порт нашего прямого прокси.

Когда мы делаем запрос HTTP GET с помощью axiosInstance.get() , запрос будет отправлен через наш прямой прокси. Данные ответа затем записываются на консоль. Если произойдет ошибка, она также будет обнаружена и записана на консоль.

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

Обратный прокси

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

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

Другим примером обратного прокси является сеть доставки контента (CDN). CDN используются веб-сайтами для распространения контента между несколькими серверами, расположенными в разных географических точках. Когда клиент запрашивает ресурс с веб-сайта, использующего CDN, запрос сначала отправляется на ближайший сервер CDN, который затем перенаправляет запрос на соответствующий сервер от имени клиента. Ответ от сервера затем отправляется обратно на сервер CDN, который, в свою очередь, отправляет его обратно клиенту. Это может помочь повысить производительность за счет сокращения расстояния, которое данные должны пройти между клиентом и сервером.

Вот пример реализации обратного прокси в NGINX:

http < upstream backend < server backend1.example.com; server backend2.example.com; server backend3.example.com; >server < listen 80; server_name example.com; location / < proxy_pass http://backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; >> >

В этом примере мы определяем восходящий блок, в котором указываются серверы, которые мы хотим использовать в качестве внутренних серверов. Затем мы определяем блок сервера, который прослушивает порт 80 и указывает имя домена, или мы можем сказать server_name , которое мы хотим использовать для нашего веб-сайта. Внутри блока сервера мы определяем блок местоположения, в котором указывается путь URL-адреса, который мы хотим проксировать. Затем мы используем директиву proxy_pass , чтобы указать восходящий блок, который мы определили ранее. Мы также используем директиву proxy_set_header для установки различных заголовков, которые будут отправлены на внутренние серверы.

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

Заключение

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

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

NGINX

NGINX — программное обеспечение, написанное для UNIX-систем. Основное назначение — самостоятельный HTTP-сервер, или, как его используют чаще, фронтенд для высоконагруженных проектов. Возможно использование NGINX как почтового SMTP/IMAP/POP3-сервера, а также обратного TCP прокси-сервера.

Как используется и работает nginx

NGINX является широко используемым продуктом в мире IT, по популярности уступая лишь Apache.
Как правило, его используют либо как самостоятельный HTTP-сервер, используя в бекенде PHP-FPM, либо в связке с Apache, где NGINX используется во фронтэнде как кеширующий сервер, принимая на себя основную нагрузку, отдавая статику из кеша, обрабатывая и отфильтровывая входящие запросы от клиента и отправляя их дальше к Apache. Apache работает в бекэнде, работая уже с динамической составляющей проекта, собирая страницу для передачи её в кеш NGINX и запрашивающему её клиенту. Это если в общих чертах, чтобы понимать суть работы, так-то внутри всё сложнее.

Как проверить, установлен ли NGINX

Пишете в консоль SSH следующую команду, она покажет версию NGINX

nginx -v

Если видите что-то навроде
nginx version: nginx/1.10.3
Значит, всё в порядке, установлен NGINX версии 1.10.3 . Если нет, установим его.

Как установить NGINX

Если вы сидите не под root , предваряйте команды apt-get префиксом sudo , например sudo apt-get install nginx

Обновляем порты (не обязательно)

apt-get update && apt-get upgrade

apt-get install nginx

nginx -v

Где расположен nginx

Во FreeBSD NGINX располагается в /usr/local/etc/nginx .
В Ubuntu, Debian NGINX располагается тут: /etc/nginx . В ней располагается конфигурационный файл nginx.conf — основной конфигурационный файл nginx.
Чтобы добраться до него, выполняем команду в консоли

nano /etc/nginx/nginx.conf

По умолчанию, файлы конфигураций конкретных сайтов располагаются в /etc/nginx/sites-enabled/

cd /etc/nginx/sites-enabled/

или в /etc/nginx/vhosts/

cd /etc/nginx/vhosts/

Как правильно составить правила nginx.conf

Идём изучать мануалы на официальный сайт.
Пример рабочей конфигурации NGINX в роли кеширующего проксирующего сервера с Apache в бекенде

# Определяем пользователя, под которым работает nginx user www-data; # Определяем количество рабочих процессов автоматически # Параметр auto поддерживается только начиная с версий 1.3.8 и 1.2.5. worker_processes auto; # Определяем, куда писать лог ошибок и уровень логирования error_log /var/log/nginx/error.log warn; # Задаём файл, в котором будет храниться номер (PID) основного процесса pid /var/run/nginx.pid; events < # Устанавливает максимальное количество соединений одного рабочего процесса. Следует выбирать значения от 1024 до 4096. # Как правило, число устанавливают в зависимости от числа ядер процессора по принципу n * 1024. Например, 2 ядра дадут worker_connections 2048. worker_connections 1024; # Метод обработки соединений. Наличие того или иного метода определяется платформой. # Как правило, NGINX сам умеет определять оптимальный метод, однако, его можно указать явно. # use epoll - используется в Linux 2.6+ # use kqueue - FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 и Mac OS X use epoll; # Будет принимать максимально возможное количество соединений multi_accept on; >http < include /etc/nginx/mime.types; default_type application/octet-stream; log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; # Куда писать лог доступа и уровень логирования access_log /var/log/nginx/access.log main; # Для нормального ответа 304 Not Modified; if_modified_since before; # Включаем поддержку WebP map $http_accept $webp_ext < default ""; "~*webp" ".webp"; >## # Basic Settings ## # Используется, если количество имен серверов большое #server_names_hash_max_size 1200; #server_names_hash_bucket_size 64; ### Обработка запросов ### # Метод отправки данных sendfile более эффективен, чем стандартный метод read+write sendfile on; # Будет отправлять заголовки и и начало файла в одном пакете tcp_nopush on; tcp_nodelay on; ### Информация о файлах ### # Максимальное количество файлов, информация о которых будет содержаться в кеше open_file_cache max=200000 inactive=20s; # Через какое время информация будет удалена из кеша open_file_cache_valid 30s; # Кеширование информации о тех файлах, которые были использованы хотя бы 2 раза open_file_cache_min_uses 2; # Кеширование информации об отсутствующих файлах open_file_cache_errors on; # Удаляем информацию об nginx в headers server_tokens off; # Будет ждать 30 секунд перед закрытием keepalive соединения keepalive_timeout 30s; ## Максимальное количество keepalive запросов от одного клиента keepalive_requests 100; # Разрешает или запрещает сброс соединений по таймауту reset_timedout_connection on; # Будет ждать 30 секунд тело запроса от клиента, после чего сбросит соединение client_body_timeout 30s; # В этом случае сервер не будет принимать запросы размером более 200Мб client_max_body_size 200m; # Если клиент прекратит чтение ответа, Nginx подождет 30 секунд и сбросит соединение send_timeout 30s; # Proxy # # Задаёт таймаут для установления соединения с проксированным сервером. # Необходимо иметь в виду, что этот таймаут обычно не может превышать 75 секунд. proxy_connect_timeout 30s; # Задаёт таймаут при передаче запроса проксированному серверу. # Таймаут устанавливается не на всю передачу запроса, а только между двумя операциями записи. # Если по истечении этого времени проксируемый сервер не примет новых данных, соединение закрывается. proxy_send_timeout 30s; # Задаёт таймаут при чтении ответа проксированного сервера. # Таймаут устанавливается не на всю передачу ответа, а только между двумя операциями чтения. # Если по истечении этого времени проксируемый сервер ничего не передаст, соединение закрывается. proxy_read_timeout 30s; ## # Gzip Settings ## # Включаем сжатие gzip gzip on; # Для IE6 отключить gzip_disable "msie6"; # Добавляет Vary: Accept-Encoding в Headers gzip_vary on; # Cжатие для всех проксированных запросов (для работы NGINX+Apache) gzip_proxied any; # Устанавливает степень сжатия ответа методом gzip. Допустимые значения находятся в диапазоне от 1 до 9 gzip_comp_level 6; # Задаёт число и размер буферов, в которые будет сжиматься ответ gzip_buffers 16 8k; # Устанавливает минимальную HTTP-версию запроса, необходимую для сжатия ответа. Значение по умолчанию gzip_http_version 1.1; # MIME-типы файлов в дополнение к text/html, которые нужно сжимать gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript image/svg+xml; # Минимальная длина файла, которую нужно сжимать gzip_min_length 10; # Подключаем конфиги конкретных сайтов include /etc/nginx/conf.d/*.conf; include /etc/nginx/vhosts/*/*; ### Далее определяем localhost ### Сюда отправляются запросы, для которых не был найден свой конкретный блок server в /vhosts/ server < server_name localhost; # Тут можно ввести IP сервера disable_symlinks if_not_owner; listen 80 default_server; # Указываем, что это сервер по умолчанию на порту 80 ### Возможно, понадобится чётко указать IP сервера # listen 192.168.1.1:80 default_server; ### Можно сбрасывать соединения с сервером по умолчанию, а не отправлять запросы в бекенд #return 444; include /etc/nginx/vhosts-includes/*.conf; location @fallback < error_log /dev/null crit; proxy_pass http://127.0.0.1:8080; proxy_redirect http://127.0.0.1:8080 /; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; access_log off ; >> >

Строка include /etc/nginx/vhosts/*; указывает на поддиректорию vhosts , в которой содержатся файлы конфигураций конкретно под каждый домен.
Пример того, что может содержаться там — example.com.conf
Ниже пример для Apache в бекенде:

server < # Домен сайта и его алиасы через пробел server_name example.com www.example.com; # Кодировка сайта. Содержимое заголовка "Content-Type". off отключает этот заголовок. Можно указать стандартные uft-8, windows-1251, koi8-r, либо же использовать свою. charset off; disable_symlinks if_not_owner from=$root_path; index index.html; root $root_path; set $root_path /var/www/example/data/www/example.com; access_log /var/www/httpd-logs/example.com.access.log ; error_log /var/www/httpd-logs/example.com.error.log notice; #IP:Port сервера NGINX listen 192.168.1.1:80; include /etc/nginx/vhosts-includes/*.conf; location / < location ~ [^/]\.ph(p\d*|tml)$ < try_files /does_not_exists @fallback; ># WebP location ~* ^.+\.(png|jpe?g)$ < expires 365d; add_header Vary Accept; try_files $uri$webp_ext $uri =404; >location ~* ^.+\.(gif|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf)$ < expires 365d; try_files $uri =404; >location / < try_files /does_not_exists @fallback; >> location @fallback < proxy_pass http://127.0.0.1:8080; proxy_redirect http://127.0.0.1:8080 /; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; access_log off ; >>

А вот вариант для PHP-FPM:

server < # Домен сайта и его алиасы через пробел server_name example.com www.example.com; # Кодировка сайта. Содержимое заголовка "Content-Type". off отключает этот заголовок. Можно указать стандартные uft-8, windows-1251, koi8-r, либо же использовать свою. charset off; disable_symlinks if_not_owner from=$root_path; index index.html; root $root_path; set $root_path /var/www/example/data/www/example.com; access_log /var/www/httpd-logs/example.com.access.log ; error_log /var/www/httpd-logs/example.com.error.log notice; #IP:Port сервера NGINX listen 192.168.1.1:80; include /etc/nginx/vhosts-includes/*.conf; location / < location ~ [^/]\.ph(p\d*|tml)$ < try_files /does_not_exists @php; ># WebP location ~* ^.+\.(png|jpe?g)$ < expires 365d; add_header Vary Accept; try_files $uri$webp_ext $uri =404; >location ~* ^.+\.(gif|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf)$ < expires 365d; try_files $uri =404; >location / < try_files $uri $uri/ @php; >> location @php < try_files $uri =404; include fastcgi_params; fastcgi_index index.php; fastcgi_param PHP_ADMIN_VALUE "sendmail_path = /usr/sbin/sendmail -t -i -f [email protected]"; # Путь к сокету php-fpm сайта fastcgi_pass unix:/var/www/php-fpm/example.sock; fastcgi_split_path_info ^((?U).+\.ph(?:p\d*|tml))(/?.+)$; > >

NGINX WordPress Multisite

Ниже конфигурация под WordPress Multisite с сайтами в поддиректориях:

#user 'example' virtual host 'example.com' configuration file server < server_name example.com www.example.com; charset off; disable_symlinks if_not_owner from=$root_path; index index.html index.php; root $root_path; set $root_path /var/www/example/data/www/example.com; access_log /var/www/httpd-logs/example.com.access.log ; error_log /var/www/httpd-logs/example.com.error.log notice; listen 1.2.3.4:80; include /etc/nginx/vhosts-includes/*.conf; # А вот тут блок специально для MU subdirectories if (!-e $request_filename) < rewrite /wp-admin$ $scheme://$host$uri/ permanent; rewrite ^(/[^/]+)?(/wp-.*) $2 last; rewrite ^(/[^/]+)?(/.*\.php) $2 last; >location / < try_files $uri $uri/ /index.php?$args ; >location ~ \.php < try_files $uri =404; include fastcgi_params; fastcgi_index index.php; fastcgi_param PHP_ADMIN_VALUE "sendmail_path = /usr/sbin/sendmail -t -i -f [email protected]"; fastcgi_pass unix:/var/www/php-fpm/example.sock; fastcgi_split_path_info ^((?U).+\.ph(?:p\d*|tml))(/?.+)$; > >

Как заблокировать по IP в NGINX

Блокировать можно с помощью директив allow и deny.

Правила обработки таковы, что поиск идёт сверху вниз. Если IP совпадает с одним из правил, поиск прекращается.
Таким образом, вы можете как забанить все IP, кроме своих, так и заблокировать определённый IP:

deny 1.2.3.4 ; # Здесь мы вводим IP нарушителя deny 192.168.1.1/23 ; # А это пример того, как можно добавить подсеть в бан deny 2001:0db8::/32 ; # Пример заблокированного IPv6 allow all ; # Всем остальным разрешаем доступ

Приведу пример конфигурации, как можно закрыть доступ к панели администратора WordPress по IP:

### https://sheensay.ru/?p=408 ################################ location = /wp-admin/admin-ajax.php < # Открываем доступ к admin-ajax.php. Это нужно, чтобы проходили ajax запросы в WordPress try_files $uri/ @php ; >location = /adminer.php < # Закрываем Adminer, если он есть try_files /does_not_exists @deny ; >location = /wp-login.php < # Закрываем /wp-login.php try_files /does_not_exists @deny ; >location ~* /wp-admin/.+\.php$ < # Закрываем каталог /wp-admin/ try_files /does_not_exists @deny ; >location @deny < # В этом location мы определяем правила, какие IP пропускать, а какие забанить allow 1.2.3.4 ; # Здесь мы вводим свой IP из белого списка allow 192.168.1.1/23 ; # А это пример того, как можно добавить подсеть IP allow 2001:0db8::/32 ; # Пример IPv6 deny all ; # Закрываем доступ всем, кто не попал в белый список try_files /does_not_exists @php; # Отправляем на обработку php в бекенд >location ~ \.php$ < ### Файлы PHP обрабатываем в location @php try_files /does_not_exist @php; >location @php

Ещё один неплохой вариант. Правда, по умолчанию определяются только статичные IP. А чтобы разрешить подсеть, придётся использовать дополнительный модуль GEO:

### Задаём таблицу соответсткий map $remote_addr $allowed_ip < ### Перечисляете разрешённые IP 1.2.3.4 1; ### 1.2.3.4 - это разрешённый IP 4.3.2.1 1; ### 4.3.2.1 - это ещё один разрешённый IP default 0; ### По умолчанию, запрещаем доступ >server < ### Объявляем переменную, по которой будем проводить проверку доступа set $check ''; ### Если IP не входит в список разрешённых, отмечаем это if ( $allowed_ip = 0 ) < set $check "A"; >### Если доступ идёт к wp-login.php, отмечаем это if ( $request_uri ~ ^/wp-login\.php ) < set $check "$B"; > ### Если совпали правила запрета доступа — отправляем соответствующий заголовок ответа if ( $check = «AB» )

Как в NGINX указать размер и время

directio_alignment 512;

client_header_buffer_size 1k;

client_max_body_size 100M;

client_max_body_size 1G;

Время задаётся в следующих суффиксах:

ms — миллисекунды
s — секунды
m — минуты
h — часы
d — дни
w — недели
M — месяцы, 30 дней
Y — годы, 365 дней

В одном значении можно комбинировать различные единицы, указывая их в порядке от более к менее значащим, и по желанию отделяя их пробелами. Например, 1h 30m задаёт то же время, что и 90m или 5400s . Значение без суффикса задаёт секунды.

Рекомендуется всегда указывать суффикс

Некоторые интервалы времени можно задать лишь с точностью до секунд.

Настройка отладки в NGINX

В целях отладки настройки NGINX вы можете писать данные в логи, но я советую воспользоваться директивой add_header. С её помощью вы можете выводить различные данные в http headers.
Пример, как можно определить, в каком location обрабатывается правило:

location ~ [^/]\.ph(p\d*|tml)$ < try_files /does_not_exists @fallback; add_header X-debug-message "This is php" always; >location ~* ^.+\.(jpe?g|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf)$ < expires 365d; log_not_found off; access_log off; try_files $uri $uri/ @fallback; add_header X-debug-message "This is static file" always; >

Теперь, если проверить, какие заголовки отдаёт статичный файл, например https://sheensay.ru/wp-content/uploads/2015/06/nginx.png , то вы увидите среди них и наш X-debug-message

Отладочная информация NGINX в заголовках HTTP headers

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

Добавление модулей NGINX в Linux (Debian/CentOS/Ubuntu)

Функционал NGINX возможно расширить с помощью модулей. С их списком и возможным функционалом можно ознакомиться на официальном сайте http://nginx.org/ru/docs/. Также, существуют интересные сторонние модули, например, модуль NGINX для защиты от DDoS
Приведу пример установки модуля ngx_headers_more.

Все команды выполняются в консоли, используйте Putty или Far Manager с NetBox/WinSCP. Установка будет происходить под Debian

nginx -V

В результате увидите что-то навроде

nginx version: nginx/1.8.0 built by gcc 4.9.1 (Debian 4.9.1-19) built with OpenSSL 1.0.1k 8 Jan 2015 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/etc/nginx/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/ngin x/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/p roxy_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=ng inx --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-htt p_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-htt p_auth_request_module --with-mail --with-mail_ssl_module --with-file-aio --with-http_spdy_module --with-cc-opt='-g -O2 -fstack-protector-strong -Wformat -Werror=format-securi ty' --with-ld-opt=-Wl,-z,relro --with-ipv6

wget http://nginx.org/download/nginx-1.8.0.tar.gz

tar xvf nginx-1.8.0.tar.gz

rm -rf nginx-1.8.0.tar.gz

cd nginx-1.8.0

wget https://github.com/openresty/headers-more-nginx-module/archive/v0.29.tar.gz

tar xvf v0.29.tar.gz

aptitude install build-essential

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

apt-get install aptitude

./configure --prefix=/etc/nginx --sbin-path=/etc/nginx/sbin/nginx --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-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-mail --with-mail_ssl_module --with-file-aio --with-http_spdy_module --with-cc-opt='-g -O2 -fstack-protector-strong -Wformat -Werror=format-security' --with-ld-opt=-Wl,-z,relro --with-ipv6 --add-module=./headers-more-nginx-module-0.29

./configure: error: the HTTP rewrite module requires the PCRE library. You can either disable the module by using --without-http_rewrite_module option, or install the PCRE library into the system, or build the PCRE library statically from the source with nginx by using --with-pcre= option.

Эта проблема решается установкой libpcre++-dev :

aptitude install libpcre++-dev

./configure: error: SSL modules require the OpenSSL library. You can either do not enable the modules, or install the OpenSSL library into the system, or build the OpenSSL library statically from the source with nginx by using --with-openssl= option.

Эта проблема решается так:

aptitude install libssl-dev

Configuration summary + using system PCRE library + using system OpenSSL library + md5: using OpenSSL library + sha1: using OpenSSL library + using system zlib library nginx path prefix: "/etc/nginx" nginx binary file: "/etc/nginx/sbin/nginx" nginx configuration prefix: "/etc/nginx" nginx configuration file: "/etc/nginx/nginx.conf" nginx pid file: "/var/run/nginx.pid" nginx error log file: "/var/log/nginx/error.log" nginx http access log file: "/var/log/nginx/access.log" nginx http client request body temporary files: "/var/cache/nginx/client_temp" nginx http proxy temporary files: "/var/cache/nginx/proxy_temp" nginx http fastcgi temporary files: "/var/cache/nginx/fastcgi_temp" nginx http uwsgi temporary files: "/var/cache/nginx/uwsgi_temp" nginx http scgi temporary files: "/var/cache/nginx/scgi_temp"

make install clean

/usr/sbin/nginx -V

В результате должны увидеть модуль на месте

nginx version: nginx/1.8.0 built by gcc 4.9.2 (Debian 4.9.2-10) built with OpenSSL 1.0.1k 8 Jan 2015 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/etc/nginx/sbin/nginx --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-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-mail --with-mail_ssl_module --with-file-aio --with-http_spdy_module --with-cc-opt='-g -O2 -fstack-protector-strong -Wformat -Werror=format-security' --with-ld-opt=-Wl,-z,relro --with-ipv6 --add-module=./headers-more-nginx-module-0.29

service nginx stop

mv /usr/sbin/nginx /usr/sbin/nginx_back

mv /etc/nginx/sbin/nginx /usr/sbin/nginx

nginx -V

service nginx start