Meerdere websites hosten met Nginx server blocks (virtual hosts)

Nginx server blocks zijn de virtuele hosts van Nginx waarmee je meerdere domeinnamen of websites op één enkele Nginx-installatie kunt draaien, elk met een eigen configuratie. Zo kun je op dezelfde VPS bijvoorbeeld example.com, blog.example.com en tweede-site.nl elk een eigen rootmap, logbestanden, SSL-certificaten en PHP-instellingen geven. Kort gezegd komt het neer op: voor elke site een aparte map maken, de DNS-records van het domein naar het IP-adres van de server laten wijzen, een server block bestand aanmaken in /etc/nginx/sites-available, deze activeren via een symlink in sites-enabled, de configuratie testen en Nginx herstarten.

In deze handleiding nemen we het proces van meerdere sites hosten met Nginx server blocks stap voor stap door, gericht op een productieomgeving. Het doel is niet alleen een werkende setup, maar ook een beheerbare, veilige, snelle, back-upvriendelijke en schaalbare omgeving. Vooral voor webbureaus, developers, e-commerce eigenaren, bedrijven met meerdere merken en systeembeheerders die meerdere projecten op één server draaien, delen we praktische tips. Heb je nog geen server? Bekijk dan eerst onze pagina’s over VPS server en domeinregistratie via Domeinregistratie.

Wat zijn Nginx server blocks?

Nginx server blocks zijn configuratieblokken binnen Nginx die bepalen naar welke website een inkomend HTTP of HTTPS verzoek wordt gestuurd. Dit concept is vergelijkbaar met de VirtualHost in Apache. Wanneer een bezoeker een domeinnaam in de browser intypt, vertaalt DNS dat naar het IP-adres van je server. Nginx kijkt vervolgens naar de Host-header in het verzoek en kiest het server block waarvan de server_name overeenkomt.

Op deze manier kun je tientallen websites draaien op hetzelfde IP-adres en dezelfde fysieke of virtuele server. Voor elke site kun je een eigen root directory, toegang- en foutlog, redirectregels, SSL-certificaat, cachebeleid en beveiligingsregels instellen. Bijvoorbeeld: je bedrijfswebsite staat in /var/www/bedrijf/public, je blog in /var/www/blog/public en een testomgeving in /var/www/staging/public.

Nginx is zeer efficiënt in deze opzet doordat het event-driven is en veel gelijktijdige verbindingen met weinig middelen kan verwerken. Daarom is het populair voor shared hosting, VPS, cloud servers en drukbezochte applicaties. Voor een vlekkeloze werking van meerdere sites moet je echter elk detail goed plannen, van bestandsrechten en DNS tot SSL-installatie en logscheiding.

Wanneer gebruik je Nginx server blocks?

Nginx server blocks zijn ideaal als je op één server meerdere websites of webapplicaties wilt beheren. Dat kan variëren van een paar kleine bedrijfswebsites tot tientallen klantprojecten, subdomeinen of microservices. Cruciaal is dat elke site logisch gescheiden blijft.

• Als je meerdere domeinnamen op één VPS wilt hosten.
• Als je www en niet-www domeinen naar één canonieke URL wilt doorverwijzen.
• Als je subdomeinen naar verschillende mappen of applicaties wilt laten wijzen.
• Als je voor elke site aparte SSL-certificaten en beveiligingsregels wilt instellen.
• Als je klantprojecten met aparte logbestanden wilt monitoren.
• Als je verschillende applicaties zoals Laravel, WordPress, statische HTML of Node.js op dezelfde server wilt draaien.

Een digitaal bureau kan bijvoorbeeld technisch 8 kleine bedrijfswebsites op een VPS met 4 GB RAM hosten. Wel moet je per site rekening houden met verkeer, schijfruimte, PHP-processen, databasebelasting en back-up frequentie. Bij veel verkeer of kritieke isolatie is een krachtigere VPS, cloud server of managed hosting aan te raden. Vergelijk hiervoor onze Web Hosting en Zakelijk Hosting pakketten.

Vereisten vóór je begint

We gaan uit van een Linux server met Ubuntu of Debian. Commando’s kunnen per distributie iets verschillen, maar de basis blijft hetzelfde. Maak altijd een back-up voordat je in een productieomgeving aanpassingen doet; een fout in de Nginx-config kan alle sites tijdelijk onbereikbaar maken.

