Nginx Server Blockovi (Virtual Hosts) za Hosting Više Web Stranica

Nginx server blockovi su virtualni host koncept koji vam omogućuje da objavite više domena ili web stranica s različitim konfiguracijama unutar jedne Nginx instalacije. Na primjer, možete definirati različite korijenske direktorije, log datoteke, SSL certifikate i PHP postavke za example.com, blog.example.com i drugi-site.com na istom VPS-u. Ukratko, rješenje uključuje: kreiranje zasebnog direktorija za svaku stranicu, usmjeravanje DNS zapisa domene na IP adresu servera, pisanje zasebnog server bloka pod /etc/nginx/sites-available, povezivanje s direktorijem sites-enabled, testiranje konfiguracije i ponovno učitavanje Nginx servisa.

U ovom vodiču ćemo se posvetiti procesu hostinga više stranica uz pomoć Nginx server blockova na način koji je prikladan za produkcijsko okruženje. Cilj nije samo postaviti funkcionalnu infrastrukturu, već stvoriti upravljiv, siguran, brz, rezervni i skalabilan sustav. Podijelit ćemo praktične korake posebno za agencije, programere, vlasnike e-trgovina, tvrtke koje upravljaju višestrukim markama i sistemske administratore koji pokreću više projekata na jednom serveru. Ako još nemate server, možete istražiti stranice za odabir resursa VPS server i upravljanje domenama na Registracija domene .

Što su Nginx Server Blockovi?

Nginx server blockovi su dijelovi konfiguracije unutar Nginx-a koji su definirani kao server block i određuju na koju stranicu će biti usmjeren HTTP ili HTTPS zahtjev. Slični su konceptu VirtualHost u Apache-u. Kada posjetitelj upiše domenu u preglednik, DNS prevodi tu domenu u IP adresu servera. Nakon toga, Nginx gleda na Host zaglavlje u zahtjevu i pokreće onaj server block koji odgovara server_name vrijednosti.

Na taj način, na istom IP adresu i na istom fizičkom ili virtualnom serveru može se objaviti desetke različitih web stranica. Moguće je definirati zasebne root direktorije, pristupne logove, logove grešaka, pravila preusmjeravanja, SSL certifikate, politike cache-a i sigurnosne pravila za svaku stranicu. Na primjer, možete zadržati svoju korporativnu stranicu u /var/www/korporativna/public, svoj blog u /var/www/blog/public, a svoj testni okoliš u /var/www/staging/public.

Nginx je u ovom okviru vrlo učinkovit jer zahvaljujući svojoj arhitekturi orijentiranoj na događaje može upravljati visokim brojem simultanih veza uz nisku potrošnju resursa. Zbog toga je često izbor za dijeljeni hosting, VPS, cloud server i infrastrukturu visoko prometnih aplikacija. Za pravilno funkcioniranje hostinga više stranica, svaki detalj, od dozvola datoteka do DNS preusmjeravanja, od instalacije SSL-a do razdvajanja logova, mora biti pravilno planiran.

Kada koristiti Nginx Server Blockove?

Nginx server blockovi se posebno koriste kada trebate upravljati više web prisutnosti na jednom serveru. To može biti dva mala korporativna site-a ili deseci klijent projekata, poddomena ili mikroservisa. Ključna točka ovdje je da se svaki projekt logički odvoji jedan od drugog.

• Ako želite objaviti više domena na istom VPS-u.
• Ako želite preusmjeriti www i non-www domene na jednu kanoničku adresu.
• Ako želite povezati poddomene s različitim mapama ili aplikacijama.
• Ako želite definirati zasebne SSL certifikate i sigurnosne politike za svaku stranicu.
• Ako želite pratiti klijentske projekte s odvojenim log datotekama.
• Ako želite pokretati različite aplikacije poput Laravel-a, WordPress-a, statičnog HTML-a i Node.js na istom serveru.

