Хостинг на множество сайтов с Nginx сървърни блокове (виртуални хостове)

Nginx сървърните блокове представляват концепция за виртуален хост, която ви позволява да хоствате множество домейни или уебсайтове с отделни конфигурации на един единствен Nginx инсталация. Например, можете да дефинирате различни коренови директории, лог файлове, SSL сертификати и настройки на PHP за example.com, blog.example.com и second-site.com на същия VPS. В кратце, решението е: да създадете отделна директория за всеки сайт, да насочите DNS записките на домейна към IP адреса на сървъра, да напишете отделен сървърен блок под /etc/nginx/sites-available, да създадете символична връзка в директорията sites-enabled, да тествате конфигурацията и да презаредите Nginx услугата.

В това ръководство ще разгледаме процеса на хостинг на множество сайтове с Nginx сървърни блокове по начин, подходящ за продукционна среда. Целта не е само да създадете работеща структура; а да изградите управляем, сигурен, бърз, резервируем и мащабируем ред. Особено ще споделим практични стъпки за агенции, разработчици, собственици на електронна търговия, бизнеси, които управляват множество марки, и системни администратори, които работят с множество проекти на един сървър. Ако все още нямате сървър, можете да прегледате страниците за избор на ресурс VPS сървър и управление на домейни Регистрация на домейн.

Какво представляват Nginx сървърните блокове?

Nginx сървърните блокове са конфигурационни части, определящи коя уебстраница да бъде насочена при получаване на HTTP или HTTPS заявка, описани в конфигурацията на Nginx като сървърен блок. Това е подобно на концепцията за VirtualHost от Apache. Когато посетител напише домейн в браузъра, DNS разрешава този домейн до IP адреса на сървъра. След това Nginx проверява заглавката Host на заявката и активира сървърния блок, чиято стойност server_name съвпада.

Така на един и същ IP адрес и на един и същ физически или виртуален сървър могат да бъдат публикувани десетки различни уебсайтове. Възможно е да зададете отделни коренови директории, логове за достъп, логове за грешки, правила за пренасочване, SSL сертификати, политики за кеш и правила за сигурност за всеки сайт. Например, можете да съхранявате корпоративния си сайт в /var/www/corporate/public, блога си в /var/www/blog/public, а тестовата си среда в /var/www/staging/public.

Nginx е изключително ефективен в тази структура, тъй като благодарение на своята събитийна архитектура може да управлява високи нива на съвременни връзки с ниска консумация на ресурси. Поради това, той е предпочитан в среди за споделен хостинг, VPS, облачни сървъри и инфраструктури на приложения с висок трафик. За да функционира правилно хостингът на множество сайтове, всяка детайлна част трябва да бъде планирана правилно, от разрешенията на файловете до DNS пренасочванията, от инсталацията на SSL до разделението на логовете.

Кога да се използват Nginx сървърни блокове?

Nginx сървърните блокове се използват особено когато трябва да управлявате множество уеб присъствия на един единствен сървър. Това могат да бъдат две малки корпоративни сайта или десетки клиентски проекти, поддомейни или микроуслуги. Критичната точка тук е логичното разделение на всеки проект.

• Ако искате да публикувате множество домейни на един и същ VPS.
• Ако искате да пренасочите www и non-www домейни към един каноничен адрес.
• Ако искате да свържете поддомейни с различни папки или приложения.
• Ако искате да дефинирате отделни SSL сертификати и политики за сигурност за всеки сайт.
• Ако искате да следите клиентските проекти с отделни лог файлове.
• Ако искате да стартирате различни приложения като Laravel, WordPress, статичен HTML и Node.js на един и същ сървър.

Например, технически е възможно един дигитален агент да публикува 8 малки корпоративни сайта на един VPS с 4 GB RAM. Въпреки това, за всеки сайт трябва да се изчисли трафикът, използването на диск, броят на PHP процесите, натоварването на базата данни и честотата на резервирането. Ако проектите получават интензивен трафик или изолацията на ресурсите е критична, трябва да се предпочетат по-мощни VPS, облачни сървъри или управлявани хостинг решения. В този момент могат да се сравняват Уеб хостинг и Корпоративен хостинг опции.

Изисквания преди започване

