Usean sivuston hallinta Nginx-palvelinlohkoilla

Q: Mikä ero on sites-available ja sites-enabled kansioilla?

sites-available sisältää kaikki mahdolliset konfiguraatiot; sites-enabled vain aktiiviset. Yleensä sites-enabled kansiossa on symbolinen linkki sites-available tiedostoon – näin aktivointi ja deaktivointi on hallittua.

Nginx serverilohkot (eli virtuaaliset hostit) mahdollistavat usean domainin tai verkkosivun julkaisun yhdellä Nginx-palvelimella – jokainen omilla asetuksillaan. Voit esimerkiksi määritellä example.com, blog.example.com ja toinen-sivusto.fi jokaiselle oman juurikansion, lokitiedostot, SSL-sertifikaatit ja PHP-asetukset samalla VPS:llä. Ratkaisu on yksinkertainen: luo jokaiselle sivustolle oma kansio, ohjaa domainin DNS-tietueet palvelimen IP-osoitteeseen, kirjoita erillinen serverilohko tiedosto /etc/nginx/sites-available kansioon, tee siitä symbolinen linkki sites-enabled kansioon, testaa asetukset ja lataa Nginx uudelleen.

Tässä oppaassa käymme läpi usean sivuston ylläpitämisen Nginx-serverilohkoilla tuotantoympäristöön sopivalla tavalla. Tarkoituksena ei ole vain saada toimiva setup, vaan rakentaa hallittava, turvallinen, nopea, varmistettava ja skaalautuva kokonaisuus. Jaamme käytännön ohjeita erityisesti IT-toimistoille, kehittäjille, verkkokauppiaille, monibrändiyrityksille ja järjestelmänvalvojille, jotka pyörittävät useita projekteja yhdellä palvelimella. Jos sinulla ei ole vielä palvelinta, tutustu VPS palvelin ja domainin hallintaan Domainrekisteröinti -sivuilla.

Mitä ovat Nginx serverilohkot?

Nginx serverilohkot ovat Nginx-konfiguraatiossa määriteltäviä server-lohkoja, jotka ohjaavat HTTP/HTTPS-pyynnön oikealle sivustolle. Apache-maailmassa tätä kutsutaan VirtualHostiksi. Kun käyttäjä kirjoittaa selaimeen domainin, DNS muuntaa osoitteen palvelimen IP:ksi. Tämän jälkeen Nginx tarkistaa pyynnön Host-headerin ja aktivoi serverilohkon, jonka server_name vastaa domainia.

Näin samalla IP-osoitteella ja yhdellä serverillä voi julkaista kymmeniä eri verkkosivustoja. Jokaiselle sivulle voi määrittää oman juurikansion, lokit, ohjaussäännöt, SSL-sertifikaatin, välimuistipolitiikan ja turvallisuusasetukset. Esimerkiksi yrityssivusto voi sijaita /var/www/yritys/public kansiossa, blogi /var/www/blogi/public ja testausympäristö /var/www/staging/public.

Nginx on tehokas tässä roolissa – sen tapahtumapohjainen arkkitehtuuri hallitsee suuretkin samanaikaiset yhteydet kevyellä resurssien käytöllä. Siksi Nginx on suosittu jaettu hostingissa, VPS:llä, pilvipalvelimilla ja korkean liikenteen sovelluksissa. Usean sivuston hallinta vaatii huolellista suunnittelua: oikeat tiedosto-oikeudet, DNS-tietueet, SSL-asennus ja lokien erottelu ovat avainasemassa.

Milloin Nginx serverilohkoja kannattaa käyttää?

Nginx serverilohkoja käytetään, kun haluat hallita useita verkkosivustoja yhdellä palvelimella. Tämä voi olla kaksi pientä yrityssivua, useita asiakasprojekteja, alidomaineja tai mikropalveluita. Tärkeää on, että jokainen projekti on loogisesti erotettu omakseen.

Haluat julkaista useita domaineja samalla VPS:llä.
Haluat ohjata www- ja non-www-osoitteet yhteen kanoniseen osoitteeseen.
Alidomainit tulee ohjata eri kansioihin tai sovelluksiin.
Tarvitset jokaiselle sivulle oman SSL-sertifikaatin ja turvallisuuspolitiikan.
Seuraat asiakasprojektien liikennettä omilla lokitiedostoilla.
Pyörität WordPressiä, Laravelia, staattista HTML:ää ja Node.js:ää samalla palvelimella.

