Правильна настройка nginx перетворює звичайний сервер на надійний інструмент, здатний витримувати тисячі одночасних з’єднань без надмірного споживання ресурсів. Конфігураційні файли визначають, як обробляються запити, куди передається трафік і які механізми безпеки застосовуються.
Основна структура будується навколо блоків http, server і location, а сучасні версії (станом на 2026 рік) підтримують HTTP/2, TLS 1.3 і гнучке балансування навантаження. Грамотна настройка nginx дозволяє одночасно обслуговувати статичний контент, працювати як reverse proxy і забезпечувати високу продуктивність навіть на обмеженому обладнанні.
У цій статті розкрито механізми обробки запитів, практичні кроки конфігурації, типові помилки та способи діагностики, щоб як початківець, так і досвідчений адміністратор міг побудувати стабільну систему.
Як nginx обробляє запити всередині
Nginx працює за подієво-орієнтованою моделлю. Головний процес (master) читає конфігурацію, створює worker-процеси і передає їм сокети. Кожен worker використовує механізм epoll (на Linux) або kqueue (на FreeBSD) і може одночасно тримати тисячі відкритих з’єднань, не створюючи окремий потік на кожне.
Коли приходить запит, nginx спочатку вибирає відповідний server-блок за IP, портом і значенням server_name. Далі відбувається пошук location за пріоритетом: точне співпадіння (=), префікс з найдовшим шляхом, регулярні вирази (~ і ~*). Після вибору location виконується або віддача файлу з диска, або proxy_pass, або fastcgi_pass.
Ця схема пояснює, чому неправильний порядок location-блоків часто призводить до неочікуваної поведінки. Worker-процеси не діляться станом між собою, тому всі змінні та ліміти задаються на рівні конфігурації або shared memory zones.
Структура конфігураційних файлів і базові директиви
Головний файл зазвичай розташований у /etc/nginx/nginx.conf. Він містить глобальні параметри (user, worker_processes, error_log), блок events і блок http. Всередині http підключаються додаткові файли через include /etc/nginx/conf.d/*.conf або /etc/nginx/sites-enabled/*.
Ключові директиви:
- worker_processes auto; — автоматично підлаштовується під кількість ядер CPU.
- worker_connections 4096; — максимальна кількість з’єднань на один worker.
- worker_rlimit_nofile 65535; — піднімає ліміт відкритих файлів, щоб уникнути помилок «too many open files».
- server_tokens off; — приховує версію сервера в заголовках і сторінках помилок.
Після будь-якої зміни обов’язково виконується перевірка синтаксису командою nginx -t. Якщо тест пройшов успішно, застосовується reload: systemctl reload nginx або nginx -s reload. Це дозволяє оновити конфігурацію без розриву активних з’єднань.
Покрокова настройка для статичного сайту
Для простого сайту створюється окремий файл у /etc/nginx/sites-available/example.com і символічне посилання в sites-enabled.
Мінімальна робоча конфігурація виглядає так:
listen 80;
listen [::]:80;
server_name example.com www.example.com;
root /var/www/example.com;
index index.html index.htm;
location / {
try_files uriuri/ =404;
}
location ~ /. {
deny all;
access_log off;
log_not_found off;
}
}
Після створення каталогу з файлами сайту, встановлення правильних прав (зазвичай www-data:www-data) і перевірки конфігурації сайт стає доступним. Для початківців цього достатньо, щоб швидко вивести сторінку в інтернет. Досвідчені користувачі одразу додають окремі access_log і error_log для зручності аналізу.
Настройка reverse proxy і upstream
Коли додаток працює на внутрішньому порту (наприклад, Node.js на 3000 або PHP-FPM на 9000), nginx виступає як reverse proxy. Upstream-блок дозволяє описати кілька бекендів і правила балансування.
least_conn;
server 127.0.0.1:3000 weight=3;
server 127.0.0.1:3001;
keepalive 32;
}
server {
listen 80;
server_name api.example.com;
location / {
proxy_pass http://backend;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Connection “”;
proxy_connect_timeout 5s;
proxy_read_timeout 30s;
}
}
Параметр least_conn направляє новий запит на бекенд із найменшою кількістю активних з’єднань. Keepalive зменшує витрати на встановлення TCP-з’єднань між nginx і бекендом. Для PHP використовується fastcgi_pass і набір параметрів із snippets/fastcgi-php.conf.
У нашій практиці ми стикалися з випадком, коли відсутність proxy_set_header Host призводила до того, що додаток отримував неправильне ім’я хоста і генерував помилкові посилання.
HTTPS, сертифікати та базове посилення безпеки
Сучасна настройка nginx майже завжди включає TLS. Найпростіший шлях — certbot з плагіном nginx:
certbot –nginx -d example.com -d www.example.com
Certbot автоматично додає listen 443 ssl, шляхи до сертифікатів і редирект з HTTP. Для ручної конфігурації важливо вказати:
- ssl_protocols TLSv1.2 TLSv1.3;
- ssl_ciphers з сучасними наборами (ECDHE + AES-GCM або CHACHA20);
- ssl_session_cache shared:SSL:10m;
- ssl_session_tickets off;
Додаткові заголовки безпеки розміщують у server-блоці:
add_header X-Frame-Options DENY always;
add_header X-Content-Type-Options nosniff always;
add_header Referrer-Policy “strict-origin-when-cross-origin” always;
Відключення server_tokens і правильні права на файли сертифікатів — обов’язкові кроки, які зменшують поверхню атаки вже на етапі базової настройки nginx.
Оптимізація продуктивності під сучасні навантаження
Станом на 2026 рік типові рекомендації для сервера з 4–8 ядрами виглядають так:
| Параметр | Рекомендоване значення | Примітка |
|---|---|---|
| worker_processes | auto | Дорівнює кількості ядер |
| worker_connections | 4096–8192 | З урахуванням worker_rlimit_nofile |
| keepalive_timeout | 65 | Баланс між ресурсами і швидкістю |
| gzip | on + gzip_types | Стискає текст, CSS, JS, JSON |
| sendfile | on | Ефективна віддача статичних файлів |
Дані базуються на офіційній документації nginx.org та практичних тестах спільноти.
Додатково вмикають open_file_cache, обмежують розмір тіла запиту (client_max_body_size) і використовують limit_req_zone для захисту від надмірної кількості запитів з однієї IP-адреси.
Поширені помилки при настройці nginx
- Відсутність крапки з комою після директиви — nginx -t одразу показує «invalid parameter».
- Неправильний порядок location — префікс без ^~ може перекриватися регулярним виразом, і запит йде не туди, куди очікували.
- Використання uri замістьrequest_uri в rewrite або proxy — призводить до подвійного декодування і потенційних вразливостей.
- Запуск worker-процесів від root — критична помилка безпеки; завжди user www-data; або nginx.
- Відсутність try_files при статичній роздачі — nginx може намагатися виконати неіснуючі скрипти.
- Ігнорування error_log — багато проблем видно лише там, а не в access_log.
Кожна з цих помилок легко перевіряється командою nginx -t і переглядом логів. Виправлення займає хвилини, але наслідки можуть бути серйозними.
Діагностика проблем: що робити, коли щось пішло не так
Перший крок завжди — nginx -t. Якщо синтаксис у порядку, дивляться systemctl status nginx і tail -f /var/log/nginx/error.log. Типові повідомлення «bind() to 0.0.0.0:80 failed» вказують на зайнятий порт, «permission denied» — на права доступу до файлів або каталогів.
Для аналізу трафіку зручно тимчасово підвищити рівень логування (error_log … debug;) і після збору даних повернути звичайний рівень. Команда ss -tlnp | grep nginx показує, які порти реально слухаються.
За моїм досвідом використання цього протягом місяця на кількох проектах, найбільше часу економить звичка завжди перевіряти конфігурацію перед reload і тримати окремі логи для кожного віртуального хоста.
Чек-лист самоперевірки після настройки nginx
- nginx -t повертає «syntax is ok» і «test is successful».
- systemctl is-active nginx показує active.
- curl -I http://localhost повертає очікуваний код і заголовки.
- Сертифікати валідні (ssl_certificate і ssl_certificate_key вказані правильно).
- server_tokens off; присутній у конфігурації.
- Права на root-каталоги сайтів не дозволяють запис від користувача nginx.
- Ліміти rate і connection налаштовані для критичних location.
- Логи ротуються і не заповнюють диск.
Пройшовши цей список, можна бути впевненим, що базова настройка nginx виконана коректно.
Коли можна впоратися самому, а коли варто звернутися до фахівця
Базову установку, статичний сайт, reverse proxy для одного додатку і отримання Let’s Encrypt сертифіката більшість адміністраторів виконують самостійно за кілька годин. Складніші сценарії — георозподілене балансування, складні правила WAF, інтеграція з Kubernetes Ingress, налаштування mTLS між сервісами — уже вимагають досвіду і часу на тестування.
Якщо після кількох спроб error.log продовжує показувати незрозумілі повідомлення, або сайт під навантаженням починає віддавати 502/504, раціональніше залучити спеціаліста. Це економить години (а іноді й дні) і знижує ризик тривалого простою.
Питання, які найчастіше ставлять під час настройки nginx
Чому після reload сайт віддає стару сторінку?
Браузер або проміжний кеш. Додайте Cache-Control або виконайте curl з заголовком, що обходить кеш.
Як обмежити доступ лише з певних IP?
Використовуйте allow/deny всередині location або geo-модуль для складніших правил.
Чи потрібно завжди вмикати gzip?
Так для текстового контенту. Для вже стиснутих форматів (jpeg, mp4, zip) gzip_types не включають їх, щоб не витрачати CPU.
Що робити з великими файлами завантаження?
Підвищіть client_max_body_size і client_body_timeout, а також переконайтеся, що бекенд теж готовий приймати великий обсяг даних.
Як перевірити, що HTTP/2 працює?
curl -I –http2 https://example.com має показати HTTP/2 200.
Настройка nginx — це не одноразова дія, а процес, який супроводжує життєвий цикл будь-якого веб-проекту. Зрозуміла структура конфігурації, регулярна перевірка синтаксису і увага до логів дозволяють тримати сервер стабільним навіть при зростанні навантаження. Офіційна документація на nginx.org залишається найнадійнішим джерелом актуальних директив і прикладів.
