Nginx strežniški bloki (virtualni gostitelji) za gostovanje več spletnih strani

Nginx strežniški bloki predstavljajo koncept virtualnih gostiteljev, ki omogoča objavo več domen ali spletnih strani z ločenimi konfiguracijami v eni sami namestitvi Nginxa. Na primer, lahko definirate različne korenske mape, dnevniške datoteke, SSL certifikate in PHP nastavitve za example.com, blog.example.com in druga-stran.com, vse na istem VPS-ju. Na kratko, rešitev vključuje: ustvarjanje ločenih map za vsak spletni naslov, usmerjanje DNS zapisov domene na IP naslov strežnika, pisanje ločenega strežniškega bloka pod /etc/nginx/sites-available, povezovanje tega bloka v mapo sites-enabled, testiranje konfiguracije in ponovno nalaganje storitve Nginx.

V tem priročniku bomo obravnavali postopek gostovanja več spletnih strani z Nginx strežniškimi bloki na način, primeren za proizvodno okolje. Cilj ni le vzpostavitev delujoče strukture, temveč tudi ustvarjanje upravljive, varne, hitre, varnostno kopirane in skalabilne postavitve. Delili bomo praktične korake, še posebej za agencije, razvijalce, lastnike e-trgovin, podjetja, ki upravljajo več blagovnih znamk, in sistemske skrbnike, ki izvajajo več projektov na enem strežniku. Če še nimate strežnika, si lahko ogledate strani za VPS strežnik in Registracija domene za izbiro virov.

Kaj so Nginx strežniški bloki?

Nginx strežniški bloki so konfiguracijski elementi, opredeljeni znotraj Nginx konfiguracije kot strežniški blok, ki določajo, na katero spletno stran naj se preusmeri prihajajoča HTTP ali HTTPS zahteva. So podobni konceptu VirtualHost na Apache strani. Ko obiskovalec v brskalnik vnese domeno, DNS to domeno razreši na IP naslov strežnika. Nato Nginx pregleda Host glavo v zahtevi in zažene tisti strežniški blok, katerega vrednost server_name se ujema.

S tem je mogoče na istem IP naslovu in istem fizičnem ali virtualnem strežniku objaviti desettisoče različnih spletnih strani. Za vsako stran je mogoče določiti ločeno korensko mapo, dnevnik dostopov, dnevnik napak, pravila preusmerjanja, SSL certifikat, politiko predpomnjenja in varnostna pravila. Na primer, lahko svojo poslovno stran hranite v /var/www/poslovna/public, svoj blog v /var/www/blog/public, svoj testni okolje pa v /var/www/staging/public.

Nginx je v tej strukturi zelo učinkovit, saj lahko zaradi svoje arhitekture, osredotočene na dogodke, upravlja z visokim številom sočasnih povezav z nizko porabo virov. Zaradi tega se pogosto uporablja v skupnih gostiteljskih, VPS, oblačnih strežnikih in infrastrukturi visokotrafičnih aplikacij. Za zdravo delovanje več spletnih strani je treba pravilno načrtovati vsak detajl, od dovoljenj datotek do preusmeritev DNS, od namestitve SSL do ločevanja dnevnikov.

Kdaj uporabiti Nginx strežniške bloke?

Nginx strežniški bloki se uporabljajo, ko morate upravljati več spletnih prisotnosti na enem strežniku. To so lahko dva majhna poslovna spletna mesta ali pa desettisoče projektov strank, poddomen ali mikro storitev. Ključna točka tukaj je logična ločitev vsakega projekta drug od drugega.

• Če želite objaviti več domen na istem VPS-ju.
• Če želite preusmeriti www in ne-www različice domen na eno samo kanonično naslov.
• Če želite povezati poddomene z različnimi mapami ali aplikacijami.
• Če želite za vsako stran določiti ločen SSL certifikat in varnostno politiko.
• Če želite spremljati projekte strank z ločenimi dnevniškimi datotekami.
• Če želite na istem strežniku izvajati različne aplikacije, kot so Laravel, WordPress, statični HTML in Node.js.

