Настройки nginx для production: архитектура, конфиг и типичные ошибки

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

Категории

Статья также доступна на украинском (перейти к просмотру).

Разбор архитектуры nginx, логики server и location, полезные настройки, логирование и работы с PHP-FPM

Содержание:

Выбор веб-сервера обычно зависит от многих показателей, основными из которых являются производительность, ресурсоемкость и совместимость со многими ОС. Общепризнанным лидером по указанным характеристикам является веб-сервер с открытым кодом Nginx. Он почти вдвое опережает Apache по скорости обработки подключений статического контента, позволяющего эффективно обеспечивать работу на VPS или выделенном сервере PHP-сайтов. Это становится возможным потому, что nginx не «просто веб-сервер», а HTTP-прокси из event-driven архитектурой и широкими возможностями зума. Рассмотрим более подробно его возможности и устройство.

Архитектура nginx

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

На Рисунку 1 приведена высокоуровневая архитектура веб-сервера Nginx.

Рисунок 1.Архитектура веб-сервера Nginx.

Опираясь на приведенную схему, сформируем концептуальные основы внутреннего строения веб-сервера и принципы организации обработки HTTP-запросов:

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

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

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

Максимальное количество одновременных соединений для одного worker-процесса может быть установлена ??с помощью параметра worker_connections в конфигурационном файле. Стандартное значение – 512 соединений на одно worker. При этом следует учитывать, что указанное значение не может превышать текущий лимит на максимальное значение количества открытых в Linux файлов для одного процесса

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

Принципы обработки запросов подчиняются асинхронным неблокирующим event-driven алгоритмам: worker-процессы никогда не блокируются и ожидают появления событий на сокетах соединения и прослушивания; при появлении события на сокете соединение worker формирует ответ клиенту; при появлении происходящего на сокете прослушивания создается новый сокет соединения для обслуживания нового клиента.

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

Но во всем остальном – вопросы безопасности, ресурсоемкость, скорость обработки статических данных – Nginx опережает многих своих конкурентов.

Как nginx выбирает server и location

КонфигурацияNginx представлена ??в виде иерархии блоков: http / server / location, что оптимизирует процесс избрания обработчиков для выполнения запросов.

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

Пример определения конфигурации одного сервера:

server {
listen 80;
server_name mysite.ua;
root /var/www/mysite;
}

Приведенная конфигурация обеспечит ответы веб-сервера на HTTP-запросы от домена mysite.ua, которые будут поступать на порт 80. Имя домена определено директивой server_name.

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

Процесс избрания обработчика запроса в Nginx происходит в следующей последовательности:

На первом этапе выбирается серверный блок путем сравнения порта, адреса клиента и заголовка хоста с установленными значениями директивserver_name та listen.

На втором этапе выбирается блок location, определенный в пределах избранного серверного блока Критерием его выбора есть соответствие URI запросавсем возможным совпадением.

На третьем этапе корректируется выбор блока location путем внутреннего перенаправление, определяемое с помощью таких директив, как rewrite, index, try_files або error_page. В таком случае инициируется поиск необходимого блока location в пределах выбранного сервера.

В случае, если у несколькихсерверных блоках указаны одинаковые значения IP-адреса и порта,запускается процедура сравнения заголовка Host запросасо значением директивы server_name каждого блокадля поиска наиболее удачного совпадения.

Server_name

Директива server_name может содержать знаки для подстановки, имена или регулярные выражения. При этом порядок оценки будет следующим:

Точное совпадение;
Начальный знак подстановки;
Конечный знак подстановки;
Совпадение с регулярным выражением;
Стандартный сервер в случае, если совпадение не найдено.

Примеры:

Точное совпадение:

server {
listen 80;
server_name *.mysite.ua;
}
Початковий знак підстановки:
 server {
listen 80;
server_name *.mysite.ua;
}
Кінцевий знак підстановки:
server {
listen 80;
server_name www.mysite.*;
}

Конечный знак подстановки:


server {
listen 80;
server_name www.mysite.*;
}