Na primjer, tehnički je moguće da digitalna agencija objavi 8 nisko prometnih korporativnih stranica na jednom VPS-u s 4 GB RAM-a. Međutim, za svaku stranicu treba izračunati promet, korištenje diska, broj PHP procesa, opterećenje baze podataka i učestalost rezervi. Ako projekti primaju visok promet ili je izolacija resursa kritična, trebali bi se odabrati snažniji VPS, cloud server ili rješenja za upravljani hosting. U ovom kontekstu, opcije Web Hosting i Korporativni Hosting mogu se usporediti.

Zahtjevi prije početka

U ovom vodiču pretpostavit ćemo da koristite Linux server temeljen na Ubuntu ili Debian-u. Komande se mogu malo razlikovati ovisno o distribuciji; međutim, logika je ista. Prije nego što započnete s radom u produkcijskom okruženju, obavezno napravite rezervne kopije. Pogrešna Nginx konfiguracija može uzrokovati privremenu nedostupnost svih stranica.

Tehničke pripreme

• Linux korisnički račun s root ili sudo privilegijama.
• Instaliran i aktivan Nginx servis.
• Najmanje jedna domena usmjerena na IP adresu servera.
• Portovi 80 i 443 otvoreni u vatrozidu.
• Uređena struktura direktorija za datoteke stranica.
• Važeći certifikat za SSL ili korištenje besplatnog Let's Encrypt.
• Instalacija PHP-FPM za aplikacije temeljene na PHP-u.

Na DNS strani, A zapis usmjerava glavnu domenu na IPv4 adresu, dok AAAA zapis, ako postoji, usmjerava na IPv6 adresu. Za poddomene kao www može se koristiti CNAME ili A zapis. DNS propagacija obično se završava između nekoliko minuta i 24 sata. Kada postavljate novu instalaciju, brže je prvo pripremiti DNS zapise, a zatim preći na konfiguraciju Nginx server blockova.

Preporučena struktura direktorija

Jedna od najčešćih grešaka u hostingu više stranica je držanje svih datoteka u jednom miješanom direktoriju. Ovaj pristup može izgledati jednostavno na kratki rok, ali značajno usporava procese održavanja, rezervi i otklanjanja grešaka. Bolji način je korištenje odvojenih nadređenih direktorija za svaku domenu, unutar kojih se koriste poddirektoriji poput public, logs, backups.

Primjer strukture može izgledati ovako: /var/www/site1.com/public, /var/www/site1.com/logs, /var/www/site2.com/public i /var/www/site2.com/logs. Nginx root vrijednost trebala bi direktno ukazivati na public direktorij. Na taj način, datoteke aplikacije, osjetljive datoteke poput .env i rezervne kopije neće biti dostupne putem weba.

Za svaki web direktorij možete staviti jednostavnu index.html datoteku kao primjer statične test stranice. U njoj možete napisati ime stranice kako biste brzo potvrdili koji server block radi. U produkcijskim okruženjima, vlasništvo ovih direktorija obično se postavlja na www-data korisnika ili posebnog korisnika koji provodi implementaciju. U dozvolama datoteka, 755 za direktorije i 644 za datoteke obično je dovoljno u većini statičnih scenarija. U aplikacijama koje zahtijevaju pisanje, kao što je WordPress, područja poput uploads treba dodatno razmotriti.

Kreiranje Nginx Server Blocka Korak po Korak

Sljedeći koraci su objašnjeni na primjeru domene site1.com. Istu metodu možete ponoviti za drugu, treću ili više stranica. Ključna točka je koristiti jedinstvene server_name, root i log datoteke za svaku stranicu.

1. Kreirajte direktorij stranice

Prvi korak je kreirati direktorij u kojem će se nalaziti web datoteke. Primjer: sudo mkdir -p /var/www/site1.com/public. Zatim, za testiranje, možete stvoriti datoteku /var/www/site1.com/public/index.html i u nju napisati prepoznatljiv tekst poput "Ovo je testna stranica site1.com".

Za pravilno postavljanje vlasništva datoteke može se koristiti naredba sudo chown -R www-data:www-data /var/www/site1.com. Ako provodite implementaciju s drugim korisnikom, prilagodite dozvole grupe u skladu s tim. U produkcijskom okruženju izbjegavajte dozvole 777 gdje svi imaju pravo pisanja. Ove dozvole mogu omogućiti napadačima da zloupotrebljavaju direktorije za učitavanje.