В това ръководство ще предположим, че работим с Linux сървър, базиран на Ubuntu или Debian. Командите могат да имат малки разлики в зависимост от дистрибуцията; обаче логиката остава същата. Важно е да направите резервно копие преди да извършите операции в продукционна среда. Неправилна Nginx конфигурация може да доведе до временно недостъпност на всички сайтове.

Необходими технически подготовки

• Потребителски акаунт в Linux с root или sudo права.
• Инсталирана и работеща Nginx услуга.
• Най-малко един домейн насочен към IP адреса на сървъра.
• Отворени портове 80 и 443 в защитната стена.
• Редовна структура на директории за файловете на сайта.
• Валиден сертификат за SSL или използване на безплатен Let’s Encrypt.
• Инсталиране на PHP-FPM за PHP-базирани приложения.

От страна на DNS, A записа насочва основния домейн към IPv4 адреса, а AAAA записа, ако е наличен, към IPv6 адреса. За поддомейни като www могат да се използват CNAME или A запис. DNS разпространението обикновено завършва в рамките на няколко минути до 24 часа. Когато правите нова инсталация, подгответе DNS записите първо, след което преминете към конфигурацията на Nginx сървърни блокове, за да ускорите процеса.

Предложена структура на директории

Една от най-често срещаните грешки при хостинг на множество сайтове е да се съхраняват всички файлове в една директория. Този подход може да изглежда лесен в краткосрочен план, но значително забавя процесите по поддръжка, резервно копие и отстраняване на грешки. По-добър метод е да се използват отделни главни директории за всеки домейн и в тях поддиректории като public, logs, backups.

Примерна структура може да бъде планирана по следния начин: /var/www/site1.com/public, /var/www/site1.com/logs, /var/www/site2.com/public и /var/www/site2.com/logs. Nginx root стойността трябва да сочи директно към public директорията. По този начин файловете на приложението, чувствителните файлове като .env и резервите не могат да бъдат достъпни директно през уеб.

За примерна статична тестова страница можете да поставите прост index.html файл във всяка сайтова папка. В него можете да напишете името на сайта, за да потвърдите бързо кой сървърен блок работи. В продукционни среди собствеността на тези папки обикновено се управлява от потребителя www-data или от специален потребител, който извършва разгръщането. При разрешенията на файловете, 755 за папки и 644 за файлове обикновено са достатъчни за повечето статични сценарии. В приложения, които изискват запис, като WordPress, области като uploads трябва да бъдат оценени допълнително.

Стъпка по стъпка създаване на 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. Създайте файла на сървърния блок

Обичайната практика в Nginx е да се съхраняват неактивните конфигурации в /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 страница да предшества сайта ви, можете да деактивирате конфигурацията по подразбиране. За целта можете да премахнете връзката /etc/nginx/sites-enabled/default. Въпреки това, уверете се, че вашият собствен сървърен блок работи правилно, преди да направите това.

4. Тествайте конфигурацията и презаредете Nginx

След всяка промяна, командата sudo nginx -t трябва да се използва за тестване на синтаксиса. Ако тестът е успешен, командата sudo systemctl reload nginx ще презареди услугата без прекъсване. reload командата обикновено е по-сигурна от restart, тъй като управлява активните връзки по-гладко.

Ако тестът е неуспешен, съобщението за грешка обикновено показва името на файла и номера на реда. Липсващи точка и запетая, неправилни фигурни скоби, грешни пътища на директории или конфликтуващи server_name стойности са най-често срещаните проблеми. Nginx не трябва да се презарежда, докато грешката не бъде отстранена.

Добавяне на втори и трети сайт

Красотата на хостинга на множество сайтове е, че след правилната първоначална настройка процесът може да бъде повторен. Създавате директория /var/www/site2.com/public, пишете файла /etc/nginx/sites-available/site2.com, променяте root и лог стойностите на site2.com, създавате символична връзка и стартирате теста на Nginx.

Простата структура за втория сайт може да бъде написана по следния начин: 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

Според SEO стандартите за 2026 г. HTTPS вече не е само функция за сигурност, а показател за доверие на потребителите и техническо качество. Браузърите маркират HTTP сайтовете като несигурни; SSL е задължителен в проекти, съдържащи плащания, членства, формуляри или административни панели. При хостинг на множество сайтове, правилният сертификат трябва да бъде зададен за всеки домейн. Можете да проверите страницата за SSL сертификати на Hostragons за вашите нужди SSL сертификати.