Benodigde technische voorbereidingen

• Een Linux gebruiker met root of sudo rechten.
• Een geïnstalleerde en actieve Nginx service.
• Minimaal één domeinnaam die naar het server IP verwijst.
• Poorten 80 en 443 open in de firewall.
• Een overzichtelijke mappenstructuur voor je sites.
• Een geldig SSL-certificaat of gratis Let’s Encrypt certificaat.
• Voor PHP-applicaties: PHP-FPM geïnstalleerd.

DNS richt A-records naar het IPv4-adres en AAAA-records naar IPv6, indien beschikbaar. Subdomeinen zoals www kunnen via CNAME of A-records gekoppeld worden. DNS-propagatie duurt meestal enkele minuten tot 24 uur. Begin met DNS-instellingen voordat je Nginx server blocks configureert, dat versnelt het proces.

Aanbevolen mappenstructuur

Een veelgemaakte fout bij het hosten van meerdere sites is alle bestanden door elkaar in één map plaatsen. Dat lijkt makkelijk, maar leidt tot veel onderhoudsproblemen en tijdverlies bij back-ups en troubleshooting. Beter is voor elk domein een aparte hoofdmap te maken met daarbinnen submappen zoals public, logs en backups.

Een voorbeeldstructuur is: /var/www/site1.nl/public, /var/www/site1.nl/logs, /var/www/site2.nl/public, /var/www/site2.nl/logs. De root in Nginx verwijst direct naar de public map, zodat applicatiebestanden, .env bestanden en backups niet publiekelijk toegankelijk zijn.

Om te testen kun je in elke public map een eenvoudige index.html plaatsen met bijvoorbeeld de naam van de site, zodat je snel ziet welk server block actief is. In productie zijn de mappen vaak eigendom van www-data of een deployment gebruiker. Bestandsrechten zijn meestal 755 voor mappen en 644 voor bestanden voldoende. Bij WordPress en andere schrijvende applicaties moet je mappen zoals uploads apart behandelen.

Stap voor stap een Nginx server block aanmaken

Hieronder gebruiken we site1.nl als voorbeeld. Voor sites 2, 3 etc. herhaal je dezelfde stappen, met unieke server_name, root en logbestanden per site.

1. Maak de site map aan

Maak eerst de map voor je webbestanden aan, bijvoorbeeld met sudo mkdir -p /var/www/site1.nl/public. Maak daarna een testbestand /var/www/site1.nl/public/index.html met een herkenbare tekst zoals “Dit is de testpagina van site1.nl”.

Stel de juiste eigenaar in met sudo chown -R www-data:www-data /var/www/site1.nl. Pas de groep aan als je met een andere deployment user werkt. Vermijd rechten 777 in productie, dat kan beveiligingsrisico’s geven.

2. Maak het server block bestand aan

De standaardpraktijk is om configuraties in /etc/nginx/sites-available te plaatsen en ze via symlinks in sites-enabled te activeren. Maak bijvoorbeeld /etc/nginx/sites-available/site1.nl aan.

Een eenvoudige HTTP server block ziet er zo uit:
server {
  listen 80;
  server_name site1.nl www.site1.nl;
  root /var/www/site1.nl/public;
  index index.html index.htm;
  access_log /var/log/nginx/site1.nl.access.log;
  error_log /var/log/nginx/site1.nl.error.log;
  location / {
    try_files $uri $uri/ =404;
  }
}

Hier luistert listen 80 naar HTTP-verkeer, server_name geeft de domeinen aan, root wijst naar je webmap, index definieert de standaardbestanden, en try_files zorgt dat een 404 wordt gegeven als het bestand niet bestaat. Voor statische sites is dit voldoende.

3. Activeer de site

Maak een symlink aan om de configuratie te activeren: sudo ln -s /etc/nginx/sites-available/site1.nl /etc/nginx/sites-enabled/site1.nl. Dit is beter dan kopiëren, want bij wijzigingen blijft het bestand consistent.