2. Kreirajte datoteku server blocka

U Nginx-u je uobičajena praksa držati neaktivne konfiguracije pod /etc/nginx/sites-available i aktivirati ih povezivanjem s /etc/nginx/sites-enabled putem simboličke veze. Primjer datoteke: /etc/nginx/sites-available/site1.com.

Jednostavan HTTP server block može se napisati ovako: 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; } }

U ovoj konfiguraciji listen 80 sluša HTTP promet, server_name označava koje domene pripadaju ovom blocku, root pokazuje direktorij gdje se nalaze web datoteke, a index definira zadanu datoteku. try_files vraća 404 ako ne može pronaći traženu datoteku ili direktorij. Ova konfiguracija je obično dovoljna za statične stranice.

3. Aktivirajte stranicu

Da biste aktivirali konfiguraciju, treba stvoriti simboličku vezu: sudo ln -s /etc/nginx/sites-available/site1.com /etc/nginx/sites-enabled/site1.com. Ova metoda je zdravija od kopiranja datoteka jer radite unutar jedne glavne konfiguracijske datoteke. Kada napravite promjene, povezane datoteke ostaju ažurirane.

Ako ne želite da zadnja Nginx stranica preuzme vašu stranicu, možete onemogućiti zadnju konfiguraciju. To se može učiniti uklanjanjem veze /etc/nginx/sites-enabled/default. Međutim, prije nego to učinite, uvjerite se da vaš vlastiti server block ispravno radi.

4. Testirajte konfiguraciju i ponovno učitajte Nginx

Nakon svake promjene, treba izvršiti sintaktičko testiranje s naredbom sudo nginx -t. Ako je test uspješan, možete ponovo učitati servis bez prekida s naredbom sudo systemctl reload nginx. reload naredba je obično sigurnija od restart, jer bolje upravlja aktivnim vezama.

Ako test ne uspije, poruka o grešci obično pokazuje naziv datoteke i broj reda. Nedostajuća točka-zarez, pogrešno postavljene vitičaste zagrade, neispravna putanja direktorija ili sukobi s vrijednostima server_name su najčešći problemi. Nginx se ne smije ponovo učitavati dok se greška ne otkloni.

Dodavanje Druge i Treće Stranice

Ljepota hostinga više stranica je što se proces može ponavljati nakon prvotne ispravne instalacije. Kreirate direktorij /var/www/site2.com/public za site2.com, pišete datoteku /etc/nginx/sites-available/site2.com, mijenjate root i log vrijednosti na site2.com, stvarate simboličku vezu i pokrećete Nginx test.

Jednostavna struktura za drugu stranicu može se napisati ovako: 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; } }

Korištenje odvojenih logova za svaku stranicu vrlo je vrijedno u stvarnosti. Na primjer, dok se na jednoj stranici povećava broj 404 grešaka, druga može raditi bez problema. Zbog odvojene strukture logova, možete pronaći izvor greške u nekoliko sekundi. Na sličan način, analiza prometa, napadi botova, slomljene veze i problemi s performansama mogu se pratiti po stranicama.

SSL i HTTPS Konfiguracija

Prema SEO standardima iz 2026. godine, HTTPS više nije samo sigurnosna značajka, već i pokazatelj povjerenja korisnika i tehničke kvalitete. Preglednici označavaju HTTP stranice kao nesigurne; SSL je obavezan za projekte koji uključuju plaćanje, članstvo, forme ili upravljačke panele. Kada hostate više stranica, ispravan certifikat treba biti definiran za svaku domenu. Možete provjeriti stranicu SSL certifikati za vaše SSL potrebe putem Hostragonsa.

Ako koristite Let's Encrypt, možete dobiti certifikat za svaku domenu putem Certbota. U primjeru procesa, naredba certbot --nginx -d site1.com -d www.site1.com prepoznaje Nginx konfiguraciju i automatski može dodati HTTPS block. Međutim, nakon automatskog uređivanja, dobra je praksa provjeriti datoteku. Mogu se pojaviti problemi s pogrešnim preusmjeravanjem ili ponovljenim server blockovima.

