Nginx серверні блоки для кількох сайтів

Nginx серверні блоки — це механізм віртуальних хостів, який дозволяє розміщувати на одному сервері декілька доменів або сайтів з окремими конфігураціями. Наприклад, на одному VPS можна налаштувати різні кореневі каталоги, лог-файли, SSL-сертифікати та PHP-параметри для example.com, blog.example.com і druhyj-sajt.com. Основна ідея: створити для кожного сайту окрему папку, спрямувати DNS-записи доменів на IP сервера, створити окремий серверний блок у /etc/nginx/sites-available, активувати його символічним посиланням у sites-enabled, перевірити конфігурацію і перезавантажити Nginx.

У цій статті ми покроково розглянемо, як правильно налаштувати Nginx серверні блоки для хостингу кількох сайтів у продакшн-середовищі. Мета — не просто запустити сайт, а зробити це керовано, безпечно, швидко, з резервним копіюванням і можливістю масштабування. Ці рекомендації будуть корисні для агентств, розробників, власників інтернет-магазинів, компаній із кількома брендами та системних адміністраторів, які керують багатьма проектами на одному сервері. Якщо у вас ще немає сервера, ознайомтеся з нашим матеріалом про VPS сервер, а для вибору доменного імені — з Реєстрація домену.

Що таке Nginx серверні блоки?

Nginx серверні блоки (server blocks) — це частини конфігурації, які визначають, як обробляти HTTP та HTTPS запити для різних доменів. Це аналог VirtualHost в Apache. Коли користувач вводить адресу сайту в браузері, DNS переводить домен у IP сервера. Потім Nginx дивиться на заголовок Host і запускає відповідний серверний блок, де прописаний цей домен (server_name).

Завдяки цьому на одному IP і одному сервері можна розміщувати десятки сайтів з різними кореневими папками, логами, правилами переадресації, SSL-сертифікатами, політиками кешування та заходами безпеки. Наприклад, корпоративний сайт можна зберігати у /var/www/corporate/public, блог — у /var/www/blog/public, а тестову версію — у /var/www/staging/public.

Nginx дуже ефективний у такій архітектурі, оскільки працює на подієвій моделі, що дозволяє обробляти велику кількість одночасних з’єднань при мінімальному споживанні ресурсів. Саме тому він популярний для shared-хостингу, VPS, хмарних серверів і високонавантажених сайтів. Проте для стабільної роботи потрібно правильно налаштувати права доступу, DNS, SSL, логування та інші деталі.

Коли використовувати Nginx серверні блоки?

Nginx серверні блоки особливо корисні, коли потрібно керувати кількома вебресурсами на одному сервері. Це може бути пара невеликих корпоративних сайтів або кілька десятків клієнтських проектів, субдоменів чи мікросервісів. Головне — логічне розділення між проєктами.

Якщо потрібно розмістити кілька доменів на одному VPS.
Якщо хочете перенаправляти www і без www на один канонічний домен.
Якщо субдомени мають вести на різні каталоги або застосунки.
Якщо для кожного сайту потрібен свій SSL та політика безпеки.
Якщо хочете вести окремі логи для різних проєктів.
Якщо на одному сервері працюють різні застосунки: Laravel, WordPress, статичні HTML-сайти, Node.js тощо.

Наприклад, агентство може розмістити на одному VPS з 4 ГБ оперативної пам’яті до 8 невеликих корпоративних сайтів. Але слід враховувати трафік, навантаження на CPU, PHP-процеси, базу даних і частоту резервного копіювання. Якщо проєкти дуже популярні або потрібна ізоляція ресурсів — варто обрати потужніший VPS, хмарний сервер або керований хостинг. Порівняти варіанти можна на сторінках Веб-хостинг і Корпоративний Хостинг.

Вимоги перед початком

