Nginx: что это за веб-сервер и что он меняет для вашего сайта

Что такое Nginx?

Nginx (произносится «энджин-икс») - веб-сервер с открытым кодом. Когда человек вводит адрес в браузере, браузер отправляет запрос, а на другом конце его встречает именно такая программа. Она находит нужный файл или обращается к приложению и возвращает ответ с кодом статуса. Те же запросы, только от роботов, присылают Яндекс и Google.

Автор Nginx - Игорь Сысоев. По материалу cloud.ru, сервер доступен для свободного использования, а помимо бесплатной версии есть платные и родственные сборки: Nginx Plus, Angie и OpenResty. Для российских проектов это значит, что у сервера есть и русскоязычная экосистема, и коммерческая поддержка.

Сайту нужен веб-сервер всегда, даже если вы им не занимаетесь. На обычном хостинге его настраивает провайдер, на VPS или в облаке это делаете вы или подрядчик. Поэтому знать базовые понятия стоит и тем, кто работает с интернетом и сайтами на уровне маркетинга: при медленной странице, цепочке редиректов или ошибке 502 вопрос обычно упирается в настройки веб-сервера. Проверить, что стоит у вас, можно за минуту: команда curl -I с адресом сайта покажет заголовки ответа, и в строке Server часто указан nginx.

Как работает Nginx?

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

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

Количество рабочих процессов задают в конфигурации. Его можно зафиксировать или приравнять к числу ядер процессора, и во многих инструкциях для параметра worker_processes ставят значение auto. Так сервер использует все ядра без ручной подгонки.

• Раздаёт файлы напрямую. Картинки, стили, скрипты и готовые HTML-страницы отдаются с диска без участия приложения.
• Работает как обратный прокси. Принимает запрос и передаёт его приложению на PHP, Python или Node.js, а ответ возвращает клиенту.
• Распределяет нагрузку. Если приложений несколько, Nginx решает, к какому из них отправить очередной запрос.
• Шифрует соединение. На нём обычно подключают сертификат и HTTPS.

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

Чем Nginx отличается от Apache?

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

Цифры обычно приводят для статических файлов. По данным обзора kurshub, в независимых тестах Nginx отдаёт статику в 2,5 раза быстрее Apache при 1000 одновременных соединений. Тот же обзор отмечает, что среди хостингов с общим доступом больше 40% сайтов работают на Apache: причина в файлах .htaccess, которыми клиент сам меняет настройки без доступа к основной конфигурации.

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

Связку из последней строки таблицы описывает и cloud.ru в том же материале: оба сервера можно использовать для одного проекта, и тогда Nginx обрабатывает статический контент, а Apache динамический. Эта схема часто встречается на старых проектах, где менять Apache неоправданно дорого, а выигрыш в скорости статики хочется получить сразу. Так поступил бы владелец магазина на старом движке: логику корзины и заказов он оставляет на Apache, а картинки товаров, стили и скрипты отдаёт через Nginx и сразу получает ускорение статики, о котором говорят тесты в 2,5 раза, без переписывания движка.

Где используют Nginx и что показывают реальные случаи

Масштаб применения хорошо видно по обзору kurshub в уже названном материале: среди тысячи самых посещаемых сайтов мира доля Nginx превышает 60%, а Netflix, Dropbox, WordPress.com и Airbnb выбрали его для обслуживания миллионов пользователей. Для небольшого интернет-магазина или лендинга он подходит по тем же причинам: быстро отдаёт статику и мало потребляет.

Показателен случай Cloudflare. Инженеры компании рассказывали в блоге Cloudflare, что их прокси сегодня обслуживает больше триллиона запросов в сутки. Много лет они строили сервис вокруг Nginx и упёрлись в особенности его устройства: каждый запрос обслуживает один рабочий процесс, и нагрузка на ядра распределяется неравномерно.

Вторая проблема касалась соединений с серверами клиентов. Пул соединений в Nginx принадлежит отдельному рабочему процессу, и чем больше процессов, тем хуже соединения используются повторно. После перехода на собственную систему, написанную на Rust, у одного крупного клиента доля повторно используемых соединений выросла с 87,1% до 99,92%, а расход процессора упал примерно на 70%, памяти - на 67%.

Он был хорош много лет.

Юйчэнь Ву и Эндрю Хаук, инженеры Cloudflare, о NGINX в том же материале

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

