Server nginx что такое
Что такое Nginx
Содержание:
Nginx — мощный инструмент для развертывания веб-сервера, который при правильной настройке превосходит Apache. Области применения Nginx весьма обширны — от кэширования HTTP до создания инвертированного прокси-сервера.
Сейчас Nginx обслуживает примерно 30,8% всех существующих сайтов мира, о чьих веб-серверах есть информация в открытом доступе. Понимание, что из себя представляет Nginx и как этот программный продукт можно применять на практике, помогает эффективно решать задачи во многих областях IT-индустрии.
В этой статье рассмотрим принцип работы Nginx, а также его функционал, отличия от Apache и способ установки на конкретную ОС.
Что такое Nginx
Nginx (NGINX, Engine-X, «Энжин-кс») — это бесплатный веб- и почтовый прокси-сервер с непоточной (асинхронной) архитектурой и открытым кодом.
Nginx работает на ОС Unix-типа и был успешно протестирован на OpenBSD, FreeBSD, Linux, Mac OS X, Solaris. На ОС Windows он стал доступен после выпуска бинарной сборки 0,7.52.
На данный момент функционалом пользуются такие известные платформы: Rambler, Begun, Yandex, SourceForge.net, WordPress.com, vkontakte.ru. Статистика показывает, что Nginx используют 22,3 млн веб-сайтов и 2,03 млн дополнительных активных сайтов.
Как работает Nginx
В отличие от обычного веб-сервера, Nginx не создаёт один поток под каждый запрос, а разделяет его на меньшие однотипные структуры, называемые рабочими соединениями. Каждое такое соединение обрабатывается отдельным рабочим процессом, а после выполнения они сливаются в единый блок, возвращающий результат в основной процесс обработки данных. Одно рабочее соединение может обрабатывать до 1024 запросов одного вида одновременно.
Практическое применение
NGINX vs Apache
Веб-сервер Nginx по сравнению с Apache работает быстрее при отдаче статики и потребляет меньше серверных ресурсов. Его использует вместо или совместно с Apache для ускорения обработки запросов и уменьшения нагрузки. Это обуславливается тем, что большая часть тех возможностей, которые предлагает Apache, большинству обычных пользователей не нужно.
Поскольку широкий функционал Nginx требует и значительно больших ресурсов системы, постоянно применять полноценную связку «Nginx + Apache» нецелесообразно. Чаще оба веб-сервера используются в симбиозе — Nginx отдает статику и перенаправляет обработку скриптов Apache.
Нужно, чтобы Nginx и Apache работали без сбоев? Мощный VPS от Eternalhost позволит сохранить оптимальную производительность, даже при пиковых нагрузках.
Сильные и слабые стороны
Архитектура и конфигурация Nginx
Установка на Linux возможна двумя способами — из предварительно собранного бинарного файла (пакета) или с помощью исходного кода.
Первый способ самый простой, но второй позволяет подключить различные дополнительные модули, расширяющие возможности сервера. Установка с помощью исходного кода применяется сравнительно редко, поэтому ее особенности рассматривать здесь не будем.
Установка Nginx на Windows возможна с помощью интерфейса Win32 API. Однако, такой вариант будет гораздо менее эффективен, даже в серверных версиях и не может быть рекомендован для широкого применения.
Установка из предварительно собранного файла
Для конфигурации Nginx задействуется директория /etc/nginx/. При дальнейшей работе с сервером важны файл nginx.conf и папка sites-available.
Основные настройки можно в файле nginx.conf. Благодаря этому файлу, все параметры можно настроить по своему усмотрению. Работать можно и с настройками по умолчанию.
Важные элементы конфигурации
Сервер может обслуживать множество сайтов. Файлы, которые определяют какие именно, находятся в директории /etc/nginx/sites-available.
Чтобы Nginx работал с сайтами, их необходимо слинковать с /etc/nginx/sites-enabled.
Использования метода линкования позволяет быстро запускать сайты, не удаляя никакие файлы после их использования. Помимо этого, можно просто скопировать файлы прямо в первую директорию.
Символьная ссылка — это путь к файлу. Общий синтаксис для неё выглядит так:
Примеры ссылок для каталога и файла:
Директория sites-available содержит конфигурацию виртуальных хостов. Это позволяет веб-серверу настраиваться для множества сайтов с разной конфигурацией. Сайты в этой директории не задействуются и будут обслуживаться только, если сделать символьную ссылку на папку sites-enabled.
Настройка конфигурации
Root-каталог Nginx по умолчанию находится в директории /usr/share/nginx/html. Все файлы, которые размещаются в нем, автоматически обслуживаются веб-сервером. Место определяется файлом конфигурации, который можно найти в /etc/nginx/conf.d/default.conf.
Основной конфигурационный файл сервера находится в /etc/nginx/nginx.conf. Через него изменяются любые настройки.
Запуск
Установка Nginx на CentOS
Рассмотрим практически установку Nginx на Linux, взяв за основу один из самых популярных дистрибутивов данной операционной системы – CentOS.
Заключение
Nginx представляет собой практически готовое решение для множества задач, требующих развёртывания полноценного веб-сервера или прокси. По ряду параметров Nginx превосходит своего «старшего коллегу» Apache. Главные из них — отсутствие требовательности к ресурсам и способность обрабатывать большое число соединений одновременно.
Понимание работы и принципа обработки запросов в Nginx позволяет грамотно масштабировать и балансировать нагрузку на современных сайтах, располагающих контентом разных категорий. А связка Nginx и Apache позволяет максимально расширить эффективность применения веб-сервера.
Чтобы Nginx, Apache и другой сложный «софт» работал, как швейцарские часы, разверните их на виртуальном сервере от Eternalhost! Это мощный и надёжный инструмент для самых неординарных задач в области IT.
Nginx — быстрый, дерзкий и суперпопулярный сервер
Мы постепенно рассказываем о веб-серверах — это программы, которые отвечают за то, чтобы нам выдавались сайты. В прошлой серии показывали Apache — один из первых массовых веб-серверов, который до сих пор работает в огромном количестве компьютеров. А сегодня — новое поколение.
Короткая предыстория
Главная проблема веб-сервера Apache, про который мы говорили прошлый раз, — это падение производительности с ростом трафика. Чем больше людей заходят на сайт, тем хуже он справляется. Решения на тот момент были такие:
И то и другое — дорого. Чтобы решить эту проблему, в 2002 году системный администратор Игорь Сысоев начал разрабатывать собственный веб-сервер, который сможет решить проблему с проседанием под нагрузкой. Тогда Игорь работал в «Рамблере».
Через два года вышел первый релиз его веб-сервера Nginx. Сейчас это самый популярный веб-сервер в России и в тройке самых известных — в мире.
Архитектура
Apache работает так: все запросы, которые попадают на этот сервер, обслуживаются до тех пор, пока не будет дан полный ответ на запрос. Это значит, что если для ответа нужно будет попросить движок сайта собрать новую страницу, то Apache даст задание движку, а сам будет ждать ответ, пока не дождётся. Когда запросов много, сервер начинает тратить свои ресурсы на простой и ожидания, а не на реальную работу.
В Nginx всё устроено немного иначе:
Получается, что так как Nginx не тратит время на ожидание результата, то он может одновременно обрабатывать гораздо больше запросов, чем Apache. В этом и есть суперсила Nginx.
В чём ещё отличия от Apache
Документация. У Apache документации, форумов и примеров гораздо больше, потому что проект начался на 7 лет раньше и все материалы сразу были на английском — стандартном языке для всех программистов.
Nginx появился позже и в России, поэтому почти вся документация изначально была на русском. Из-за этого разработчикам из других стран было трудно использовать Nginx, но со временем ситуация выровнялась: сейчас проект ведётся одновременно на русском и на английском языках.
Работа с модулями. В Apache всё просто: прописал название модуля и веб-сервер сразу его подгрузил и начал использовать. Не нужно — выгрузил, тоже на ходу. Это позволяет очень гибко настраивать поведение сервера в разные моменты времени.
Чтобы добавить модули в Nginx, их нужно выбрать заранее и скомпилировать вместе с ядром сервера. С одной стороны, это неудобно: нужно на старте чётко представлять, что будет делать сервер и в каких ситуациях. Но с другой — это повышает безопасность: не получится на лету подключить какой-то неизвестный и непроверенный модуль, в котором будет дыра в безопасности.
Nginx + Apache = ❤️
Может показаться, что Nginx и Apache воюют друг с другом за долю рынка, но на самом деле они отлично работают вместе:
Получается так: Nginx занимается самыми простыми запросами, которые можно выполнить моментально, а всю динамику и сборки отправляет в Apache и продолжает заниматься своими делами.
В итоге польза всем: пока Apache ждёт или собирает страницы, Nginx успевает переделать кучу дел и не тратит своё время на ожидание. Системные администраторы часто используют такую связку, чтобы сбалансировать нагрузку на сервер и более эффективно использовать ресурсы.
Кто использует
Если вы назовёте три любых крупных ИТ-компании, то две из них точно будут использовать Nginx. В этом можно легко убедиться самому, посмотрев на список тех проектов, где используют эту программу:
Причина такой популярности — в скорости работы, надёжности и универсальности Nginx. К нему можно прикрутить почти любой софт и получить любую конфигурацию ответов на запросы.
Конфликт с «Рамблером»
В 2019 году произошла такая история: Рамблер заявил, что раз Сысоев во время создания Nginx работал у них, то и все права на этот веб-сервер тоже принадлежат им. В итоге завели дело по статье о нарушении авторских прав, а Рамблер требовал возместить им ущерб в 50 миллионов рублей.
Через полгода уголовное дело прекратили за отсутствием состава преступления: компания не смогла найти подтверждения своим словам и не смогла получить права на код 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
Команда должна показать версию сервера, что-то подобное:
nginx version: nginx/1.10.3
Где расположен nginx
По умолчанию, файлы конфигураций конкретных сайтов располагаются в /etc/nginx/sites-enabled/
или в /etc/nginx/vhosts/
Как правильно составить правила nginx.conf
Идём изучать мануалы на официальный сайт.
Пример рабочей конфигурации NGINX в роли кеширующего проксирующего сервера с Apache в бекенде
А вот вариант для PHP-FPM:
NGINX WordPress Multisite
Ниже конфигурация под WordPress Multisite с сайтами в поддиректориях:
Как заблокировать по IP в NGINX
Блокировать можно с помощью директив allow и deny.
Правила обработки таковы, что поиск идёт сверху вниз. Если IP совпадает с одним из правил, поиск прекращается.
Таким образом, вы можете как забанить все IP, кроме своих, так и заблокировать определённый IP:
Приведу пример конфигурации, как можно закрыть доступ к панели администратора WordPress по IP:
Ещё один неплохой вариант. Правда, по умолчанию определяются только статичные IP. А чтобы разрешить подсеть, придётся использовать дополнительный модуль GEO:
Как в NGINX указать размер и время
Время задаётся в следующих суффиксах:
Рекомендуется всегда указывать суффикс
Некоторые интервалы времени можно задать лишь с точностью до секунд.
Настройка отладки в NGINX
В целях отладки настройки NGINX вы можете писать данные в логи, но я советую воспользоваться директивой add_header. С её помощью вы можете выводить различные данные в http headers.
Пример, как можно определить, в каком location обрабатывается правило:
Отладочная информация 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.
Скачиваем и распаковываем последнюю версию модуля из источника, в моём случае, с GitHub
—add-module=
Эта проблема решается установкой libpcre++-dev :
Эта проблема решается так:
В результате должны увидеть модуль на месте
Основные ошибки nginx и их устранение
502 Bad Gateway
Ошибка означает, что NGINX не может получить ответ от одного из сервисов на сервере. Довольно часто эта ошибка появляется, когда NGINX работает в связке с Apache, Varnish, Memcached или иным сервисом, а также обрабатывает запросы PHP-FPM.
Как правило, проблема возникает из-за отключенного сервиса (в этом случае нужно проверить состояние напарника и при необходимости перезапустить его) либо, если они находятся на разных серверах, проверить пинг между ними, так как, возможно, отсутствует связь между ними.
Также, для PHP-FPM нужно проверить права доступа к сокету.
Для этого убедитесь, что в /etc/php-fpm.d/www.conf прописаны правильные права
504 Gateway Time-out
Ошибка означает, что nginx долгое время не может получить ответ от какого-то сервиса. Такое происходит, если Apache, с которым NGINX работает в связке, отдаёт ответ слишком медленно.
Проблему можно устранить с помощью увеличения времени таймаута.
При работе в связке NGINX+Apache в конфигурационный файл можно внести изменения:
Тут мы выставили ожидание таймаута в 800 секунд.
Upstream timed out (110: Connection timed out) while reading response header from upstream
Причиной может быть сложная и потому долгая обработка php в работе PHP-FPM.
Здесь тоже можно увеличить время ожидания таймаута
800 секунд на ожидание ответа от бекенда.
Это лишь временные меры, так как при увеличении нагрузки на сайт ошибка снова станет появляться. Устраните узкие места, оптимизируйте работу скриптов php
413 Request Entity Too Large
Ошибка означает, что вы пытались загрузить слишком большой файл. В настройках nginx по умолчанию стоит ограничение в 1Mb.
Для устранения ошибки в nginx.conf нужно найти строку
и заменить значение на нужное. Например, мы увеличим размер загружаемых файлов до 100Mb
Также, можно отключить проверку размера тела ответа полностью значением ноль:
Следует помнить, зачем ввели это ограничение: если любой пользователь может загружать файлы на неподготовленный сайт, можно сравнительно легко провести DDOS-атаку на него, перегружая входной поток большими файлами.
После каждого внесённого изменения в конфигурационный файл необходимо перезагружать nginx
304 Not Modified не устанавливается
Правильность ответа 304 Not Modified можно проверить с помощью:
Client intended to send too large body
Решается с помощью увеличения параметра client_max_body_size
Как перезагрузить nginx
Эти команды остановят и перезапустят сервер NGINX.
Перезагрузить конфигурационный файл без перезагрузки NGINX можно так:
Проверить правильность конфигурации можно командой
В чём разница между reload и restart
Как происходит перезагрузка в NGINX:
Короче говоря, restart обрывает работу резко, reload делает это плавно.
Restart рекомендуется использовать, только когда внесены глобальные изменения, например, заменено ядро сервера, либо нужно увидеть результат внесённых изменений прямо здесь и сейчас. В остальных случаях используйте reload.
Как вместо 404 ошибки делать 301 редирект на главную
Как в NGINX сделать редирект на мобильную версию сайта
Данный код вставляется на уровне server в самое начало файла (не обязательно в самое начало, но главное, чтобы перед определением обработчика скриптов php, иначе редирект может не сработать).
Как в NGINX включить поддержку WebP
Чтобы включить поддержку WebP, нужно прописать в секции http :
Теперь, в секции server можно использовать:
Полезные материалы и ссылки
Настройка NGINX под WP Super Cache
В первую очередь, сервис задумывался как переводчик инструкций mod_rewrite с htaccess на nginx. Однако, он позволяет переводить другие инструкции, которые можно и резонно перевести из Apache в nginx.
Инструкции, не относящиеся к настройке сервера (например, php_value), игнорируются.
Переводчик не проверяет правильность входящего конфига, в том числе регулярные выражения и логические ошибки.
Результат перевода следует обязательно проверить вручную, а затем разместить в секции server <> конфигурационного файла nginx.
Замечания и предложения по улучшению ждем, как обычно, на [email protected] 😉