У цьому посібнику ми припускаємо, що працюємо на сервері з Ubuntu або Debian. Команди можуть трохи відрізнятися для інших дистрибутивів, але суть однакова. Перед змінами на продакшн-сервері обов’язково зробіть резервну копію, адже помилка в конфігурації Nginx може призвести до недоступності всіх сайтів.

Необхідна підготовка

Користувач Linux з root або sudo правами.
Встановлений і запущений Nginx.
Принаймні один домен, спрямований на IP сервера.
Відкриті порти 80 і 443 у файрволі.
Організована структура каталогів для сайтів.
Дійсний SSL-сертифікат або налаштований безкоштовний Let’s Encrypt.
Для PHP-застосунків — встановлений PHP-FPM.

DNS-запис A направляє основний домен на IPv4 адресу, AAAA — на IPv6 (якщо є). Для субдоменів типу www застосовують CNAME або A записи. Поширення DNS може займати від кількох хвилин до 24 годин. Щоб прискорити процес, спершу налаштуйте DNS, потім переходьте до конфігурації Nginx.

Покрокове створення Nginx серверного блоку

Нижче наведено приклад на основі домену site1.com. Аналогічно можна додати другий, третій і більше сайтів. Головне — унікальні server_name, root та лог-файли для кожного.

1. Створіть папку сайту

Спочатку створюємо каталог для файлів: sudo mkdir -p /var/www/site1.com/public. Потім додаємо тестовий файл /var/www/site1.com/public/index.html з текстом «Це тестова сторінка site1.com».

Встановіть правильного власника: sudo chown -R www-data:www-data /var/www/site1.com. Якщо деплой виконує інший користувач, налаштуйте групові права відповідно. Уникайте прав 777 — це загроза безпеці, адже так зловмисники можуть завантажувати небажані файли.

2. Створіть файл серверного блоку

Зазвичай конфігурації зберігають у /etc/nginx/sites-available, а активують через символічні посилання у /etc/nginx/sites-enabled. Приклад: /etc/nginx/sites-available/site1.com.

Приклад базової конфігурації HTTP:

server {  
    listen 80;  
    server_name site1.com www.site1.com;  
    root /var/www/site1.com/public;  
    index index.html index.htm;  
    access_log /var/log/nginx/site1.com.access.log;  
    error_log /var/log/nginx/site1.com.error.log;  
    location / {  
        try_files $uri $uri/ =404;  
    }  
}

Тут listen 80 приймає HTTP-запити, server_name визначає домени, root — каталог сайту, index — головний файл, try_files повертає 404, якщо файл не знайдено. Для статичних сайтів цього достатньо.

3. Активуйте сайт

Створіть символічне посилання: sudo ln -s /etc/nginx/sites-available/site1.com /etc/nginx/sites-enabled/site1.com. Це зручніше за копіювання, бо всі зміни відразу застосовуються.

Якщо не хочете, щоб стандартна сторінка Nginx перекривала ваш сайт, деактивуйте дефолтний блок: sudo rm /etc/nginx/sites-enabled/default. Перед цим переконайтеся, що ваш блок працює коректно.

4. Перевірте конфігурацію і перезавантажте Nginx

Після кожної зміни запускайте перевірку: sudo nginx -t. Якщо помилок немає, оновіть конфігурацію без простою: sudo systemctl reload nginx. Команда reload більш безпечна, ніж restart, бо не розриває активні підключення.

Якщо виникають помилки, повідомлення вкажуть рядок і тип проблеми — пропущена крапка з комою, неправильна дужка, невірний шлях або конфлікт server_name. Не перезавантажуйте Nginx, поки помилки не виправите.

Додавання другого і третього сайту

Перевага Nginx у тому, що процес можна повторювати. Для site2.com створіть папку /var/www/site2.com/public, файл /etc/nginx/sites-available/site2.com з унікальними параметрами root і логів, активуйте символічне посилання і протестуйте.

Приклад конфігурації для другого сайту:

server {  
    listen 80;  
    server_name site2.com www.site2.com;  
    root /var/www/site2.com/public;  
    index index.html;  
    access_log /var/log/nginx/site2.com.access.log;  
    error_log /var/log/nginx/site2.com.error.log;  
    location / {  
        try_files $uri $uri/ =404;  
    }  
}

Відокремлені логи допомагають швидко знаходити проблеми. Наприклад, збільшення кількості 404 помилок на одному сайті можна виявити без впливу на інші. Також можна відстежувати трафік, атаки ботів і помилки продуктивності по кожному ресурсу окремо.

Налаштування SSL і HTTPS

З 2026 року HTTPS — це не просто безпека, а й фактор ранжування у SEO та довіри користувачів. Браузери позначають HTTP-сайти як небезпечні, а для платіжних форм, особистих кабінетів і адмінпанелей SSL обов’язковий. Для кожного домену потрібно налаштувати власний сертифікат. Перегляньте варіанти на сторінці сертифікати SSL.

Якщо ви використовуєте Let’s Encrypt, сертифікати можна отримати через Certbot: команда certbot --nginx -d site1.com -d www.site1.com автоматично налаштує HTTPS. Після автоматичного оновлення конфігурації рекомендуємо перевірити файл — іноді виникають проблеми з дублюванням серверних блоків або некоректними редиректами.

Зазвичай HTTP-трафік (порт 80) перенаправляють на HTTPS (порт 443) за допомогою 301 редиректу — це сигнал пошуковим системам про постійне перенесення. Визначте, чи використовуватимете www, і налаштуйте всі варіанти (http, https, www, без www) на один канонічний URL. Наприклад, якщо вибрали https://site1.com, то перенаправляйте весь www-трафік туди, щоб уникнути дублювання контенту.

Nginx серверні блоки для PHP та WordPress

Для статичних сайтів конфігурація проста, але WordPress, Laravel та інші PHP-застосунки потребують інтеграції з PHP-FPM. У такому випадку додають підтримку index.php і перенаправлення PHP-запитів до PHP-FPM сокету. Наприклад, для PHP 8.3 на Ubuntu шлях до сокета може бути /run/php/php8.3-fpm.sock.

Приклад для PHP-сайту:

server {  
    listen 80;  
    server_name wordpress-site.com www.wordpress-site.com;  
    root /var/www/wordpress-site.com/public;  
    index index.php index.html;  
    location / {  
        try_files $uri $uri/ /index.php?$args;  
    }  
    location ~ \.php$ {  
        include snippets/fastcgi-php.conf;  
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;  
    }  
}

Для WordPress важливо, щоб постійні посилання працювали через try_files $uri $uri/ /index.php?$args. Також варто обмежити доступ до xmlrpc.php, wp-login.php, заборонити запуск PHP у uploads і впровадити інші заходи безпеки. Якщо на одному VPS розміщено багато WordPress-сайтів, кожен має мати власну базу даних, користувача і регулярне оновлення. Для зручнішого керування можна розглянути WordPress хостинг.

Порівняння Nginx серверних блоків з Apache VirtualHost

Обидва вебсервери дозволяють хостити кілька сайтів на одному сервері, але мають різну архітектуру і підходи.

Порівняння Nginx серверних блоків з Apache VirtualHost
Критерій	Nginx серверні блоки	Apache VirtualHost
Продуктивність	Ефективний при великій кількості одночасних з’єднань з низьким навантаженням на ресурси.	Залежить від модулів і процесів, може споживати більше ресурсів.
Конфігурація	Централізована і проста в управлінні.	Гнучкість через .htaccess, що дозволяє змінювати налаштування на рівні папок.
Обробка статичних файлів	Швидка і оптимізована.	Добре працює, але зазвичай повільніше за Nginx.
Виконання PHP	Через PHP-FPM.	Можливі варіанти mod_php або PHP-FPM.
Сценарії використання	Ідеальний для реверс-проксі, високонавантажених і сучасних застосунків.	Підходить для старих застосунків із залежністю від .htaccess та спільного хостингу.