Als je niet wilt dat de standaard Nginx pagina voorrang krijgt, kun je de default symlink verwijderen met sudo rm /etc/nginx/sites-enabled/default. Controleer eerst dat je eigen site correct werkt.

4. Test de configuratie en herstart Nginx

Voer na elke wijziging sudo nginx -t uit om de syntax te controleren. Is alles oké, herlaad dan Nginx zonder downtime met sudo systemctl reload nginx. Deze reload is veiliger dan een volledige restart omdat actieve verbindingen soepeler worden afgehandeld.

Bij fouten geeft nginx -t meestal een regelnummer met de oorzaak, bijvoorbeeld ontbrekende puntkomma’s, verkeerde accolades, onjuiste paden of dubbele server_name waarden. Los deze eerst op voordat je Nginx herstart.

Een tweede en derde site toevoegen

Het voordeel van meerdere sites is dat je na een correcte eerste setup eenvoudig extra sites toevoegt. Maak voor site2.nl een map /var/www/site2.nl/public, maak een server block bestand /etc/nginx/sites-available/site2.nl met aangepaste root en logs, activeer met een symlink en test Nginx opnieuw.

Een simpel voorbeeld voor site2.nl:
server {
  listen 80;
  server_name site2.nl www.site2.nl;
  root /var/www/site2.nl/public;
  index index.html;
  access_log /var/log/nginx/site2.nl.access.log;
  error_log /var/log/nginx/site2.nl.error.log;
  location / {
    try_files $uri $uri/ =404;
  }
}

Gescheiden logs per site zijn erg waardevol in de praktijk. Zo kun je bijvoorbeeld bij 404-fouten meteen zien welke site het betreft. Ook traffic analyses, botaanvallen, broken links en performance issues monitor je zo per website.

SSL en HTTPS instellen

In 2026 is HTTPS niet alleen een veiligheidsvereiste, maar ook een SEO- en betrouwbaarheidsfactor. Browsers markeren HTTP-sites als onveilig; voor betalingspagina’s, lidmaatschappen, formulieren en beheerpaneel is SSL verplicht. Bij meerdere sites moet je voor elk domein het juiste certificaat instellen. Bekijk onze SSL certificaten voor meer opties.

Met Let’s Encrypt kun je via Certbot gratis certificaten aanvragen. Bijvoorbeeld met certbot --nginx -d site1.nl -d www.site1.nl wordt Nginx automatisch aangepast en een HTTPS server block toegevoegd. Controleer altijd handmatig de configuratie na automatische aanpassingen om redirect loops of dubbele server blocks te voorkomen.

Meestal wordt HTTP (poort 80) permanent doorgestuurd naar HTTPS (poort 443) met een 301 redirect. Kies of je www wilt gebruiken en verzamel alle varianten op één canonieke URL. Wil je bijvoorbeeld https://site1.nl gebruiken zonder www, stuur dan ook www-verkeer via HTTP en HTTPS netjes door naar die ene URL. Dit voorkomt duplicate content issues.

Nginx server blocks voor PHP en WordPress

Voor statische sites is de configuratie eenvoudig, maar WordPress, Laravel of andere PHP-applicaties vereisen integratie met PHP-FPM. Je voegt index.php toe aan index en stuurt PHP-verzoeken door naar de PHP-FPM socket. Op Ubuntu met PHP 8.3 is dat vaak /run/php/php8.3-fpm.sock, maar dit kan verschillen per server.

Een voorbeeld server block voor WordPress:
server {
  listen 80;
  server_name wordpress-site.nl www.wordpress-site.nl;
  root /var/www/wordpress-site.nl/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;
  }
}

De try_files regel is cruciaal voor WordPress permalinks. Verder kun je beveiligingsmaatregelen toepassen zoals het beperken van toegang tot xmlrpc.php, wp-login.php en het uitsluiten van PHP uitvoering in uploads. Host je meerdere WordPress sites? Zorg dan dat elke site een eigen database, eigen gebruiker en updatebeleid heeft. Voor een eenvoudigere ervaring kun je ook kiezen voor WordPress hosting.

Vergelijking Nginx server blocks en Apache VirtualHost

Nginx en Apache bereiken hetzelfde doel met verschillende architecturen. Beide kunnen meerdere sites op één server hosten. De keuze hangt af van je applicatie, beheerstijl en prestatie-eisen.