Ако използвате Let’s Encrypt, можете да получите сертификат за всеки домейн с Certbot. Примерният процес е: certbot --nginx -d site1.com -d www.site1.com, който разпознава конфигурацията на Nginx и автоматично добавя HTTPS блока. Въпреки това, добра практика е да проверите файла след автоматичното редактиране. Могат да възникнат проблеми с неправилни пренасочвания или повтарящи се сървърни блокове.

При конфигурацията на HTTPS, трафикът на порт 80 обикновено се пренасочва постоянно на порт 443. 301 пренасочването дава постоянен сигнал за предпочитание от SEO гледна точка. Решете дали да използвате www или не и обединете всички вариации на един каноничен адрес. Например, ако ще използвате https://site1.com вместо https://www.site1.com, уверете се, че трафикът от www по HTTP и HTTPS се пренасочва към адрес без www. Това намалява риска от дублирано съдържание.

Nginx сървърни блокове за PHP и WordPress сайтове

Конфигурацията за статични HTML сайтове е проста; обаче за WordPress, Laravel или специализирани PHP приложения е необходимо интегриране с PHP-FPM. В този случай се дефинира index.php файл и PHP заявките се насочват към съответния сокет. Например, на Ubuntu пътят на сокета за PHP 8.3 може да бъде /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. Ако хоствате множество WordPress сайтове на един VPS, използвайте отделна база данни, отделен потребител и редовна политика за актуализация за всеки сайт. За тези, които търсят алтернатива за WordPress хостинг, WordPress хостинг може да бъде по-управляемо решение.

Сравнение на Nginx сървърни блокове с Apache VirtualHost

Nginx и Apache постигат същата цел с различни архитектури. И двете могат да хостват множество сайтове на един и същ сървър. Изборът зависи от нуждите на приложението, управленските навици и очакванията за производителност.

Ако приложението ви е силно зависимо от правилата на .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 могат да бъдат оценени в подходящи проекти. Въпреки това, особено Content-Security-Policy, ако не се приложи правилно, може да блокира скриптове и стилови файлове; затова трябва да бъде тестван първо в тестова среда. За допълнително съдържание относно сигурността могат да бъдат предоставени линкове към Сигурност на уебсайт статии.

Внимание за производителност и SEO

Nginx сървърните блокове влияят не само на публикуването, но и на качеството на производителността и SEO. Неправилните вериги за пренасочване, грешните канонични предпочитания, липсваща gzip или brotli компресия, големи лог файлове и недостатъчни настройки на кеша могат да забавят сайта. Сигналите за опит на страницата на Google са потребителски ориентирани; бързо реагиращите, сигурни и стабилни сайтове имат тенденция да показват по-добра производителност.

Първо, задайте един каноничен вариант за всеки домейн. Направете пренасочване от HTTP към HTTPS, от www към non-www или обратно в една стъпка. Верига не трябва да бъде: http://site.com първо http://www.site.com, след това https://www.site.com, след това https://site.com. Вместо това, по-добре е да се насочите директно с един 301.

За статичните файлове могат да се използват заглавия cache-control. Изображенията, CSS и JS файлове могат да се съхраняват в браузъра за определен период. Въпреки това, за често променящи се файлове, стратегията за версиониране на името на файла или query string трябва да бъде използвана. gzip компресията намалява широчината на лентата за текстови файлове като HTML, CSS, JS и JSON. За сайтове с висок трафик могат да се оценят Nginx microcache, FastCGI cache или CDN. За нуждите на CDN и глобален достъп можете да предоставите линк към съдържание като Какво е CDN.

Управление на логове и наблюдение

Управлението на логовете при хостинг на множество сайтове е ключът към решаване на проблеми. Отделните лог файлове ясно показват къде и какъв проблем се е случил. access_log записва заявките на посетителите, а error_log записва конфигурации, разрешения, проблеми с намирането на файлове и upstream грешки. Грешката 502 Bad Gateway обикновено е свързана с PHP-FPM или връзка с бекенд услуга. Грешката 403 Forbidden може да е свързана с проблеми с разрешенията или индекс файловете. Грешката 404 Not Found може да сигнализира за неправилен път на файла, rewrite проблеми или неправилна root структура след DNS.

