nginx: как устроен веб-сервер и шлюз перед приложением

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

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

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

Настройки хранятся в файлах, главный из которых обычно называется nginx.conf. Внутри выделяют контексты: http, server, location. Блок server описывает виртуальный хост с портом и именем, а location — правила для конкретных путей запроса.

Типичная запись location указывает корневой каталог для статики либо директиву proxy_pass с адресом внутреннего приложения. Каждый server выбирается по имени из заголовка Host или по SNI, на что указывает директива server_name.

Отдача статических файлов: изображения, стили, скрипты. Шлюз перед приложением на другом языке, при этом nginx завершает TLS и передаёт запросы на внутренний порт. Балансировка между несколькими серверами через блок upstream. Перенаправление с HTTP на HTTPS, кэширование ответов и ограничение частоты запросов.

Эти роли подробно раскрыты на странице про балансировщик нагрузки.

Ещё один частый сценарий — перенаправление с адреса без www на адрес с ним, объединение нескольких доменов под одним сайтом и отдача страниц-заглушек при техническом обслуживании с кодом 503.

Отключайте вывод версии директивой server_tokens off, не оставляйте открытыми служебные страницы статуса, ограничивайте размер тела запроса и держите ПО обновлённым. Сертификаты подключают директивами ssl_certificate и ssl_certificate_key, а поддерживаемые версии TLS ограничивают современными.

Частая ошибка новичков — неверный порядок правил location и лишние слэши в proxy_pass, которые меняют передаваемый путь и дают неожиданный результат.

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

Для защиты от перегрузки применяют директивы limit_req и limit_conn, задающие допустимую частоту запросов и число соединений с одного адреса.

Синтаксис конфигурации проверяет команда nginx -t, а применить изменения без остановки сервиса позволяет перезагрузка конфигурации. Журналы доступа и ошибок находятся обычно в каталоге /var/log/nginx, и именно там ищут причину кодов 502 и 504.

Заблуждение: nginx только раздаёт статику. Он давно стал универсальным шлюзом. Другое заблуждение — что nginx сам выполняет PHP или Python: код исполняется отдельным процессом. Определить, что сайт работает на nginx, можно по заголовку Server в ответе, если администратор его не скрыл.

Для просмотра актуальной конфигурации целиком используют nginx -T: команда выводит итоговую конфигурацию со всеми подключёнными файлами.

При проблемах начинайте с журнала ошибок. Ошибка «connection refused» при передаче запроса приложению означает, что внутреннее приложение не слушает нужный порт. «Upstream timed out» указывает на слишком долгий ответ приложения; увеличивать таймаут стоит, только если задержка ожидаема, а не как способ скрыть неполадку.

Ошибка 413 говорит, что тело запроса больше допустимого предела, который задаёт директива client_max_body_size. Ошибка 404 при существующем файле часто вызвана неверным корневым каталогом или порядком правил. Для проверки, какой блок server сработал, помогает отдельное имя в заголовке ответа или временное сообщение в журнале.

После изменений полезно проверить сайт снаружи и убедиться, что ответ содержит ожидаемые заголовки, включая HSTS, если он включён.