Na primer, tehnično je mogoče, da digitalna agencija objavi 8 nizkotrafičnih poslovnih spletnih mest na enem samem 4 GB RAM VPS-ju. Vendar je treba za vsako stran izračunati promet, porabo diska, število PHP procesov, obremenitev baze podatkov in pogostost varnostnih kopij. Če projekti dobijo intenziven promet ali je izolacija virov kritična, je priporočljivo izbrati močnejši VPS, oblačni strežnik ali upravljane rešitve gostovanja. Na tej točki je možno primerjati Spletno gostovanje in Korporativno gostovanje možnosti.

Predpogoji pred začetkom

V tem priročniku bomo predpostavili, da imamo Linux strežnik, ki temelji na Ubuntu ali Debianu. Ukazi se lahko nekoliko razlikujejo glede na distribucijo; vendar je logika enaka. Pred izvajanjem operacij v proizvodnem okolju je nujno narediti varnostno kopijo. Napačna konfiguracija Nginx lahko povzroči, da so vse strani začasno nedostopne.

Potrebne tehnične priprave

• Linux uporabniški račun z root ali sudo pravicami.
• Namestitev in delujoča storitev Nginx.
• Vsaj ena domena, usmerjena na IP naslov strežnika.
• Odprti 80 in 443 porti v požarnem zidu.
• Redna struktura map za datoteke strani.
• Veljaven certifikat za SSL ali uporaba brezplačnega Let’s Encrypt.
• Namestitev PHP-FPM za PHP aplikacije.

Na strani DNS A zapis usmerja glavno domeno na IPv4 naslov, medtem ko AAAA zapis, če obstaja, usmerja na IPv6 naslov. Za poddomene, kot je www, se lahko uporablja CNAME ali A zapis. Razširitev DNS običajno traja od nekaj minut do 24 ur. Ko postavljate novo namestitev, je priporočljivo najprej pripraviti DNS zapise, nato pa preiti na konfiguracijo Nginx strežniških blokov, kar pospeši postopek.

Priporočena struktura map

Ena najpogostejših napak pri gostovanju več spletnih strani je, da vse datoteke hranijo zmedeno v eni sami mapi. Ta pristop se morda zdi enostaven na kratki rok, a v procesih vzdrževanja, varnostnega kopiranja in odpravljanja napak povzroča resne izgube časa. Boljša metoda je, da za vsako domeno ustvarite ločeno nadmapo in v njej uporabite podmape, kot so public, logs, backups.

Primerna struktura bi lahko bila: /var/www/site1.com/public, /var/www/site1.com/logs, /var/www/site2.com/public in /var/www/site2.com/logs. Nginx mora vrednost root neposredno usmerjati v mapo public. Tako datoteke aplikacije, občutljive datoteke, kot je .env, in varnostne kopije ne bodo dostopne neposredno prek spleta.

Za vsako mapo strani lahko postavite preprosto datoteko index.html za testiranje statične testne strani. Vsebina lahko vsebuje ime strani, kar hitro potrdi, kateri strežniški blok deluje. V proizvodnih okoljih se lastništvo teh map običajno upravlja z uporabo uporabnika www-data ali posebnega uporabnika za namestitev. Pri dovoljenjih datotek je 755 dovolj za mape in 644 za datoteke v večini statičnih scenarijev. V aplikacijah, kot je WordPress, ki zahtevajo pisanje, pa je treba posebej obravnavati področja, kot je mapa uploads.

Korak za korakom: Ustvarjanje Nginx strežniškega bloka

Naslednji koraki so opisani na primeru domene site1.com. Enako metodo lahko ponovite za drugo, tretjo ali več spletnih strani. Ključna točka je uporaba edinstvenih vrednosti server_name, root in dnevniške datoteke za vsako stran.

1. Ustvarite mapo za stran

Prvi korak je ustvariti mapo, kjer bodo shranjene spletne datoteke. Na primer: sudo mkdir -p /var/www/site1.com/public. Nato za testiranje ustvarite datoteko /var/www/site1.com/public/index.html in vanjo vpišite besedilo, ki ga lahko prepoznate, na primer: To je testna stran site1.com.

Za pravilno nastavitev lastništva datoteke lahko uporabite ukaz: sudo chown -R www-data:www-data /var/www/site1.com. Če postopke namestitve izvajate z drugim uporabnikom, ustrezno prilagodite dovoljenja skupini. V proizvodnih okoljih se izogibajte dovoljenjem 777, kjer imajo vsi uporabniki pravico pisati. Ta dovoljenja lahko omogočijo napadalcem zlorabo map za nalaganje.