Esimerkiksi digitaalinen toimisto voi julkaista 8 pientä yrityssivua yhdellä 4 GB RAM VPS:llä – mutta jokaisen sivuston liikenne, levytila, PHP-prosessien määrä, tietokantakuorma ja varmuuskopiointi on arvioitava erikseen. Jos projektit ovat suuria tai eristys on tärkeää, kannattaa harkita tehokkaampaa VPS:ää, pilvipalvelinta tai hallittua hostingia. Vertaa Verkkohosting ja Yrityshosting vaihtoehtoja tarpeen mukaan.

Vaatimukset ennen aloitusta

Tässä oppaassa käytämme Ubuntu- tai Debian-pohjaista Linux-palvelinta. Komennot voivat erota hieman jakelusta riippuen, mutta logiikka on sama. Ota aina varmuuskopio ennen tuotantoympäristön muutoksia – väärä Nginx-konfiguraatio voi tehdä kaikki sivustot tilapäisesti saavuttamattomiksi.

Tekniset valmistelut

Linux-käyttäjä, jolla on root- tai sudo-oikeudet.
Toimiva Nginx-palvelu.
Vähintään yksi domain ohjattuna palvelimen IP-osoitteeseen.
Palomuuri sallii portit 80 (HTTP) ja 443 (HTTPS).
Selkeä kansiorakenne sivustojen tiedostoille.
Voimassa oleva SSL-sertifikaatti tai ilmainen Let’s Encrypt.
PHP-FPM asennettuna PHP-sivustoille.

DNS:ssa A-tietue ohjaa päädomainin IPv4-osoitteelle, AAAA-tietue (jos käytössä) IPv6:lle. Alidomainit kuten www voidaan ohjata CNAME- tai A-tietueilla. DNS-muutosten propagaatio kestää yleensä muutamista minuuteista 24 tuntiin. Nopeampi asennus onnistuu, kun DNS-tietueet ovat valmiina ennen Nginx-konfiguraation rakentamista.

Suositeltu kansiorakenne

Yksi yleisimmistä virheistä monen sivuston hostingissa on kaikkien tiedostojen sekoittaminen yhteen kansioon. Tämä voi näyttää helpolta lyhyellä aikavälillä, mutta vaikeuttaa ylläpitoa, varmuuskopiointia ja debuggausta. Paras tapa on luoda jokaiselle domainille oma yläkansio, jonka sisällä on public, logs, backups jne.

Esimerkki: /var/www/sivusto1.fi/public, /var/www/sivusto1.fi/logs, /var/www/sivusto2.fi/public ja /var/www/sivusto2.fi/logs. Nginx:n root osoittaa public-kansioon – näin varmistat, että .env, varmuuskopiot ja muut arkaluonteiset tiedostot eivät ole suoraan verkosta luettavissa.

Jokaisen sivuston kansioon kannattaa luoda testiksi yksinkertainen index.html, jossa lukee sivuston nimi – näin voit nopeasti varmistaa, mikä serverilohko aktivoituu. Tuotantoympäristössä kansioiden omistaja on usein www-data tai deployment-käyttäjä. Kansioiden oikeudet 755 ja tiedostojen 644 riittävät useimmissa tapauksissa. WordPressin kaltaisissa järjestelmissä uploads-kansion oikeudet tulee määritellä erikseen.

Serverilohkon luominen vaihe vaiheelta

Alla olevat vaiheet käydään läpi esimerkkinä sivusto1.fi domainilla. Sama ohje toimii myös muille sivustoille – tärkeintä on, että jokaiselle sivulle on oma server_name, root ja lokitiedosto.

1. Luo sivuston kansio

Ensimmäinen askel on luoda kansio, jossa verkkotiedostot sijaitsevat. Esimerkki: sudo mkdir -p /var/www/sivusto1.fi/public. Testiksi voit luoda tiedoston /var/www/sivusto1.fi/public/index.html, jonka sisältö on vaikka "Tämä on sivusto1.fi testisivu".

Oikea omistajuus: sudo chown -R www-data:www-data /var/www/sivusto1.fi. Jos deployaat eri käyttäjällä, säädä ryhmäoikeudet sen mukaan. Vältä 777-oikeuksia – ne altistavat palvelimen hyökkäyksille.

