Налаштування nginx для production: архітектура, конфіг і типові помилки

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

Категорії

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

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

Зміст:

Вибір веб-серверу, зазвичай, залежить від багатьох показників, основними з яких є продуктивність, ресурсоємність та сумісність із багатьма ОС. Загальновизнаним лідером за вказаними характеристиками є веб-сервер з відкритим кодом Nginx. Він майже у два рази випереджає Apache за швидкістю обробки підключень статичного контенту, що дозволяє ефективно забезпечувати роботу на VPS або виділеному сервері PHP-сайтів, створених на базі WordPress, Laravel та багатьох інших CMS. Це стає можливим тому, що nginx – це не «просто веб-сервер», а HTTP-проксі із event-driven архітектурою та широкими можливостями масштабування. Розглянемо більш детально його можливості та будову.

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

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

На Малюнку 1 наведена високорівнева архітектура веб-серверу Nginx.

Архітектура веб-сервера 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, що оптимізує процес обрання обробників для виконання запитів.

Всі запити, котрі надходять до веб-серверу, проходять жорсткий етап оцінювання на предмет визначення способу їх обробки. Спосіб обробки запитів задається вмістом серверних блоків server, прописаних у конфігураційному файлі. Кожен такий блок визначає віртуальний сервер із рядом мережевих параметрів для обробки відповідних запитів. Це такі параметри, як порт, 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 host3.mysite.ua;
} 
Початковий знак підстановки:
server {
listen 80;
server_name *.mysite.ua;
}

Кінцевий знак підстановки:

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 ~ \.(jpe?g|ico|gif)$ {
root /var/www/myfiles;
}

Блок забезпечить обробку запитів зображень, визначених у виразі типів. У порівнянні із пошуком за префіксом, ці запити будуть виконуватися значно повільніше, а також можуть ускладнити відлагодження.

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

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

sendfile. Забезпечує передачу файлів між файловими дескрипторами у межах простору ядра без ресурсних втрат на перемикання контексту. Використання директиви замінює собою операції читання та запису та дозволяє здійснювати записи з блочного пристрою у буфер ядра через механізм DMA. Використовується сумісно із директивами 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.

Логи та діагностика

Nginx під час своєї роботи використовує два типи журналів:

Журнал доступу – 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