За да предотвратите безкрайното нарастване на лог файловете, трябва да проверите конфигурацията на logrotate. За малки проекти дневната или седмичната ротация може да е достатъчна. За сайтове с висок трафик трябва да се използват централизирано събиране на логове, мониторинг на метрики и системи за предупреждения. Запълването на диска може да доведе до невъзможност на Nginx да записва логове, спиране на базата данни и недостъпност на сайтовете. Поради това е практична мярка да се зададат прагови стойности за използването на диска.

Често срещани грешки и бързи решения

При работа с 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 правилен ли е, активна ли е конфигурацията на Nginx, налична ли е root папката, правилни ли са разрешенията, премина ли услугата теста, какво казва логът? Следването на тази последователност позволява бързо решение без паника.

Практически контролен списък за продукционна среда

Преди да преминете в живо производство, проверете всеки сайт с помощта на следния контролен списък. Особено в клиентски проекти, документирането на тези точки преди предаване създава професионален стандарт на работа.

• A или AAAA записа на домейна насочва към правилния IP адрес.
• Едната версия от www и non-www е избрана канонично.
• HTTP трафикът е пренасочен към HTTPS с 301.
• SSL сертификатът е валиден и автоматичното подновяване е активно.
• Определени са отделни коренови и лог файлове за всеки сайт.
• Nginx конфигурацията е проверена с sudo nginx -t.
• План за резервно копие е определен и тест на възстановяване е извършен.
• Разрешенията на файловете са в съответствие с принципа на минимални права.
• В защитната стена са отворени само необходимите портове.
• Грешките в логовете са наблюдавани най-малко 15 минути след преминаване в живо производство.

Този списък може да изглежда малък, но в реални проекти значително намалява риска от прекъсване. Особено стъпките за подновяване на SSL, проверка на DNS и наблюдение на логовете ранно откриват повечето невидими проблеми.

Заключение

Nginx сървърните блокове са един от основните методи за редовно, сигурно и производително хостване на множество сайтове на един сървър. Правилната структура на директориите, отделните конфигурационни файлове, ясните правила за пренасочване, използването на HTTPS, разделението на логовете и редовният тестов процес правят управлението на множество сайтове изключително ефективно. Същите принципи могат да се прилагат от малък портфолио сайт до множество клиентски проекти.

Ако планирате да публикувате нов проект, първо уточнете нуждите си от домейн, сървърен ресурс и SSL; след това следвайте контролния списък по-горе, за да настроите конфигурацията на Nginx стъпка по стъпка. Ако търсите по-управляеми инфраструктурни решения, можете да изберете подходяща отправна точка, преглеждайки Хостинг пакети, VPS сървър и SSL сертификати решенията на Hostragons.

Често задавани въпроси

С колко сайта може да хоствате с Nginx сървърни блокове?

Технически можете да хоствате много сайтове на един сървър с Nginx; границата обикновено зависи от CPU, RAM, диск, трафик, натоварване на базата данни и капацитета на PHP-FPM. Докато десетки сайтове могат да бъдат хоствани за статични сайтове с нисък трафик, за натоварени WordPress или електронни търговски проекти е по-здравословно да се хостват по-малко сайтове.

Трябва ли отделен SSL сертификат за всеки сайт?

Да, всеки домейн или поддомейн, който ще бъде публикуван чрез HTTPS, трябва да бъде включен в обхвата на сертификата. Могат да се използват отделни сертификати, както и SAN или wildcard сертификати. Важно е Nginx 443 сървърен блок да свързва правилните сертификатни файлове с правилния домейн.

Може ли да се публикува поддомейн с Nginx сървърен блок?

Да. Можете да дефинирате отделен server_name за поддомейни като blog.site.com или panel.site.com и да ги насочите към различна коренова директория или различно бекенд приложение. От страна на DNS, трябва да създадете A или CNAME запис за съответния поддомейн.

Каква е разликата между sites-available и sites-enabled?

sites-available е мястото, където се съхраняват наличните конфигурационни файлове; sites-enabled съдържа активните конфигурации. Обикновено в sites-enabled се създава символична връзка към файла в sites-available. Този метод прави активирането и деактивирането на сайтовете по-организирано.

Какво да правя, ако отварям грешен сайт?

Най-честите причини са неправилно насочване на DNS към неправилния IP, грешна стойност на server_name, улавяне на заявките от подразбиращия се Nginx блок или неправилно работа на SSL блока на порта 443. Проверете първо DNS записите, след което изхода на nginx -t, активните връзки в sites-enabled и съответния access_log файл.