2. Luo serverilohko-tiedosto

Yleinen käytäntö on tallentaa ei-aktiiviset konfiguraatiot /etc/nginx/sites-available kansioon ja tehdä niistä symbolinen linkki /etc/nginx/sites-enabled kansioon. Esimerkki: /etc/nginx/sites-available/sivusto1.fi

Yksinkertainen HTTP-serverilohko:


server {
    listen 80;
    server_name sivusto1.fi www.sivusto1.fi;
    root /var/www/sivusto1.fi/public;
    index index.html index.htm;

    access_log /var/log/nginx/sivusto1.fi.access.log;
    error_log /var/log/nginx/sivusto1.fi.error.log;

    location / {
        try_files $uri $uri/ =404;
    }
}

Tässä listen 80 vastaanottaa HTTP-liikenteen, server_name määrittää domainit, root osoittaa public-kansioon, index asettaa oletustiedostot. try_files palauttaa 404, jos tiedostoa ei löydy. Staattisille sivuille tämä riittää.

3. Aktivoi sivusto

Konfiguraation aktivointi: sudo ln -s /etc/nginx/sites-available/sivusto1.fi /etc/nginx/sites-enabled/sivusto1.fi. Symbolinen linkki on parempi kuin kopiointi – muutokset päivittyvät automaattisesti.

Jos et halua Nginxin oletussivua sivustosi eteen, poista default-konfiguraation linkki /etc/nginx/sites-enabled/default. Varmista kuitenkin, että oma serverilohkosi toimii ennen oletuksen poistamista.

4. Testaa asetukset ja lataa Nginx uudelleen

Jokaisen muutoksen jälkeen testaa konfiguraatio: sudo nginx -t. Jos testit menevät läpi, lataa palvelu: sudo systemctl reload nginx. reload on yleensä turvallisempi kuin restart, koska se hallitsee olemassa olevat yhteydet pehmeämmin.

Jos testit epäonnistuvat, saat yleensä virheilmoituksen tiedoston ja rivin mukaan. Tyypilliset virheet: puuttuva puolipiste, väärä hakasulku, virheellinen kansiopolku tai päällekkäinen server_name. Älä lataa Nginxiä ennen kuin virheet on korjattu.

Toisen ja kolmannen sivuston lisääminen

Monen sivuston hallinnan etu on, että ensimmäisen kunnon asennuksen jälkeen prosessi on helposti toistettavissa. Luo esim. /var/www/sivusto2.fi/public kansio, kirjoita /etc/nginx/sites-available/sivusto2.fi tiedosto, vaihda root ja lokitiedostot sivusto2.fi:lle, tee symbolinen linkki ja testaa Nginx.

Toisen sivuston serverilohko:


server {
    listen 80;
    server_name sivusto2.fi www.sivusto2.fi;
    root /var/www/sivusto2.fi/public;
    index index.html;

    access_log /var/log/nginx/sivusto2.fi.access.log;
    error_log /var/log/nginx/sivusto2.fi.error.log;

    location / {
        try_files $uri $uri/ =404;
    }
}

Erilliset lokitiedostot ovat arvokkaita – jos yhdessä sivustossa 404-virheet lisääntyvät, toisessa ei, löydät syyn nopeasti. Samoin liikenteen analyysi, bottien hyökkäykset, rikkinäiset linkit ja suorituskykyongelmat voidaan seurata sivustokohtaisesti.

SSL ja HTTPS-konfiguraatio

Vuoden 2026 SEO-vaatimuksissa HTTPS on paitsi turvallisuutta, myös teknisen laadun ja käyttäjäluottamuksen mittari. Selaimet merkitsevät HTTP-sivut epäluotettaviksi; maksut, kirjautumiset, lomakkeet ja hallintapaneelit vaativat SSL:n. Monen sivuston hostingissa jokaiselle domainille tulee määrittää oikea sertifikaatti. Hostragonsin SSL-sertifikaatik -sivulta löydät sopivat ratkaisut.