2. Ustvarite datoteko strežniškega bloka

Običajna praksa v Nginxu je, da neaktivne konfiguracije hranite pod /etc/nginx/sites-available in jih aktivirate s simbolično povezavo v mapo /etc/nginx/sites-enabled. Na primer: /etc/nginx/sites-available/site1.com.

Preprost HTTP strežniški blok se zapiše na naslednji način: 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; } }

Ta konfiguracija omogoča poslušanje HTTP prometa na portu 80, server_name pa določa, kateri domene pripadajo temu bloku, root pa označuje mapo, kjer so shranjene spletne datoteke, index pa definira privzeto datoteko. try_files vrne 404, če ne more najti želene datoteke ali mape. Ta struktura je dovolj za statične strani.

3. Aktivirajte stran

Za aktivacijo konfiguracije ustvarite simbolično povezavo: sudo ln -s /etc/nginx/sites-available/site1.com /etc/nginx/sites-enabled/site1.com. Ta metoda je bolj zdrava od kopiranja datotek, saj delate na eni sami glavni konfiguracijski datoteki. Ko naredite spremembe, ostane povezana datoteka posodobljena.

Če želite preprečiti, da bi privzeta Nginx stran preglasila vašo spletno stran, lahko onemogočite privzeto konfiguracijo. To storite tako, da odstranite povezavo /etc/nginx/sites-enabled/default. Vendar se prepričajte, da pravilno deluje vaš strežniški blok, preden to storite.

4. Testirajte konfiguracijo in znova naložite Nginx

Po vsaki spremembi je treba izvesti sintaktični test z ukazom: sudo nginx -t. Če je test uspešen, lahko storitev ponovno naložite brez prekinitev s: sudo systemctl reload nginx. Ukaz reload je običajno bolj varen od restart, ker bolje upravlja z aktivnimi povezavami.

Če test ne uspe, bo sporočilo o napaki večinoma prikazovalo ime datoteke in številko vrstice. Najpogostejše težave so manjkajoči podpičja, napačne zavite oklepaje, napačne poti do map ali podvajanje vrednosti server_name. Nginx ne sme biti ponovno naložen, dokler težave niso odpravljene.

Dodajanje druge in tretje spletne strani

Čar pri gostovanju več spletnih strani je, da se postopek po prvi pravilni namestitvi lahko ponovi. Ustvarite mapo /var/www/site2.com/public za site2.com, napišite datoteko /etc/nginx/sites-available/site2.com, spremenite vrednosti root in log v site2.com, ustvarite simbolično povezavo in izvedite test Nginx.

Preprosta struktura za drugo spletno stran se loči na naslednji način: 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; } }

Uporaba ločenih dnevnikov za vsako spletno stran je v resničnem svetu zelo dragocena. Na primer, medtem ko se na eni strani povečujejo napake 404, na drugi strani morda ne bo težav. Z ločeno strukturo dnevnikov lahko vir napake najdete v nekaj sekundah. Na enak način je mogoče spremljati analizo prometa, napade botov, pokvarjene povezave in težave s delovanjem na podlagi spletne strani.

Konfiguracija SSL in HTTPS

V skladu z SEO standardi leta 2026 HTTPS ni več le varnostna funkcija, temveč tudi znak zaupanja uporabnikov in tehnične kakovosti. Brskalniki označujejo HTTP strani kot nezanesljive; SSL je obvezen pri projektih, ki vključujejo plačila, članstva, obrazce ali nadzorne plošče. Pri gostovanju več spletnih strani je treba za vsako domeno pravilno določiti certifikat. Za SSL potrebe si lahko ogledate stran SSL certifikati na Hostragons.

Če uporabljate Let’s Encrypt, lahko z Certbotom pridobite certifikat za vsako domeno. V primeru, da certbot --nginx -d site1.com -d www.site1.com zazna konfiguracijo Nginx, lahko samodejno doda blok za HTTPS. Vendar je dobra navada, da po samodejni obdelavi preverite datoteko. Lahko se pojavijo težave z napačnimi preusmeritvami ali podvojenimi strežniškimi bloki.