Использование блока location

Процесс сопоставления URI при выборе блока location может осуществляться несколькими способами:

По точному совпадению;
С помощью префиксов (Prefix);
Посредством регулярных выражений (regex).

Точное совпадение определяется с помощью так называемых модификаторов, например, символа «=». В случае наличия модификатора «~» происходит оценка регистрозависимого регулярного выражения. При этом сервер проверяет URI запроса на соответствие шаблону regex и использует первое совпадение.

Если модификатор не найден, применяется скоростной поиск по префиксу, который лучше всего подходит для статического контента и маршрутизации на основе директорий.
Пример точного совпадения:

location = /index.php {
root /var/www/mysite;

Пример поиска по префиксу:

location /myfile/ {
root /var/www/static;

Здесь модификатор не указан, и потому поиск сразу происходит по префиксу. Приведенный блок обеспечит обработку запросов для всех URI, которые начинаются с /myfile/,например, /myfile/logo.jpg или /myfile/buf/sel/.

Пример поиска по регулярному выражению:

location /myfile/ {
root /var/www/static;
}

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

Базовый production- набор директив

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

sendfile. Обеспечивает передачу файлов между файловыми дескрипторами в пространстве ядра без ресурсных потерь на переключение контекста. Использование директивы заменяет собой операции чтения и записи и позволяет осуществлять записи из блочного устройства в буфер ядра через механизм ДМА. Используется совместно с директивами tcp_nodelay и tcp_nopush, которые прописываются в nginx.conf.

tcp_nodelay. Позволяет отправлять данные в буфер ядра вне зависимости от размеров пакета данных. Использование директивы позволяет оптимизировать задержки и экономить до двух сотен миллисекунд времени на каждый HTTP-запрос.

tcp_nopush. Это противоположность директиве. tcp_nodelay.Она позволяет оптимизировать количество передаваемых данных за один проход.

keepalive_timeout. Задает время, в течение которого TCP-соединение может быть открыто для повторного использования. Использование keepalive-соединений позволяет многократно использовать сокеты, не создавая при этом новых соединений и не загрязняя таблицу сокетов. Это повышает производительность за счет снижения нагрузки на ядро ??и увеличения пропускной способности при высоком уровне RPS (Requests Per Second).

client_max_body_size. Позволяет установить максимально возможный размер тела запроса клиента. В случае превышения установленного значения клиенту возвращается ошибка 413 (Request Entity Too Large). Установка значения "0" отключает указанную проверку.
types_hash_max_size. Установка максимального размера записи в хэш-таблицах MIME-типов. Стандартные значения – 4k, 8k.

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

Журнал доступа – access_log;
Журнал ошибок – error_log.

Журнал доступа используется для хранения записей обо всех запросах клиентов. При появлении каждого нового запроса в журнал сразу же заносится соответствующая запись. Такая запись обычно содержит следующие поля: Timestamp; IP-адрес клиента; IP-адрес ресурса, в отношении которого производится запрос, а также другие поля для сохранения дополнительных данных о клиенте. Файл журнала находится по адресу: /var/log/nginx/access.log.

Типичный вывод лог-записи из журнала доступа может быть следующим:

73.81.251.135 - - [23/Jan/2026:15:33:05 +0300] "GET /favicon.ico HTTP/1.1" 404 197 "http://86.175.69.317/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0"

Настроить журнал доступа можно как на уровне Nginx (файл nginx.conf), так и на уровне отдельного веб-ресурса в директории /etc/nginx/conf.d.

Для его настроек используются параметры log_format и access_log. Первый задает формат лога и данные для логирования. Второй указывает путь к местонахождению журнала для фиксации событий.

Получить более подробную информацию по настройке журнала можно в документации Nginx.

Журнал ошибок error_log используется для фиксации следующих типов ошибок:

Связанные с получением доступа к файлов;
Проблемы подключения к backend-серверов;
Ошибки конфигурации;
Проблемы с SSL;
Внутренние ошибки сервера (ошибки 5xx).

Файл журнала ошибок находится по адресу: /var/log/nginx/error.log.

Типичный вывод лог-записи из журнала ошибок может быть следующим:

23/Jan/2026:16:25:03 [error] 1456#7865: *10 open() "/var/www/html/mypage.html" failed (2: No such file or directory), client: 127.0.0.1, server: myserver.ua, request: "GET /mypage.html HTTP/1.1", host: "mysite.ua"

Можно настроить журнал ошибок, как и журнал доступа – на уровне сервера и для отдельных сайтов.
Для его настроек используются параметры log_format и error_log, имеющие те же значения, что и для журнала доступа.

Для обоих типов журналов применяются восемь уровней логирования, определяющих тип события: debug, info, notice, warn, error, crit, alertи emerg.

Правильное использование логов позволяет:

Продиагностировать работу сайта;
Проанализировать трафик;
Решить вопросы безопасности;
Выполнить оптимизацию.

Диагностирование

Для целей диагностики часто требуется знать время выполнения запроса. Его можно получить с помощью переменной $request_time, создав специальный формат логов Созданный формат можно использовать в конфигурациях различных сайтов, указав его в соответствующем серверном блоке.
Также может быть полезной переменная $upstream_response_time, которая фиксирует время, от момента установления соединения до получения последнего байта тела запроса от вверх по upstream-сервера. Принцип ее использования такой же, как и $request_time.

Приведем пример:

http {
log_format my_up_t '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent"'
'rt="$request_time" uct="$upstream_connect_time" uht="$upstream_header_time" urt="$upstream_response_time"';
server {
access_log /var/logs/nginx-access.log my_up_t;
...
}

Здесь my_up_t – имя созданного дополнительного формата логов, в котором мы определяем переменные $request_time и $upstream_response_time.

Попробуем применить наши знания о логах для диагностики работы нашего веб-ресурса. К примеру, в случае заторможенности сайта, в файле access.log мы обязательно увидим значительное количество запросов с большим значением переменной $request_time. А в файле error.log – сообщение 504 Gateway Timeout или вообще ничего. В этом случае с помощью переменных необходимо обнаружить все «длинные» запросы и проверить backend.

nginx + PHP-FPM

PHP-FPM – это альтернативная реализация FastCGI для PHP, которая лучше всего подходит для высоконагруженных сайтов и желательна для применения вместе со скоростным Nginx.

Основные этапы подготовки PHP-FPM для Nginx:

Установка PHP-FPM;
Конфигурирование FPM-пула;
Настройка Nginx;
Тестирование совместной работы Nginx и PHP-FPM.

Для того, чтобы серверный блок Nginx смог использовать пул FPM, в файле nginx.conf следует указать путь к файлу FPM-пулу с помощью параметра fastcgi_pass внутри блока location block для php.
Пример настроек серверного блока Nginx для сайта на WordPress:

server {
        listen       80;
        server_name  new.mysite.ua;
        root         /var/www/html/wordpress;
        access_log /var/log/nginx/ new.mysite.ua-access.log;
        error_log  /var/log/nginx/ new.mysite.ua-error.log error;
         index index.html index.htm index.php;
        location / {
                     try_files $uri $uri/ /index.php$is_args$args;
         }
        location ~ \.php$ {
           fastcgi_split_path_info ^(.+\.php)(/.+)$;
           fastcgi_pass unix:/var/run/php7.5-fpm-wordpress-site.sock;
           fastcgi_index index.php;
           include fastcgi.conf;
   }
}

Здесь директива try_files применена с целью перенаправления запросов PHP на единую точку входа (файл index.php) в случае отсутствия нужных файлов.

Выводы

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

Важно не просто хорошо ранжироваться, важно быть там, где пользователи ищут ответы на свои запросы.
Подписывайтесь на наш Telegram-канал https://t.me/freehostua, чтобы быть в курсе новых полезных материалов

Смотрите наш канал YouTube на https://www.youtube.com/freehostua.

Мы в чем ошиблись, или что-то пропустили?

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

Настройки nginx для production