Let’s Encryptillä voit hankkia sertifikaatit jokaiselle domainille Certbotilla. Esimerkki: certbot --nginx -d sivusto1.fi -d www.sivusto1.fi tunnistaa Nginx-konfiguraation ja lisää HTTPS-lohkon automaattisesti. Tarkista kuitenkin tiedosto käsin – joskus syntyy virheellisiä ohjauksia tai päällekkäisiä lohkoja.

HTTPS-konfiguraatiossa on tapana ohjata portin 80 liikenne pysyvästi portille 443. 301-uudelleenohjaus on SEO:n kannalta pysyvä signaali. Valitse, käytätkö www:ta vai et, ja ohjaa kaikki versiot yhteen kanoniseen osoitteeseen. Esimerkiksi jos haluat https://sivusto1.fi, ohjaa sekä HTTP että HTTPS www-liikenne non-www-osoitteeseen. Tämä vähentää duplikaattisisällön riskiä.

Nginx serverilohkot PHP:lle ja WordPressille

Staattisilla HTML-sivuilla konfiguraatio on helppo, mutta WordPressin, Laravelin ja muiden PHP-sovellusten kanssa tarvitaan PHP-FPM-yhteys. Tällöin määritellään index.php ja ohjataan PHP-pyynnöt oikeaan socketiin. Esimerkiksi Ubuntu:ssa PHP 8.3:n socket on /run/php/php8.3-fpm.sock. Versio riippuu palvelimesta.

PHP-pohjainen serverilohko:


server {
    listen 80;
    server_name wordpress-sivusto.fi www.wordpress-sivusto.fi;
    root /var/www/wordpress-sivusto.fi/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;
    }
}

WordPressissa pysyvien osoitteiden toimivuuden kannalta try_files $uri $uri/ /index.php?$args on tärkeä. Lisäksi xmlrpc.php:n rajoitus, wp-login.php:n rate limiting, uploads-kansion PHP-esto ja muut turvallisuustoimet kannattaa miettiä. Jos hostaat useita WordPress-sivustoja samalla VPS:llä, luo jokaiselle oma tietokanta, käyttäjä ja päivityspolitiikka. Jos etsit helpompaa ratkaisua, WordPress hosting voi olla sopiva vaihtoehto.

Nginx serverilohkot vs. Apache VirtualHost

Nginx ja Apache saavuttavat saman lopputuloksen eri arkkitehtuurilla. Molemmilla voi ylläpitää useita sivustoja yhdellä palvelimella. Valinta riippuu sovelluksen vaatimuksista, hallintatottumuksista ja suorituskykyodotuksista.

Nginx serverilohkot vs. Apache VirtualHost
Kriteeri	Nginx serverilohkot	Apache VirtualHost
Suorituskyky	Erinomainen samanaikaisessa liikenteessä, kevyt resurssien käyttö.	Voi kuluttaa enemmän resursseja modulien ja prosessimallin vuoksi.
Asetukset	Yksinkertainen ja keskitetty konfiguraatio.	.htaccess mahdollistaa hakemistokohtaisen joustavuuden.
Staattisten tiedostojen jako	Nopea ja tehokas.	Hyvä suorituskyky, mutta Nginx yleensä kevyempi.
PHP:n ajaminen	PHP-FPM:n kautta.	mod_php tai PHP-FPM käytettävissä.
Käyttötilanteet	Reverse proxy, staattiset tiedostot, korkea liikenne ja modernit sovellukset.	.htaccess-riippuvaiset legacy-sovellukset ja jaettu hosting.

Jos sovelluksesi vaatii paljon .htaccess-sääntöjä, Apache voi olla helpompi. Korkean liikenteen, reverse proxy, välimuisti ja moderni devops-ympäristö hyötyvät usein Nginxistä. Joissain tapauksissa Nginx voi toimia reverse proxyna ja Apache taustapalvelimena.

Turvallisuuden parhaat käytännöt

Usean sivuston hostaus samalla palvelimella säästää kustannuksia, mutta lisää turvallisuusvastuuta. Haavoittuvuus yhdessä sivustossa voi vaikuttaa kaikkiin, joten eristäminen ja minimioikeudet ovat tärkeitä.

