Nginx серверски блокови (Виртуални хостови) за хостовање више сајтова

Nginx серверски блокови представљају концепт виртуалног хоста који вам омогућава да објавите више домена или веб сајтова са одвојеним конфигурацијама на једној Nginx инсталацији. На пример, можете дефинисати различите коренске директоријуме, лог фајлове, SSL сертификате и PHP подешавања за example.com, blog.example.com и drugi-site.com на истом VPS-у. Укратко, решење је: креирати посебан директоријум за сваку локацију, усмерити DNS записе домена на IP адресу сервера, написати одвојен серверски блок под /etc/nginx/sites-available, повезати га са директоријумом sites-enabled, тестирати конфигурацију и поново учитати Nginx сервис.

У овом водичу ћемо се бавити процесом хостовања више сајтова помоћу Nginx серверских блокова на начин који је погодан за продукциону средину. Циљ није само да се успостави функционална структура, већ и да се створи управљив, сигуран, брз, резервно копиран и скалабилан систем. Посебно ћемо делити практичне кораке за агенције, програмере, власнике е-трговине, предузећа која управљају више брендова и систем администраторе који покрећу више пројеката на једном серверу. Ако још увек немате сервер, можете погледати странице за избор ресурса VPS сервер и управљање доменима Регистрација домена.

Шта су Nginx серверски блокови?

Nginx серверски блокови су конфигурациони делови унутар Nginx конфигурације који су дефинисани као server блок и одређују на који сајт ће бити усмерен долазни HTTP или HTTPS захтев. Слично концепту VirtualHost у Apache-у. Када посетилац у претраживач унесе домен, DNS решава тај домен на IP адресу сервера. Након тога Nginx проверава заглавље Host у захтеву и покреће серверски блок који одговара вредности server_name.

Овим путем, на истој IP адреси и истом физичком или виртуалном серверу може бити објављено десетине различитих веб сајтова. Могуће је дефинисати посебан коренски директоријум, логове за приступ, логове грешака, правила преусмеравања, SSL сертификате, политику кеширања и правила безбедности за сваку локацију. На пример, можете држати вашу корпоративну страницу у /var/www/korporativna/public, ваш блог у /var/www/blog/public, а вашу тестну средину у /var/www/staging/public.

Nginx је веома ефикасан у овом структуралном моделу јер захваљујући свом догађајима усмереном архитектонском дизајну може управљати високим паралелним везама уз низак ниво потрошње ресурса. Због тога се често користи у окружењима као што су делјени хостинг, VPS, облачни сервери и инфраструктуре за апликације са високим протоком. Да би више сајтова функционисало здраво, сви детаљи, од дозвола фајлова до DNS усмеравања, од инсталације SSL-а до раздвајања логова, морају бити правилно планирани.

Kада се користе Nginx серверски блокови?

Nginx серверски блокови се користе посебно када је потребно управљати више веб присустава на једном серверу. То могу бити два мала корпоративна сајта, али и десетине пројеката клијената, поддомене или микросервиси. Критична тачка је логичко одвајање сваког пројекта.

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

На пример, технички је могуће да дигитална агенција објави 8 малих корпоративних сајтова на једном 4 GB RAM VPS-у. Међутим, за сваку локацију морају се израчунати проток, коришћење диска, број 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 серверских блокова.

Препоручена структура директоријума

Једна од најчешћих грешака у хостовању више сајтова је чување свих фајлова у једном директоријуму на неуређен начин. Овај приступ може изгледати лако на кратак рок, али озбиљно одлаже процесе одржавања, резервних копија и отклањања грешака. Бољи метод је коришћење одвојеног надреда за свакој домену, а унутар њега јавни, логови, резервне копије и слично.

Пример структуре може бити: /var/www/site1.com/public, /var/www/site1.com/logs, /var/www/site2.com/public и /var/www/site2.com/logs. Nginx root вредност мора указивати директно на јавни директоријум. На тај начин, фајлови апликације, осетљиви фајлови попут .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. Овај метод је здравији од копирања фајлова јер радите на једном главном конфигурационом фајлу. Када направите измене, повезани фајл остаје актуелан.

Aко не желите да подразумевана Nginx страница буде испред вашег сајта, можете онемогућити подразумевану конфигурацију. За то можете уклонити везу /etc/nginx/sites-enabled/default. Међутим, пре него што то урадите, уверите се да ваш серверски блок исправно функционише.

4. Тестирајте конфигурацију и поново учитајте Nginx

Након сваке промене, треба да урадите тест синтаксе командом sudo nginx -t. Ако је тест успешан, можете поново учитати сервис без прекида помоћу команде sudo systemctl reload nginx. Команда reload је обично сигурнија од restart команде, јер управља активним везама на глаткији начин.

Aко тест не буде успешан, порука о грешци обично показује име фајла и број линије. Најчешћи проблеми су недостајућа тачка и запета, погрешна фигурна заграда, погрешан пут до директоријума или конфликтне server_name вредности. Нигде не би требало поново учитати Nginx пре него што се грешка отклони.

Додавање другог и трећег сајта

Лепота хостовања више сајтова је што, након првобитне исправне инсталације, процес постаје могуће поновити. За site2.com креирате директоријум /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 конфигурација

У 2026 SEO стандардима, HTTPS више није само безбедносна функција, већ и показатељ корисничког поверења и техничке квалитете. Претраживачи означавају HTTP сајтове као несигурне; SSL је обавезан за пројекте који укључују плаћање, чланство, форме или управљачке панеле. Када хостујете више сајтова, правилан сертификат мора бити дефинисан за сваку домену. Можете погледати страницу SSL сертификати на Hostragons-у за ваше SSL потребе.