Третий сценарий знаком каждому, кто переносил сайт на другой хостинг: после переезда на VPS с Nginx пропадают привычные правила из .htaccess. Редиректы со старых адресов, запрет доступа к служебным папкам и подмена адресов нужно описать заново в конфигурации сервера. Поэтому в чек-лист переезда стоит внести проверку этих правил на тестовом адресе до смены DNS.

Как выглядит настройка и что в ней нужно знать?

Конфигурация состоит из директив. По руководству на nginx.org, основной файл называется nginx.conf и лежит в одном из нескольких каталогов, чаще всего в /etc/nginx. Сервер описывают блоком server: порт в listen, имя домена в server_name, корневая папка в root, правила для адресов внутри location.

1. Подготовьте блок server для домена и укажите, где лежат файлы сайта или адрес приложения для proxy_pass.
2. Проверьте файл командой nginx -t: сервер сообщит о синтаксических ошибках до применения.
3. Примените изменения командой nginx -s reload: управляющие сигналы stop и quit завершают работу быстро или плавно, а reload перезагружает конфигурацию.
4. Откройте сайт и проверьте ответы нужных страниц, редиректы и заголовки.

Для приложения достаточно добавить в location директиву proxy_pass с адресом, на котором оно слушает запросы. Для PHP используют передачу через FastCGI. Остальные параметры, такие как заголовки, таймауты и кэш, добавляют по мере необходимости, и каждое изменение проверяют отдельно, чтобы понимать, что именно повлияло на скорость или поведение страницы.

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

Если вы работаете на CMS, большую часть настроек создаёт панель управления хостингом или сборка вроде LEMP. Об устройстве систем управления сайтом мы писали отдельно, а здесь важно другое: при смене домена, подключении HTTPS или переносе сайта вам понадобятся эти же директивы, и лучше понимать, что именно меняет подрядчик.

Что Nginx даёт SEO и скорости сайта?

Первое - редиректы. Google рекомендует для смены адреса постоянную серверную переадресацию, и в Nginx её настраивают директивой return 301, а по документации nginx.org модуль rewrite умеет менять адрес по регулярным выражениям и делать перенаправления. Из нескольких вариантов адреса главной нужно выбрать один канонический и перенаправлять на него остальные: http на https, www на адрес без www, вариант без слэша на вариант со слэшем.

Второе - сжатие и кэш. Администратор интернет-магазина включил gzip для HTML, стилей и скриптов и проверил размер ответа в браузере. Модуль gzip, по описанию на nginx.org, часто уменьшает объём передаваемых данных вдвое и больше, и в такой проверке размер ответа заметно падает, а уровень сжатия задают числом от 1 до 9. Для картинок и стилей в инструкции cloud.ru в том же материале указано, что период кэширования файлов .jpg, .jpeg, .png, .css составляет 30 дней: это директива expires 30d. Страницы грузятся быстрее, а это влияет и на поведение посетителей, и на метрики скорости.

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

Четвёртое - единая точка контроля. Через Nginx удобно закрыть дубли адресов, убрать служебные папки из доступа и отдавать страницу ошибки 404 с правильным кодом, а не пустую страницу с кодом успеха. Проверьте также robots.txt и карту сайта: они должны открываться без ошибок, иначе роботы не получат правила обхода. Такие настройки входят в техническую часть любой SEO-работы над сайтом.

Какие ошибки чаще всего допускают с Nginx?

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

Вторая - цепочки и петли редиректов. Когда http перенаправляется на https, затем с www на адрес без www, затем со слэшем на вариант без него, робот проходит три перехода вместо одного. Соберите правила в одно условие, чтобы любой старый адрес вёл на финальный за один шаг, и проверьте результат на нескольких типовых адресах.

• Правила из .htaccess перенесли на VPS и забыли описать их в конфигурации.
• Включили сжатие, но не проверили заголовки и типы файлов.
• Закрыли доступ к папке и случайно закрыли файлы, нужные роботу.
• Оставили стандартную страницу ошибки без нужного кода ответа.

Третья - молчаливая пустая страница. Если приложение недоступно, посетитель видит заглушку, а робот получает код успеха вместо кода ошибки, и пустой адрес может попасть в индекс. Представьте магазин, где после правки конфигурации страница каталога стала отвечать ошибкой. Администратор, который проверил файл командой nginx -t и открыл три ключевые страницы, заметил это через минуту, а без проверки узнал бы по падению заказов. Для сбоев отдавайте честный код ответа и короткое понятное сообщение, а о сбоях узнавайте раньше посетителей по мониторингу. Достаточно внешнего сервиса, который раз в минуту проверяет главную и ключевые страницы и пишет в мессенджер, если ответ отличается от нормы.

Частые вопросы