Luo jokaiselle sivustolle oma tietokanta ja tietokantakäyttäjä.
Rajoita web-juuri vain public-kansioon.
Pidä varmuuskopiot, .env, .git, config ja SQL-tiedostot poissa webistä.
Uudista SSL-sertifikaatit säännöllisesti ja pakota HTTPS-uudelleenohjaus.
Käytä UFW:tä tai muuta palomuuria – avaa vain tarvittavat portit.
Päivitä Nginx ja käyttöjärjestelmä säännöllisesti.
Pidä access_log ja error_log erillisinä sivustokohtaisesti.
Lisää IP-rajoitus ja/tai lisäautentikointi hallintapaneeleihin.
Vältä 777-tiedosto-oikeuksia.

Lisäksi HTTP-headerit kuten X-Frame-Options, X-Content-Type-Options, Referrer-Policy ja Content-Security-Policy voivat parantaa turvallisuutta. Content-Security-Policy on testattava huolellisesti – väärä asetus voi estää skriptit ja tyylit. Lisää tietoa verkkosivuston turvallisuus -sisällöistä.

Suorituskyky ja SEO – mitä huomioida?

Nginx-serverilohkot vaikuttavat myös suorituskykyyn ja SEO-laatuun. Väärät uudelleenohjausketjut, puutteelliset kanoniset osoitteet, puuttuva gzip tai brotli-pakkaus, isot lokitiedostot ja huono välimuistipolitiikka voivat hidastaa sivustoa. Googlen sivukokemus on käyttäjäkeskeinen – nopea, turvallinen ja vakaa sivusto menestyy paremmin.

Määrittele domainille yksi kanoninen versio. Tee HTTP → HTTPS, www → non-www (tai päinvastoin) yhdellä 301-uudelleenohjauksella. Vältä ketjut: http://sivusto.fi → http://www.sivusto.fi → https://www.sivusto.fi → https://sivusto.fi. Parempi on yksi suora 301.

Staattisille tiedostoille määritä cache-control-headerit. Kuvia, CSS:ää ja JavaScriptiä voi pitää selaimessa määräajan. Muuttuvissa tiedostoissa käytä tiedostonimi-versionointia tai query string -strategiaa. Gzip-pakkaus pienentää HTML-, CSS-, JS- ja JSON-tiedostojen kaistan käyttöä. Suurilla sivuilla harkitse Nginx microcache, FastCGI cache tai CDN:n käyttöä. CDN:stä lisää Mitä CDN On -sisällössä.

Lokien hallinta ja valvonta

Lokien hallinta on avain monen sivuston hostingissa. Erilliset lokitiedostot osoittavat selvästi, missä sivustossa virhe tapahtui. access_log tallentaa vierailijat, error_log konfiguraatio-, oikeus-, tiedostopuuttumis- ja backend-virheet. 502 Bad Gateway liittyy usein PHP-FPM:ään tai backend-palveluun. 403 Forbidden on oikeus- tai index-tiedostovirhe. 404 Not Found voi johtua polusta, uudelleenkirjoituksesta tai DNS:n jälkeen väärästä rootista.

Lokitiedostojen kasvua kannattaa hallita logrotate:lla. Pienissä projekteissa päivittäinen tai viikoittainen rotaatio riittää. Suurella liikenteellä keskitetty logien keräys, metrikat ja hälytykset ovat hyödyllisiä. Liian täysi levy estää Nginxin logien kirjoituksen, tietokannan ja sivustot. Aseta käytännölliset raja-arvot levyn käytölle.

Yleisimmät virheet ja pikaratkaisut

Nginx-serverilohkojen kanssa törmäät todennäköisesti näihin virheisiin – niiden tunteminen nopeuttaa asennusta.

Domain avaa väärän sivuston: tarkista server_name-päällekkäisyydet ja default-lohko.
403 Forbidden: tarkista root, tiedosto-oikeudet ja index-tiedoston olemassaolo.
404 Not Found: tarkista root-polku ja try_files-sääntö.
502 Bad Gateway: varmista PHP-FPM-palvelun toimivuus ja oikea socket-polku.
SSL-sertifikaatti väärällä sivustolla: tarkista 443-lohkon server_name ja sertifikaattitiedostot.
Ohjauskierre: yksinkertaista HTTP/HTTPS ja www/nowww-uudelleenohjaukset.
Nginx reload ei onnistu: korjaa syntaksivirheet nginx -t -tuloksen mukaan.