Als je sterk afhankelijk bent van .htaccess regels, is Apache vaak eenvoudiger. Voor hoge traffic, reverse proxy setups, caching en moderne deployment workflows is Nginx meestal krachtiger. Sommige setups gebruiken Nginx als reverse proxy en Apache als backend server.

Beveiligingstips

Meerdere sites op één server besparen kosten, maar verhogen ook het beveiligingsrisico. Voorkom dat een kwetsbaarheid in één site de rest raakt door isolatie en het principe van minimale rechten toe te passen.

• Gebruik voor elke site een aparte database en databasegebruiker.
• Beperk de web root tot alleen de public map.
• Houd backups, .env, .git, config en SQL bestanden buiten de webroot.
• Vernieuw SSL-certificaten tijdig en forceer HTTPS.
• Gebruik een firewall zoals UFW en open alleen noodzakelijke poorten.
• Houd Nginx en het besturingssysteem up-to-date.
• Houd gescheiden access_log en error_log per site bij.
• Beperk toegang tot beheerpaneel met IP whitelist of extra authenticatie.
• Vermijd brede bestandsrechten zoals 777.

Het toevoegen van basisveiligheidsheaders zoals X-Frame-Options, X-Content-Type-Options, Referrer-Policy en Content-Security-Policy kan ook helpen. Let op dat CSP onjuist kan leiden tot blokkades in scripts en styles, dus test dit eerst in een testomgeving. Voor meer veiligheidstips zie website beveiliging.

Optimalisaties voor performance en SEO

Nginx server blocks beïnvloeden niet alleen hosting, maar ook snelheid en SEO. Verkeerde redirects, onjuiste canonicals, ontbrekende compressie (gzip of brotli), te grote logs en slechte cache instellingen kunnen de laadtijd verslechteren. Google hecht steeds meer waarde aan snelle, veilige en stabiele sites in haar ranking.

Zorg dat elke domein één canonieke URL heeft. Redirect HTTP naar HTTPS en verzamel www en niet-www varianten in één adres. Vermijd redirectketens zoals http://site.nl → http://www.site.nl → https://www.site.nl → https://site.nl. Gebruik liever één 301 redirect naar de uiteindelijke URL.

Gebruik cache-control headers voor statische content zoals afbeeldingen, CSS en JS om browsercache te stimuleren. Voor vaak veranderende bestanden kun je versiebeheer toepassen in bestandsnamen of query strings. Grote sites kunnen Nginx microcache, FastCGI cache of CDN inzetten. Voor uitleg over CDN’s kun je kijken op Wat is CDN.

Logbeheer en monitoring

Logbestanden zijn essentieel bij het beheren van meerdere sites. Gescheiden logs maken het makkelijk om fouten en verkeer per site te analyseren. access_log registreert bezoekersverkeer, error_log houdt fouten bij zoals configuratieproblemen, permissies, ontbrekende bestanden en backend fouten.

Een 502 Bad Gateway wijst vaak op problemen met PHP-FPM of backend services. 403 Forbidden duidt meestal op permissieproblemen of het ontbreken van een indexbestand. 404 Not Found kan wijzen op een verkeerde root of fout in try_files.

Let op dat logs niet onbeperkt groeien. Gebruik logrotate om logs regelmatig te roteren. Kleine projecten volstaan vaak met dagelijkse of wekelijkse rotatie. Drukbezochte sites profiteren van centrale logverzameling, metrics monitoring en alerts. Een volle schijf kan ervoor zorgen dat Nginx niet meer kan schrijven, databases vastlopen en websites offline gaan. Stel daarom drempels in voor schijfruimte monitoring.

Veelvoorkomende fouten en snelle oplossingen

Bij Nginx server blocks kom je vaak dezelfde problemen tegen. Deze kennis bespaart tijd bij het inrichten.

• Verkeerde site wordt geladen: controleer server_name conflicten en het default server block.
• 403 Forbidden fout: check root map, bestandsrechten en aanwezigheid van indexbestand.
• 404 Not Found fout: controleer root pad en try_files regel.
• 502 Bad Gateway fout: controleer of PHP-FPM draait en socket pad klopt.
• SSL-certificaat hoort bij verkeerde site: controleer 443 server_name en certificaatbestanden.
• Redirect loops: vereenvoudig HTTP/HTTPS en www doorverwijzingen.
• Nginx reload mislukt: pas configuratie aan op basis van foutmelding en regelnummer uit sudo nginx -t.