Aко користите Let’s Encrypt, можете се пријавити за сертификат за сваку домену помоћу Certbota. У примеру, команда certbot --nginx -d site1.com -d www.site1.com детектује Nginx конфигурацију и може аутоматски додати HTTPS блок. Међутим, добра пракса је проверити фајл након аутоматске измене. Могу се појавити проблеми са погрешним преусмеравањем или дуплим серверским блоковима.

У конфигурацији HTTPS, обично се 80 порт усмерава на 443 порт трајно. 301 преусмеравање даје сигнал о трајној преференци SEO-у. Одлучите да ли ћете користити www, а затим прикупите све варијације на једној канонској адреси. На пример, ако желите да користите https://site1.com уместо https://www.site1.com, усмерите и HTTP и HTTPS www саобраћај на адресу без 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 достижу исти циљ различитим архитектурама. Обоје могу хостовати више сајтова на једном серверу. Избор зависи од потреба апликације, навика управљања и очекивања у перформансама.

Aко ваша апликација интензивно зависи од .htaccess правила, Apache може изгледати лакше. Међутим, за високе протоке, реверзне проксије, кеширање и модерне дистрибуционе токове, Nginx је снажна опција у већини пројеката. У неким инфраструктурама, Nginx се може користити као реверзни прокси, док Apache служи као сервер апликација на задњем крају.

Најбоље праксе за безбедност

Хостовање више сајтова на истом серверу пружа предности у погледу трошкова; али повећава и одговорност за безбедност. Да би се избегло да рањивост на једном сајту утиче на друге, морају се применити принципи изолације и минималних права.

• Креирајте одвојене базе података и одвојене кориснике база података за сваки сајт.
• Ограничите веб коренски директоријум само на јавну фасциклу.
• Чувајте резервне копије, .env, .git, конфигурационе и SQL фајлове ван веб приступа.
• Редовно обнављајте SSL сертификате и обавезно усмеравајте на HTTPS.
• Користите UFW или сличан безбедносни зид на серверу; отворите само потребне портове.
• Редовно примењујте ажурирања за Nginx и оперативни систем.
• Чувајте одвојене access_log и error_log за сваког сајта.
• Додајте ИП ограничења или додатну аутентификацију на управљачке панеле.
• Избегавајте широка одобрења као што су 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 на не-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 кеша или CDN-а. За потребе глобалног приступа и CDN-а, можете се повезати на садржај као што је Шта је CDN.

Управљање логовима и праћење

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

Да бисте спречили неограничено повећање лог фајлова, требало би да проверите конфигурацију logrotate. За мале пројекте, дневна или недељна ротација може бити довољна. За сајтове са високим протоком, треба користити централизовано прикупљање логова, метрике и системе упозорења. Пун диск може довести до немогућности Nginx-а да запише логове, заустављања базе података и недоступности сајтова. Стога је практично поставити праг за коришћење диска.

Честе грешке и брза решења

Када радите са Nginx серверским блоковима, одређене грешке могу се појавити у скоро сваком пројекту. Познавање истих значајно ће смањити време инсталације.

• Домен отвара погрешан сајт: проверите server_name конфликта и подразумевани серверски блок.
• 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 директоријум, да ли су дозволе исправне, да ли је сервис прошао тест, шта кажу логови? Пратити овим редоследом омогућава вам да брзо решите проблеме без панике.

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

Пре него што одете у продукцију, проверите сваку локацију помоћу следеће контролне листе. Посебно у пројектима клијената, документација ових ставки пре испоруке ствара професионални стандард рада.

• DNS A или AAAA запис усмерава на исправну IP адресу.
• Једна од верзија са www или без www изабрана је као канонска.
• HTTP саобраћај усмерава на HTTPS са 301.
• SSL сертификат је валидан и аутоматско обнављање је активно.
• За сваки сајт дефинисан је посебан root и лог фајл.
• Nginx конфигурација је потврђена помоћу sudo nginx -t.
• Планиран је план резервних копија и тестирана је процедура враћања.
• Дозволе фајлова су у складу са принципом минималних права.
• У безбедносном зиду отворени су само потребни портови.
• Грешке у логовима пратиле су се најмање 15 минута после пуштања у продукцију.

Ова листа изгледа мала, али значајно смањује ризик од прекида у правим пројектима. Посебно кораци попут обнављања SSL-а, провере DNS-а и праћења логова рано откривају већину невидљивих грешака.

Закључак

Nginx серверски блокови су један од основних метода за хостовање више сајтова на једном серверу на уредан, сигуран и перформантан начин. Правилна структура директоријума, одвојени конфигурациони фајлови, јасна правила преусмеравања, коришћење HTTPS, раздвајање логова и редовни тестови чине управљање више сајтова веома ефикасним. Исти принципи се могу применити од малог портфолија до пројеката са више клијената.

Aко планирате да објавите нови пројекат, прво разјасните ваше потребе за доменом, сервером и SSL-ом; затим корак по корак конфигуришите Nginx користећи горњу контролну листу. Ако тражите управљивију инфраструктуру, можете погледати решења Hostragons-а Хостинг пакети, VPS сервер и SSL сертификати како бисте пронашли одговарајућу почетну тачку за ваш пројекат.

Често постављана питања

Колико сајтова се може хостовати са 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 фајлове.