Kokenut ylläpitäjä käy läpi tämän checklistin: DNS oikein? Nginx-konfiguraatio aktiivinen? root-kansio olemassa? oikeudet kunnossa? palvelu läpäisee testin? mitä logi kertoo? Näillä askelilla ratkot ongelmat ilman paniikkia.

Tuotantoympäristön tarkistuslista

Ennen julkaisua käy läpi tämä lista jokaiselle sivustolle. Asiakasprojekteissa tämän dokumentointi luo ammattimaisen standardin.

Domainin A- tai AAAA-tietue ohjaa oikeaan IP-osoitteeseen.
www- ja non-www-versioista yksi on valittu kanoniseksi.
HTTP-liikenne ohjataan HTTPS:lle yhdellä 301:llä.
SSL-sertifikaatti voimassa ja automaattinen uusinta päällä.
Jokaisella sivustolla oma root ja lokitiedostot.
Nginx-konfiguraatio testattu sudo nginx -t:llä.
Varmuuskopiointisuunnitelma ja palautustesti tehty.
Tiedosto-oikeudet minimioikeuden mukaiset.
Palomuurissa vain tarvittavat portit auki.
Virhelokit seurattu vähintään 15 minuuttia julkaisun jälkeen.

Pieni lista, mutta tuotantoprojekteissa se vähentää katkoksen riskiä merkittävästi. SSL:n uusinta, DNS-tarkistus ja lokien seuranta poimivat useimmat näkymättömät virheet ajoissa.

Yhteenveto

Nginx-serverilohkot ovat perusta usean sivuston hallintaan yhdellä palvelimella – järjestelmällisesti, turvallisesti ja suorituskykyisesti. Oikea kansiorakenne, erilliset konfiguraatiot, selkeät ohjaussäännöt, HTTPS, lokien erottelu ja säännöllinen testaus tekevät monisivuston ylläpidosta tehokasta. Samat periaatteet pätevät niin pieniin portfolioihin kuin suuriin asiakasprojekteihin.

Julkaistaessa uutta projektia: määritä domain, palvelinresurssit ja SSL-tarpeet, käy läpi yllä oleva checklist, ja rakenna Nginx-konfiguraatio vaihe vaiheelta. Jos kaipaat hallittua hostingia, tutustu Hostragonsin Hosting-paketit, VPS palvelin ja SSL-sertifikaatik -ratkaisuihin ja valitse sopiva aloitus.

Usein kysytyt kysymykset

Kuinka monta sivustoa voi hostata Nginx-serverilohkoilla?

Teknisesti voit hostata hyvin monta sivustoa – rajoitteina ovat CPU, RAM, levytila, liikenne, tietokantakuorma ja PHP-FPM:n kapasiteetti. Staattisissa, vähän liikennettä tuottavissa sivustoissa voi olla kymmeniä, mutta suurissa WordPress- tai verkkokauppaprojekteissa kannattaa rajoittaa määrää.

Tuleeko jokaiselle sivustolle olla oma SSL-sertifikaatti?

Kyllä – jos domain tai alidomain julkaistaan HTTPS:llä, sen tulee sisältyä sertifikaattiin. Voit käyttää yksittäisiä, SAN- tai wildcard-sertifikaatteja. Tärkeää on, että Nginx 443-lohkossa oikea sertifikaattitiedosto on oikealle domainille.

Voiko Nginx-serverilohkolla julkaista alidomainin?

Kyllä. Esim. blog.sivusto.fi tai panel.sivusto.fi – määritä oma server_name ja ohjaa haluttuun juurikansioon tai backend-palveluun. DNS:ssa tee A- tai CNAME-tietue alidomainille.

Mikä ero on sites-available ja sites-enabled kansioilla?

sites-available sisältää kaikki mahdolliset konfiguraatiot; sites-enabled vain aktiiviset. Yleensä sites-enabled kansiossa on symbolinen linkki sites-available tiedostoon – näin aktivointi ja deaktivointi on hallittua.

Miksi väärä sivusto avautuu?

Yleisimmät syyt: DNS ohjaa väärään IP-osoitteeseen, server_name on virheellinen, Nginxin oletuslohko nappaa pyynnön tai 443-lohkossa väärä SSL. Tarkista DNS-tietueet, nginx -t -tulos, sites-enabled linkit ja access_log.

Nginx serverilohkot: Usean verkkosivuston ylläpito yhdellä palvelimella