U konfiguraciji HTTPS, promet na portu 80 obično se trajno preusmjerava na port 443. 301 preusmjeravanje daje trajni signal odabira za SEO. Odlučite hoćete li koristiti www ili ne i okupite sve varijacije na jednoj kanoničkoj adresi. Na primjer, ako želite koristiti https://site1.com umjesto https://www.site1.com, preusmjerite i HTTP i HTTPS www promet na adresu bez www. To smanjuje rizik od dupliciranog sadržaja.

Nginx Server Blockovi za PHP i WordPress Stranice

U statičnim HTML stranicama konfiguracija je jednostavna; međutim, kod WordPress-a, Laravel-a ili specijaliziranih PHP aplikacija potrebna je integracija s PHP-FPM. U tom slučaju definira se index.php datoteka, a PHP zahtjevi se usmjeravaju na odgovarajući socket. Na primjer, na Ubuntu-u, socket put do PHP 8.3 može biti /run/php/php8.3-fpm.sock. Verzija se razlikuje ovisno o serveru.

Primjer PHP logike: 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; } }

Za rad trajnih veza u WordPress-u, struktura try_files $uri $uri/ /index.php?$args je važna. Također se trebaju razmotriti sigurnosne mjere poput ograničavanja pristupa xmlrpc.php, rate limiting za wp-login.php i onemogućavanje PHP-a u uploads direktoriju. Ako hostate mnogo WordPress stranica na istom VPS-u, koristite zasebne baze podataka, zasebne korisnike i redovnu politiku ažuriranja. Za one koji traže alternativu za WordPress hosting, WordPress hosting može biti bolje upravljivo rješenje.

Usporedba Nginx Server Blockova i Apache VirtualHost-a

Nginx i Apache postižu isti cilj različitim arhitekturama. Oba mogu hostati više stranica na jednom serveru. Odabir ovisi o potrebama aplikacije, navikama upravljanja i očekivanjima u pogledu performansi.

Ako je vaša aplikacija jako povezana s pravilima .htaccess, Apache može izgledati lakše. Međutim, za visoki promet, obrnutu proxy, cache i moderne distribucijske tokove, Nginx je snažan izbor za većinu projekata. U nekim infrastrukturnim okruženjima, Nginx može biti korišten kao obrnut proxy, dok Apache djeluje kao backend aplikacijski server.

Najbolje Prakse za Sigurnost

Hosting više stranica na istom serveru donosi prednosti s aspekta troškova; ali povećava sigurnosnu odgovornost. Da bi se osiguralo da ranjivost na jednoj stranici ne utječe na druge, treba primijeniti izolaciju i princip minimalnih privilegija.

• Kreirajte zasebne baze podataka i korisnike za svaku stranicu.
• Ograničite web root direktorij samo na public mapu.
• Držite backup, .env, .git, config i SQL datoteke izvan web pristupa.
• Redovito obnavljajte SSL certifikate i obavezno primijenite HTTPS preusmjeravanje.
• Koristite UFW ili sličan vatrozid na serveru; otvorite samo potrebne portove.
• Redovito primjenjujte ažuriranja za Nginx i operativni sustav.
• Držite odvojene access_log i error_log za svaku stranicu.
• Dodajte IP ograničenja ili dodatnu autentifikaciju za upravljačke panele.
• Izbjegavajte široke dozvole poput 777.

Također je korisno dodati osnovne sigurnosne zaglavlja. Zaglavlja kao što su X-Frame-Options, X-Content-Type-Options, Referrer-Policy i Content-Security-Policy mogu se koristiti u odgovarajućim projektima. Međutim, posebno Content-Security-Policy može spriječiti učitavanje skripti i stilskih datoteka ako nije ispravno primijenjena; stoga bi se trebala prvo testirati u testnom okruženju. Za više sadržaja o sigurnosti, mogu se navesti linkovi na Sigurnost web stranice.

Obratite Pozornost na Performanse i SEO