Een checklist van ervaren beheerders: is DNS correct? Is de Nginx configuratie actief? Bestaat de root map? Kloppen de rechten? Is de service getest? Wat zeggen de logs? Stap voor stap hiermee voorkom je paniek en los je problemen snel op.

Praktische checklist voor productie

Voordat je live gaat, controleer per site deze punten. Vooral bij klantprojecten is het goed om dit vast te leggen als professioneel proces.

• Domein wijst met A of AAAA record naar het juiste IP.
• Er is één canonieke variant gekozen tussen www en niet-www.
• HTTP wordt met een 301 permanent doorverwezen naar HTTPS.
• SSL-certificaat is geldig en automatische vernieuwing werkt.
• Elke site heeft aparte root en logbestanden.
• Nginx configuratie is gevalideerd met sudo nginx -t.
• Back-up schema is opgesteld en herstel getest.
• Bestandsrechten zijn minimaal en veilig ingesteld.
• Firewall staat alleen noodzakelijke poorten toe.
• Foutlogs zijn minimaal 15 minuten na livegang gemonitord.

Deze lijst lijkt simpel, maar voorkomt veel downtime en problemen. Vooral SSL-vernieuwing, DNS-instellingen en logmonitoring vangen veel onzichtbare fouten vroeg op.

Conclusie

Nginx server blocks zijn een krachtige manier om meerdere websites op één server overzichtelijk, veilig en performant te hosten. Met een goede mappenstructuur, aparte configuratiebestanden, duidelijke redirects, HTTPS, logscheiding en regelmatige tests hou je het beheer beheersbaar. Of je nu één portfolio site of tientallen klantprojecten draait, dezelfde principes gelden.

Start je een nieuw project? Bepaal eerst domein, server resources en SSL-behoefte. Volg daarna de bovenstaande checklist om je Nginx configuratie stap voor stap goed aan te leggen. Voor een makkelijker beheer kun je ook kijken naar onze Hostingpakketten, VPS server en SSL certificaten oplossingen die een solide basis bieden.

Veelgestelde vragen

Hoeveel sites kan ik hosten met Nginx server blocks?

Technisch kun je met Nginx veel sites op één server draaien; de limiet hangt vooral af van CPU, RAM, schijfruimte, verkeer, databasebelasting en PHP-FPM capaciteit. Op een low-traffic statische server kunnen tientallen sites, terwijl bij drukke WordPress of e-commerce projecten minder sites per server aan te raden zijn.

Heeft elke site een apart SSL-certificaat nodig?

Ja, elk domein of subdomein dat via HTTPS bereikbaar moet zijn, moet in het certificaat opgenomen zijn. Je kunt individuele certificaten gebruiken, of SAN- of wildcard certificaten. Belangrijk is dat in de Nginx 443 server block het juiste certificaat aan het juiste domein gekoppeld is.

Kan ik subdomeinen met Nginx server blocks hosten?

Ja, je kunt voor subdomeinen zoals blog.site.nl of panel.site.nl aparte server_name regels maken en die naar verschillende root mappen of backend applicaties laten wijzen. Zorg dat je in DNS een A- of CNAME-record voor het subdomein aanmaakt.

Wat is het verschil tussen sites-available en sites-enabled?

sites-available bevat alle beschikbare configuratiebestanden, terwijl sites-enabled alleen de actieve configuraties bevat. Meestal maak je in sites-enabled een symlink naar een bestand in sites-available. Dit maakt het makkelijk om sites te activeren en deactiveren zonder bestanden te verwijderen.

Waarom wordt soms de verkeerde site geladen?

De meest voorkomende oorzaken zijn: DNS wijst naar het verkeerde IP, server_name in de configuratie is niet correct, het default Nginx server block pakt het verzoek op, of een foutieve SSL server block draait op poort 443. Controleer eerst DNS, daarna de output van nginx -t, actieve symlinks in sites-enabled en de access_log bestanden.