Якщо ваш сайт сильно залежить від .htaccess, Apache може бути простішим. Але для високого навантаження, кешування та сучасних технологій Nginx зазвичай кращий вибір. Іноді їх використовують разом: Nginx як реверс-проксі, Apache як бекенд.

Кращі практики безпеки

Розміщення кількох сайтів на одному сервері економить кошти, але підвищує вимоги до безпеки. Щоб вразливість одного ресурсу не впливала на інші, дотримуйтеся принципів ізоляції та найменших привілеїв.

Для кожного сайту створюйте окрему базу даних і користувача.
Обмежуйте кореневу папку сайту лише папкою public.
Зберігайте резервні копії, .env, .git, конфігураційні та SQL файли поза веб-доступом.
Регулярно оновлюйте SSL-сертифікати і налаштовуйте обов’язковий HTTPS.
Використовуйте UFW або інші файрволи, відкривайте лише необхідні порти.
Оновлюйте Nginx і систему безпеки.
Ведіть окремі access_log і error_log для кожного сайту.
Обмежуйте доступ до панелей керування IP-адресами або двофакторною аутентифікацією.
Уникайте прав типу 777 на файлах і папках.

Додатково рекомендуємо додати базові заголовки безпеки: X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Content-Security-Policy. Останній слід тестувати, щоб не блокувати потрібні скрипти і стилі. Більше порад можна знайти у статтях на тему Безпека веб-сайту.

Оптимізація продуктивності і SEO

Nginx серверні блоки впливають не тільки на роботу сайту, а й на його SEO. Неправильні перенаправлення, відсутність канонічних URL, неактивоване стиснення gzip або brotli, великі лог-файли і слабкі кеш-політики знижують швидкість і позиції в пошуку. Google орієнтується на досвід користувача: швидкі, безпечні та стабільні сайти мають перевагу.

Визначайте єдиний канонічний домен для кожного сайту. Виконуйте редиректи з HTTP на HTTPS і з www на без www (або навпаки) за один крок (301). Уникайте ланцюжків типу http://site.com → http://www.site.com → https://www.site.com → https://site.com.

Для статичних ресурсів встановлюйте заголовки Cache-Control, щоб браузери зберігали їх певний час. Для часто оновлюваних файлів використовуйте версіонування і query string. Стиснення gzip економить трафік для HTML, CSS, JS і JSON. Для великих сайтів корисні microcache, FastCGI cache або CDN. Детальніше про CDN читайте у матеріалі Що таке CDN.

Логування і моніторинг

Управління логами — ключ до швидкого усунення проблем на багатосайтному сервері. Окремі файли доступу (access_log) і помилок (error_log) дозволяють чітко бачити, на якому сайті що відбувається. Access_log фіксує запити від відвідувачів, error_log — проблеми з конфігурацією, правами, відсутністю файлів або помилками PHP-FPM.

Наприклад, 502 Bad Gateway вказує на проблеми з PHP-FPM або бекендом, 403 Forbidden — на проблеми з правами чи відсутністю індексного файлу, 404 Not Found — на неправильну директиву root або правила rewrite. Щоб логи не розросталися безконтрольно, налаштуйте logrotate. Для невеликих сайтів достатньо щоденного або тижневого ротації. Для великих — рекомендується централізований збір логів і моніторинг.

Переповнений диск може призвести до відмови у записі логів і збою роботи сайту. Тому встановлюйте порогові значення використання диску і контролюйте їх у реальному часі.

Типові помилки і як їх швидко виправити

Під час роботи з Nginx серверними блоками часто зустрічаються такі проблеми:

Відкривається неправильний сайт — перевірте server_name на конфлікти і наявність default server блоку.
403 Forbidden — перевірте права на root каталог, наявність індексних файлів.
404 Not Found — перевірте шлях root і директиву try_files.
502 Bad Gateway — перевірте статус PHP-FPM і шлях до сокета.
SSL-сертифікат не відповідає домену — перевірте server_name у 443 блоці і файли сертифікатів.
Цикл перенаправлень — спростіть правила редиректів HTTP/HTTPS і www.
Nginx не перезавантажується — виправте синтаксис згідно з повідомленням sudo nginx -t.

