Nginx: что это и как он обрабатывает запросы сайта

Nginx — программа, которая принимает HTTP-запросы от браузеров и других клиентов. Она может сама отдать файл с диска, перенаправить посетителя на другой адрес или передать запрос приложению, запущенному, например, на Node.js, Python или PHP.

На собственном VPS Nginx часто становится входной точкой сайта: слушает порты 80 и 443, выбирает конфигурацию домена и решает, кто сформирует ответ. Это не движок сайта и не панель управления. Он не создаёт страницы WordPress и не заменяет код приложения.

Где Nginx находится в схеме сайта

Путь обычного запроса выглядит так:

1. DNS сообщает браузеру IP-адрес домена.
2. Браузер устанавливает соединение с сервером и передаёт HTTP-запрос.
3. Nginx принимает запрос на настроенном адресе и порту.
4. По домену и пути он выбирает правило обработки.
5. Ответ возвращается браузеру по тому же соединению.

Если запрошен /images/logo.webp, Nginx может прочитать готовый файл. Если запрошен /api/orders, он может направить обращение приложению на локальный порт 3000. Внешний посетитель при этом не соединяется с портом 3000 напрямую.

Передачу входящего запроса внутреннему серверу называют обратным проксированием, или reverse proxy. Слово «обратный» отличает его от обычного proxy, который представляет клиента при выходе в интернет. Reverse proxy представляет один или несколько серверов перед клиентом.

Как Nginx выбирает нужный сайт

В конфигурации сайта используется блок server. Директива listen задаёт адрес и порт, а server_name — имена доменов. Когда несколько сайтов слушают один адрес, Nginx сначала учитывает адрес и порт соединения, затем сравнивает имя из HTTP-запроса с server_name.

Если подходящего имени нет, запрос обрабатывает сервер по умолчанию для этого адреса и порта. Поэтому страница «Welcome to nginx» вместо вашего сайта часто означает не поломку файлов, а попадание в чужой или стандартный блок server.

Внутри выбранного сайта блоки location сопоставляются с путём запроса. Путь /assets/app.css относится к URI — части адреса после домена. Он не обязан совпадать с физическим путём на диске: это определяется директивами root, alias, proxy_pass и другими правилами.

Статические файлы и приложение

Ниже показана упрощённая конфигурация для домена example.com. Это пример для чтения: путь к файлам и адрес приложения нужно заменить своими значениями.

server {
    listen 80;
    server_name example.com www.example.com;

    root /var/www/example.com/public;
    index index.html;

    location /assets/ {
        try_files $uri =404;
    }

    location /api/ {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

root задаёт каталог, из которого Nginx ищет файлы. Для /assets/app.css получится путь /var/www/example.com/public/assets/app.css. try_files $uri =404 отдаёт файл, только если он существует, иначе возвращает 404.

Во втором location запросы с началом /api/ передаются приложению на loopback-адресе 127.0.0.1:3000. Loopback доступен внутри самого сервера. Заголовки сообщают приложению исходный домен, адрес цепочки клиентов и протокол внешнего запроса. Приложение должно доверять таким заголовкам только от известного reverse proxy, иначе клиент сможет подставить их сам.

Завершающий слеш в proxy_pass влияет на путь, который увидит приложение. Не меняйте его по догадке: сначала определите, ожидает ли приложение /api/orders или /orders, затем сверьтесь с документацией модуля.

Полная настройка передачи запросов разобрана отдельно в статье о reverse proxy Nginx.

Почему у Nginx несколько процессов

Главный процесс читает конфигурацию и управляет рабочими процессами. Рабочие процессы принимают соединения и обрабатывают запросы. Такая модель позволяет применить новую конфигурацию без резкого обрыва всех текущих соединений.

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

Как узнать, что Nginx уже работает

Следующие команды выполняются на Linux-сервере пользователем с правом читать состояние служб. Они ничего не меняют.

nginx -v
systemctl status nginx --no-pager

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

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

Как проверить конфигурацию перед reload

После правки сначала сохраните резервную копию конкретного файла. Затем на сервере выполните диагностическую команду:

sudo nginx -t

Команда проверяет синтаксис и пытается открыть указанные в конфигурации файлы. Успешный вывод заканчивается сообщениями о корректном синтаксисе и успешном тесте. Если названы файл и строка, не выполняйте reload: откройте это место, исправьте ошибку и повторите тест.

Только после успешной проверки примените конфигурацию:

sudo systemctl reload nginx

Команда не должна выводить ошибку. Сразу проверьте состояние службы и ответ сайта:

systemctl is-active nginx
curl --include https://example.com/

Замените example.com своим доменом. Первая команда должна вывести active. Во второй найдите ожидаемый HTTP-код и заголовки именно вашего сайта. Код 200 не всегда обязателен: настроенное перенаправление может вернуть 301 или 308.

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

Где искать причину ошибки

Симптом	Наиболее полезная проверка
Открывается стандартная страница Nginx	совпадают ли server_name, порт и фактический Host
Статический файл возвращает 404	какой путь построен из root и URI, существует ли файл
Nginx возвращает 502 Bad Gateway	запущено ли приложение и слушает ли адрес из proxy_pass
Ответ 403	есть ли право пройти по каталогам и прочитать файл, не запрещает ли доступ правило
После правки ничего не изменилось	редактировался ли активный файл и был ли выполнен успешный reload

Полную собранную конфигурацию показывает sudo nginx -T. Она может содержать домены, пути и другие внутренние сведения, поэтому не публикуйте вывод целиком. Журналы запросов и ошибок помогают связать проблему с конкретным временем и доменом; их чтение разобрано в статье о логах Nginx.

Когда Nginx действительно полезен

Nginx подходит, если нужно:

• обслуживать несколько доменов на одном сервере;
• отдавать статические файлы без участия приложения;
• завершать HTTPS-соединение и передавать запрос локальному сервису;
• ограничивать размер запроса или время ожидания;
• распределять обращения между несколькими экземплярами приложения;
• управлять кешированием и сжатием на входной точке.

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

Источники

• Nginx: руководство для начинающих
• Nginx: как обрабатывается запрос
• Nginx: модуль ngx_http_proxy_module
• Nginx: настройка HTTPS-серверов