Nginx server blockovi ne utječu samo na objavljivanje, već i na performansu i SEO kvalitetu. Pogrešne preusmjeravajuće lance, neispravni kanonički izbori, nedostaci gzip ili brotli kompresije, veliki logovi i nedovoljna postavka cache-a mogu usporiti stranicu. Googleovi signali o iskustvu stranice usmjereni su na korisnike; brzi, sigurni i stabilni webovi imaju tendenciju da se bolje performiraju.

Prvo, odredite jedinstvenu kanoničku verziju za svaku domenu. Preusmjerite s HTTP na HTTPS, s www na non-www ili obrnuto u jednom koraku. Lanac ne bi trebao izgledati ovako: http://site.com prvo na http://www.site.com, zatim na https://www.site.com, zatim na https://site.com. Umjesto toga, bolje je doći do cilja s jednim 301.

Za statične datoteke mogu se koristiti cache-control zaglavlja. Slike, CSS i JS datoteke mogu se čuvati u pregledniku određeno vrijeme. Međutim, za često mijenjane datoteke treba koristiti verzioniranje naziva datoteka ili strategiju query string. Gzip kompresija smanjuje propusnost za tekstualne datoteke poput HTML-a, CSS-a, JS-a i JSON-a. Za web stranice s visokim prometom može se razmotriti korištenje Nginx microcache, FastCGI cache ili CDN. Za potrebe CDN-a i globalnog pristupa, možete se povezati s sadržajem kao što je Što je CDN.

Upravljanje Logovima i Praćenje

U hostingu više stranica, upravljanje logovima je ključ za rješavanje problema. Odvojene log datoteke jasno pokazuju na kojoj se stranici dogodila koja greška. access_log bilježi zahtjeve posjetitelja, dok error_log bilježi greške u konfiguraciji, dozvolama, nedostupnim datotekama i upstream greškama. 502 Bad Gateway greška obično se odnosi na PHP-FPM ili vezu s back-end uslugom. 403 Forbidden može biti problem s dozvolama ili index datotekom. 404 Not Found može ukazivati na problem s putanjom datoteke, prepisivanjem ili pogrešnim root-om nakon DNS-a.

Kako bi se spriječilo neograničeno širenje log datoteka, treba provjeriti konfiguraciju logrotate. Za manje projekte, dnevna ili tjedna rotacija može biti dovoljna. Na web stranicama s visokim prometom treba koristiti centralizirano prikupljanje logova, praćenje metrika i sustave upozorenja. Prekomjerno korištenje diska može spriječiti Nginx da piše logove, uzrokovati pad baze podataka i nedostupnost stranica. Stoga je praktično postaviti pragove za korištenje diska.

Česte Greške i Brza Rješenja

Dok radite s Nginx server blockovima, mogu se pojaviti neke greške u gotovo svakom projektu. Poznavanje tih grešaka može značajno skratiti vrijeme instalacije.

• Domena otvara pogrešnu stranicu: provjerite sukobe server_name i default server block.
• 403 Forbidden greška: provjerite root direktorij, dozvole datoteka i postojanje index datoteke.
• 404 Not Found greška: provjerite root putanju i try_files pravilo.
• 502 Bad Gateway greška: provjerite radi li PHP-FPM servis i je li socket put ispravan.
• SSL certifikat izgleda kao da pripada pogrešnoj stranici: provjerite server_name i certifikat datoteke na portu 443.
• Izgleda da se pojavljuje petlja preusmjeravanja: pojednostavite HTTP-HTTPS i www preusmjeravajuća pravila.
• Nginx se ne ponovo učitava: ispravite grešku sintakse prema broju reda u sudo nginx -t izlazu.

Iskusni administratori koriste jednostavnu kontrolnu listu: Je li DNS ispravan, je li Nginx konfiguracija aktivna, postoji li root direktorij, jesu li dozvole ispravne, je li servis prošao test, što logovi govore? Kretanje kroz ovaj redoslijed omogućuje brzo rješavanje problema bez panike.

Praktična Kontrolna Lista za Produkcijsko Okruženje