V konfiguraciji HTTPS se običajno promet na portu 80 trajno preusmeri na port 443. 301 preusmeritev daje signal trajne izbire z vidika SEO. Odločite se, ali boste uporabljali www, in združite vse različice na en kanoničen naslov. Na primer, če boste uporabili https://site1.com namesto https://www.site1.com, preusmerite tako HTTP kot HTTPS www promet na naslov brez www. To zmanjša tveganje za podvojeno vsebino.

Nginx strežniški bloki za PHP in WordPress strani

Konfiguracija je preprosta za statične HTML strani; vendar pa WordPress, Laravel ali posebne PHP aplikacije zahtevajo integracijo s PHP-FPM. V tem primeru se določi datoteka index.php in PHP zahteve se preusmerijo na ustrezen vtičnik. Na primer, v Ubuntu bi lahko bila pot do vtičnika PHP 8.3 /run/php/php8.3-fpm.sock. Različica se lahko razlikuje glede na strežnik.

Primer strukture za 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; } }

Za delovanje trajnih povezav v WordPressu je pomembna struktura try_files $uri $uri/ /index.php?$args. Poleg tega je treba razmisliti o varnostnih ukrepih, kot so omejevanje dostopa do xmlrpc.php, omejevanje količin dostopa do wp-login.php ter preprečevanje izvajanja PHP v mapi uploads. Če gostite več WordPress strani na istem VPS-ju, uporabite ločeno bazo podatkov, ločenega uporabnika in redno politiko posodobitev za vsako stran. Tisti, ki iščejo alternativno gostovanje za WordPress, lahko razmislijo o WordPress gostovanje, kar je lahko bolj upravljiva možnost.

Primerjava Nginx strežniških blokov z Apache VirtualHost

Nginx in Apache dosegata isti cilj na različne načine. Obe omogočata gostovanje več spletnih strani na enem strežniku. Izbira je odvisna od potreb aplikacije, navad upravljanja in pričakovanj glede delovanja.

Če je vaša aplikacija močno odvisna od pravil .htaccess, se lahko Apache zdi lažji. Vendar je Nginx močna izbira za visok promet, obratni proxy, predpomnjenje in moderne distribucijske tokove v večini projektov. V nekaterih infrastruktura se lahko Nginx uporablja kot obratni proxy, Apache pa kot strežnik aplikacij v ozadju.

Najboljše prakse za varnost

Gostovanje več spletnih strani na istem strežniku prinaša stroškovne prednosti, vendar povečuje tudi odgovornost za varnost. Da se ranljivosti na eni spletni strani ne bi prenesle na druge, je treba upoštevati načelo izolacije in minimalnih pravic.

• Ustvarite ločeno bazo podatkov in ločenega uporabnika baze podatkov za vsako spletno stran.
• Omejite dostop do spletne korenske mape samo na mapo public.
• Ohranite varnostne kopije, .env, .git, konfiguracijske in SQL datoteke zunaj dostopa do spleta.
• Redno obnavljajte SSL certifikate in obvezno uvedite preusmeritev na HTTPS.
• Na strežniku uporabite UFW ali podoben požarni zid; odprite samo potrebne porte.
• Redno izvajajte posodobitve za Nginx in operacijski sistem.
• Vsako spletno stran spremljajte z ločenimi access_log in error_log.
• Na upravljalne plošče dodajte omejitev IP ali dodatno preverjanje pristnosti.
• Izogibajte se širokim dovoljenjem, kot je 777, pri dovoljenjih datotek.

Poleg tega je koristno dodati osnovne varnostne glave. Glave, kot so X-Frame-Options, X-Content-Type-Options, Referrer-Policy in Content-Security-Policy, se lahko uporabijo v ustreznih projektih. Vendar pa lahko zlasti Content-Security-Policy, če je nepravilno uporabljena, blokira datoteke skript in sloga; zato je priporočljivo, da se najprej preizkusi v testnem okolju. Za več informacij o varnosti lahko povezave do člankov varnost spletne strani.

Učinkovitost in SEO: Kaj je treba upoštevati