Досвідчені адміністратори використовують простий чекліст: DNS вказує на сервер, конфігурація активна, root каталог існує, права коректні, тест пройшов, логи чисті. Цей порядок допомагає швидко розв’язувати проблеми без паніки.

Чекліст перед запуском у продакшн

Перед публікацією сайту перевірте:

DNS A або AAAA записи спрямовані на правильний IP.
Визначено канонічну версію з www або без.
HTTP редиректиться на HTTPS з кодом 301.
SSL-сертифікат дійсний і налаштовано автоматичне оновлення.
Для кожного сайту вказані окремі root і лог-файли.
Конфігурація пройшла перевірку sudo nginx -t.
Налагоджено план резервного копіювання і перевірено відновлення.
Права на файли і папки відповідають принципу мінімальних прав.
Фаєрвол відкриває лише необхідні порти.
Логи помилок моніторилися щонайменше 15 хвилин після запуску.

Хоч цей список і здається простим, він суттєво знижує ризик збоїв і проблем. Особливо важливі пункти з SSL, DNS та логами — вони часто виявляють приховані помилки.

Висновок

Nginx серверні блоки — це надійний і гнучкий спосіб керувати кількома сайтами на одному сервері, забезпечуючи безпеку, продуктивність і зручність адміністрування. Правильна структура каталогів, роздільні конфігурації, коректні редиректи, HTTPS, логування та регулярне тестування роблять процес керування багатосайтністю ефективним і безболісним. Ці принципи однаково добре підходять як для невеликих портфоліо, так і для масштабних клієнтських проєктів.

Плануючи запуск нового сайту, спочатку визначте домен, ресурси сервера і SSL. Потім крок за кроком налаштуйте Nginx за цим чеклістом. Якщо хочете простіше керування, зверніть увагу на рішення Hostragons: Пакети хостингу, VPS сервер та сертифікати SSL, які допоможуть швидко стартувати.

Часті питання

Скільки сайтів можна розмістити на одному Nginx сервері?

Технічно можна розмістити дуже багато сайтів — обмеження залежать від ресурсів CPU, RAM, диска, трафіку, навантаження на базу даних і PHP-FPM. Для невеликих статичних сайтів це можуть бути десятки, а для ресурсомістких WordPress або інтернет-магазинів — менше.

Чи потрібен окремий SSL-сертифікат для кожного сайту?

Так, для кожного домену чи субдомену, який працює через HTTPS, потрібен сертифікат. Можна використовувати окремі сертифікати або SAN (Subject Alternative Name) та wildcard-сертифікати. Важливо, щоб у 443 серверному блоці Nginx були вказані правильні файли сертифікатів для відповідного домену.

Чи можна публікувати субдомени через серверні блоки?

Звичайно. Для субдоменів типу blog.site.com або panel.site.com створюйте окремий server_name і вказуйте потрібний root каталог або бекенд. Не забудьте додати відповідний A або CNAME запис у DNS.

Чим відрізняються каталоги sites-available і sites-enabled?

Sites-available — це місце зберігання всіх доступних конфігураційних файлів, а sites-enabled — це активні конфігурації, які підключені через символічні посилання. Такий підхід полегшує включення і відключення сайтів без видалення файлів.

Чому відкривається неправильний сайт?

Найпоширеніші причини — DNS вказує на неправильний IP, server_name в конфігурації вказаний некоректно, стандартний (default) серверний блок перехоплює запит або помилки в SSL-блоці. Почніть з перевірки DNS, далі виконайте sudo nginx -t, перевірте активні посилання у sites-enabled і логи доступу.

Як налаштувати Nginx серверні блоки для хостингу кількох сайтів на одному сервері