Prije nego što stavite u rad, provjerite svaku stranicu s ovom kontrolnom listom. Ovaj popis, posebno u klijent projektima, može stvoriti profesionalni standard rada dokumentiranjem ovih stavki prije isporuke.

• A ili AAAA zapis domene usmjeren je na ispravnu IP adresu.
• Jedna od verzija s www ili bez www odabrana je kao kanonička.
• HTTP promet se preusmjerava na HTTPS 301.
• SSL certifikat je važeći i automatsko obnavljanje je aktivno.
• Za svaku stranicu definirani su odvojeni root i log datoteke.
• Nginx konfiguracija je potvrđena s sudo nginx -t.
• Plan rezervi je definiran, a test vraćanja je proveden.
• Dozvole datoteka su u skladu s principom minimalnih privilegija.
• U vatrozidu su otvoreni samo potrebni portovi.
• Error logovi su praćeni najmanje 15 minuta nakon puštanja u rad.

Ova lista može izgledati mala, ali u stvarnim projektima značajno smanjuje rizik od prekida. Posebno su koraci za obnavljanje SSL-a, provjeru DNS-a i praćenje logova ključni za rano otkrivanje većine nevidljivih grešaka.

Zaključak

Nginx server blockovi su jedan od osnovnih načina za uredno, sigurno i performantno hostanje više stranica na jednom serveru. Pravilna struktura direktorija, odvojene konfiguracijske datoteke, jasna pravila preusmjeravanja, korištenje HTTPS-a, razdvajanje logova i redoviti testni proces čine upravljanje višestranim stranicama vrlo učinkovitim. Iste se principe mogu primijeniti od malog portfelja do višestrukih klijent projekata.

Ako planirate objaviti novi projekt, prvo razjasnite svoje potrebe za domenom, izvorom servera i SSL-om; zatim korak po korak postavite svoju Nginx konfiguraciju prema gornjoj kontrolnoj listi. Ako tražite održiviju infrastrukturu, možete istražiti Hosting paketi, VPS server i SSL certifikati rješenja od Hostragonsa kako biste odabrali odgovarajuću polaznu točku za vaš projekt.

Često Postavljana Pitanja

Koliko stranica se može hostati s Nginx server blockovima?

Tehnički, možete hostati veliki broj stranica na istom serveru s Nginx-om; granica obično ovisi o CPU-u, RAM-u, disku, prometu, opterećenju baze podataka i PHP-FPM kapacitetu. Na nisko prometnim statičnim stranicama može biti moguće hostati desetke stranica, dok je za intenzivne WordPress ili e-trgovinske projekte bolje hostati manji broj stranica.

Da li je potrebno imati zaseban SSL certifikat za svaku stranicu?

Da, svaki naziv domene ili poddomene koja će se objaviti putem HTTPS-a mora biti uključena u certifikat. Mogu se koristiti pojedinačni certifikati, kao i SAN ili wildcard certifikati. Važno je da se ispravni certifikat poveže s odgovarajućom domenom u Nginx 443 server blocku.

Može li se poddomena objaviti s Nginx server blockom?

Da. Možete definirati zaseban server_name za poddomene poput blog.site.com ili panel.site.com i usmjeriti ih na različite root direktorije ili različite back-end aplikacije. Na DNS strani trebate stvoriti A ili CNAME zapis za odgovarajuću poddomenu.

Koja je razlika između sites-available i sites-enabled?

sites-available je mjesto gdje se nalaze dostupne konfiguracijske datoteke; sites-enabled sadrži aktivne konfiguracije. Obično se unutar sites-enabled stvara simbolička veza na datoteku iz sites-available. Ova metoda omogućava urednije aktiviranje i deaktiviranje stranica.

Ako se otvara pogrešna stranica, odakle dolazi problem?

Najčešći uzroci su pogrešno usmjeren DNS na pogrešnu IP adresu, netočna vrijednost server_name, hvatanje zahtjeva od strane default Nginx blocka ili pogrešna SSL konfiguracija na portu 443. Prvo provjerite DNS zapise, zatim nginx -t izlaz, aktivne veze unutar sites-enabled i odgovarajuće access_log datoteke.