Nginx strežniški bloki vplivajo ne le na objavo, temveč tudi na kakovost delovanja in SEO. Napačni verižni preusmeritveni tokovi, napačne kanonične izbire, manjkajoče gzip ali brotli stiskanje, velike dnevniške datoteke in pomanjkljive nastavitve predpomnjenja lahko znižajo hitrost strani. Googleovi signali o izkušnjah s stranmi so usmerjeni k uporabnikom; hitre, varne in stabilne strani običajno zagotavljajo boljše delovanje.

Najprej določite en sam kanoničen naslov za vsako domeno. Preusmerite promet iz HTTP na HTTPS, iz www na ne-www ali obratno v enem koraku. Veriga ne bi smela izgledati takole: http://site.com najprej http://www.site.com, nato https://www.site.com, nato https://site.com. Namesto tega je pravilneje priti do cilja z enim samim 301 preusmeritvijo.

Za statične datoteke se lahko uporabljajo naslovi cache-control. Slike, CSS in JS datoteke lahko ostanejo shranjene v brskalniku določen čas. Vendar pa je pri pogosto spremenljivih datotek priporočljivo uporabiti različice v imenih datotek ali strategije query string. gzip stiskanje zmanjša pasovno širino za besedilne datoteke, kot so HTML, CSS, JS in JSON. Na spletnih straneh z velikim prometom je vredno razmisliti o uporabi Nginx microcache, FastCGI predpomnilnika ali CDN. Za potrebe CDN in globalnega dostopa lahko vključite povezavo do vsebine Kaj je CDN.

Upravljanje dnevnikov in spremljanje

Pri gostovanju več spletnih strani je upravljanje dnevnikov ključnega pomena za reševanje težav. Ločene dnevniške datoteke jasno pokažejo, na kateri strani je prišlo do napake. access_log beleži zahteve obiskovalcev, error_log pa beleži napake pri konfiguraciji, dovoljenju, iskanju datotek in napakah v upstream. Napaka 502 Bad Gateway se običajno nanaša na povezavo s PHP-FPM ali storitvijo v ozadju. Napaka 403 Forbidden je lahko posledica težave z dovoljenjem ali datoteko index. Napaka 404 Not Found lahko kaže na napačno pot do datoteke, napako pri prepisovanju ali napačen problem z root po preusmeritvi DNS.

Za preprečitev neskončnega rasti dnevniških datotek je treba preveriti konfiguracijo logrotate. Pri manjših projektih je lahko dnevna ali tedenska rotacija dovolj. Na spletnih straneh z visokim prometom je treba uporabiti centralizirano zbiranje dnevnikov, spremljanje metrik in opozorilne sisteme. Polnjenje diska lahko povzroči, da Nginx ne more zapisovati dnevnikov, baza podatkov se ustavi in spletne strani postanejo nedostopne. Zato je koristno določiti pragovne vrednosti za uporabo diska.

Pogoste napake in hitre rešitve

Med delom z Nginx strežniškimi bloki se lahko srečate z nekaterimi napakami, ki se pojavijo skoraj v vsakem projektu. Poznavanje teh napak lahko znatno skrajša čas namestitve.

• Domena odpira napačno spletno stran: preverite konflikte server_name in privzeti strežniški blok.
• Napaka 403 Forbidden: preverite korensko mapo, dovoljenja datotek in obstoj datoteke index.
• Napaka 404 Not Found: preglejte pot do root in pravilo try_files.
• Napaka 502 Bad Gateway: preverite, ali storitev PHP-FPM deluje in ali je pot do vtičnika pravilna.
• SSL certifikat se zdi, da pripada napačni strani: preverite server_name na 443 portu in datoteke certifikatov.
• Pojavlja se zanko preusmeritev: poenostavite pravila preusmerjanja za HTTP-HTTPS in www.
• Nginx ne more biti ponovno naložen: popravite napako v sintaksi glede na številko vrstice v izhodu sudo nginx -t.

Izkušeni skrbniki uporabljajo preprost seznam kontrolnih točk: Je DNS pravilen? Je konfiguracija Nginx aktivna? Ali obstaja korenska mapa? Ali so dovoljenja pravilna? Je storitev prestala test? Kaj pravijo dnevniki? S tem zaporedjem se lahko hitro rešite težav, ne da bi se vznemirjali.

Praktični kontrolni seznam za proizvodno okolje

Preden greste v živo, preverite vsako spletno stran s spodnjim kontrolnim seznamom. Še posebej pri projektih strank je dokumentiranje teh točk pred predajo profesionalni standard dela.

• A ali AAAA zapis domene se usmerja na pravilen IP naslov.
• Izbrana je ena od različic www in ne-www kot kanonična.
• HTTP promet se preusmeri na HTTPS z 301.
• SSL certifikat je veljaven in samodejno obnavljanje je aktivno.
• Za vsako stran so določene ločene korenske in dnevniške datoteke.
• Konfiguracija Nginx je potrjena s sudo nginx -t.
• Načrt varnostnega kopiranja je določen in testiranje obnovitve je bilo opravljeno.
• Dovoljenja datotek so v skladu z načelom minimalnih pravic.
• V požarnem zidu so odprti samo potrebni porti.
• Napake so bile spremljane najmanj 15 minut po zagonu.

Ta seznam se morda zdi kratek, vendar znatno zmanjšuje tveganje za prekinitve v resničnih projektih. Še posebej koraki za obnavljanje SSL, preverjanje DNS in spremljanje dnevnikov zgodaj ujamejo večino nevidnih napak.

Zaključek

Nginx strežniški bloki so ena od osnovnih metod za redno, varno in učinkovito gostovanje več spletnih strani na enem strežniku. Pravilna struktura map, ločene konfiguracijske datoteke, jasna pravila preusmerjanja, uporaba HTTPS, ločevanje dnevnikov in reden proces testiranja lahko znatno izboljšajo upravljanje več spletnih strani. Enaki principi se lahko uporabljajo od majhnih portfeljskih spletnih mest do številnih projektov strank.

Če nameravate objaviti nov projekt, najprej razjasnite svoje potrebe po domenah, strežniških virih in SSL; nato pa konfiguracijo Nginx korak za korakom postavite s pomočjo zgornjega kontrolnega seznama. Če iščete bolj upravljivo infrastrukturo, si lahko ogledate Pakcije gostovanja, VPS strežnik in SSL certifikati rešitve Hostragons, da izberete ustrezno izhodišče za vaš projekt.

Pogosta vprašanja

Koliko spletnih strani lahko gostujem z Nginx strežniškimi bloki?

Tehnično lahko z Nginxom gostite številne spletne strani na istem strežniku; omejitev je običajno odvisna od CPU, RAM, diska, prometa, obremenitve baze podatkov in kapacitete PHP-FPM. Pri nizkotrafičnih statičnih spletnih straneh je mogoče gostiti desettisoče spletnih mest, medtem ko je pri intenzivnih WordPress ali e-trgovinskih projektih bolje gostiti manj strani.

Ali potrebujem ločen SSL certifikat za vsako spletno stran?

Da, vsaka domena ali poddomena, ki bo objavljena prek HTTPS, mora biti vključena v obseg certifikata. Uporabljati je mogoče posamezne certifikate ali SAN ali wildcard certifikate. Pomembno je, da se v Nginx strežniškem bloku na 443 pravilno povežejo ustrezne datoteke certifikatov z ustrezno domeno.

Ali je mogoče objaviti poddomeno z Nginx strežniškim blokom?

Da. Za poddomeno, kot je blog.site.com ali panel.site.com, lahko določite ločen server_name in usmerite na različne korenske mape ali različne aplikacije v ozadju. Na strani DNS je treba ustvariti ustrezen A ali CNAME zapis za poddomeno.

Kakšna je razlika med sites-available in sites-enabled?

sites-available je mesto, kjer se hranijo razpoložljive konfiguracijske datoteke; sites-enabled pa vsebuje aktivne konfiguracije. Običajno se v mapi sites-enabled ustvari simbolična povezava do datoteke v sites-available. Ta metoda omogoča bolj organizirano aktivacijo in deaktivacijo spletnih strani.

Od kod prihaja težava, če se odpre napačna spletna stran?

Najpogostejši vzroki so napačna usmeritev DNS na napačen IP, napačna vrednost server_name, zajem privzete Nginx konfiguracije ali delovanje napačnega SSL bloka na 443. Najprej preverite DNS zapise, nato izhod nginx -t, aktivne povezave sites-enabled in ustrezne access_log datoteke.