Nginx Bedienerblokke: Hoe om Verskeie Webwerwe op ’n VPS te Host in Afrikaans

Nginx bedienerblokke is ’n virtuele hosting-stelsel waarmee jy verskeie domeine of webwerwe op ’n enkele Nginx-installasie kan bedryf, elk met hul eie konfigurasies. Byvoorbeeld, op ’n enkele VPS kan jy example.com, blog.example.com en tweede-webwerf.com elk hul eie wortelgidse, loglêers, SSL-sertifikate en PHP-instellings hê. Die basiese proses behels om ’n aparte gids vir elke webwerf te skep, die DNS-rekords van die domein na jou bediener-IP te wys, ’n bedienerblok vir elke webwerf onder /etc/nginx/sites-available te skryf, dit te aktiveer deur ’n simboliese skakel in sites-enabled te maak, die konfigurasie te toets en Nginx te herlaai.

In hierdie gids bespreek ons stap-vir-stap hoe om verskeie webwerwe op ’n Nginx-bediener te host, geskik vir produksieomgewings. Die doel is nie net om ’n werkende stelsel te bou nie, maar om ’n bestuurbare, veilige, vinnige, rugsteunbare en skaalbare infrastruktuur te vestig. Dit is veral handig vir agentskappe, ontwikkelaars, e-handelsondernemings, besighede met verskeie handelsmerke en stelseladministrateurs wat verskeie projekte op een bediener bestuur. As jy nog nie ’n bediener het nie, kan jy meer leer oor VPS Bediener en domeinregistrasie op Domein Registrasie.

Wat is Nginx Bedienerblokke?

Nginx bedienerblokke is konfigurasie-eenhede (server blocks) binne Nginx wat bepaal watter webwerf ’n HTTP of HTTPS versoek moet hanteer. Dit is soortgelyk aan die VirtualHost konsep in Apache. Wanneer ’n besoeker ’n domeinnaam in hul blaaier intik, los DNS dit op na die bediener se IP-adres op. Nginx kyk dan na die Host-kop van die versoek en aktiveer die bedienerblok met die ooreenstemmende server_name waarde.

Hierdie metode stel jou in staat om verskeie webwerwe op dieselfde IP-adres en fisiese of virtuele bediener te bedryf. Jy kan vir elke webwerf ’n eie wortelgidse, toegang- en foutlogboek, herlei-reëls, SSL-sertifikate, kasbeleid en sekuriteitsreëls opstel. Byvoorbeeld, jou korporatiewe webwerf kan in /var/www/korporatief/public wees, jou blog in /var/www/blog/public, en ’n toetsomgewing in /var/www/staging/public.

Nginx is baie doeltreffend in hierdie opstelling, omdat sy gebeurtenisgebaseerde argitektuur hoë gelyktydige verbindings met lae hulpbronverbruik kan hanteer. Daarom word dit dikwels gebruik vir gedeelde hosting, VPS, wolkbedieners en hoogs besoekte toepassings. Vir ’n gesonde multi-webwerf hosting moet elke detail van lêertoestemmings tot DNS-wysigings, SSL-opstelling en logboekonderskeiding deeglik beplan word.

Wanneer Gebruik Jy Nginx Bedienerblokke?

Nginx bedienerblokke is veral nuttig wanneer jy verskeie webwerwe op ’n enkele bediener wil bestuur. Dit kan twee klein korporatiewe webwerwe wees, of ’n paar dosyne kliëntprojekte, subdomeine of mikrodienste. Die belangrikste is om elke projek logies van mekaar te skei.

• As jy verskeie domeine op dieselfde VPS wil aanbied.
• As jy www en nie-www domeine na ’n enkele kanonieke adres wil herlei.
• As jy subdomeine na verskillende gidse of toepassings wil verwys.
• As jy vir elke webwerf ’n aparte SSL-sertifikaat en sekuriteitsbeleid wil hê.
• As jy kliëntprojekte met afsonderlike loglêers wil monitor.
• As jy verskillende toepassings soos Laravel, WordPress, statiese HTML en Node.js op een bediener wil laat loop.

Byvoorbeeld, ’n digitale agentskap kan ’n enkele 4 GB RAM VPS gebruik om 8 lae-trafiekorporatiewe webwerwe te host. Maar vir elke webwerf moet jy verkeer, skyfgebruik, PHP-prosesse, databasislading en rugsteunfrekwensie bereken. Indien die projek hoë verkeersvlakke het of hulpbronisolasie belangrik is, moet jy oorweeg om ’n kragtiger VPS, wolkbediener of bestuurde hosting te gebruik. Jy kan ook Web Hosting en Korporatiewe Hosting vergelyk vir geskikte opsies.

Vereistes voor Begin

Hierdie gids fokus op ’n Ubuntu- of Debian-gebaseerde Linux-bediener. Sommige opdragte kan effens verskil vir ander distribusies, maar die konsep bly dieselfde. Maak altyd ’n rugsteun voordat jy in ’n produksie-omgewing veranderings aanbring, want ’n foutiewe Nginx-konfigurasie kan al jou webwerwe tydelik ontoeganklik maak.

Benodigde tegniese voorbereidings

• Linux-gebruikersrekening met root- of sudo-regte.
• Nginx diens geïnstalleer en aan die gang.
• Ten minste een domein wat na die bediener se IP verwys.
• Poorte 80 en 443 moet in jou firewall oop wees.
• ’n Netjiese gidsstruktuur vir jou webwerf-lêers.
• ’n Geldige SSL-sertifikaat of gratis Let’s Encrypt sertifikaat.
• PHP-FPM geïnstalleer vir PHP-gebaseerde toepassings.

Op DNS-vlak wys ’n A-rekord die hoofdomein na die IPv4-adres, en ’n AAAA-rekord na IPv6 indien beskikbaar. Subdomeine soos www gebruik CNAME of A-rekords. DNS-propagasie kan tussen ’n paar minute tot 24 uur neem. Dit help om eers DNS-rekords reg te stel voordat jy met Nginx bedienerblokke begin.

Voorgestelde Gidsstruktuur

’n Algemene fout met multi-webwerf hosting is om alles deurmekaar in een gids te bêre. Dit lyk dalk eenvoudig, maar maak instandhouding, rugsteun en foutopsporing baie moeiliker. Dit is beter om vir elke domein ’n eie hoofgids te hê met subgidse soos public, logs en backups.

’n Voorbeeldstruktuur kan wees: /var/www/webwerf1.com/public, /var/www/webwerf1.com/logs, /var/www/webwerf2.com/public en /var/www/webwerf2.com/logs. Die Nginx root moet direk na die public-gids wys. Dit verseker dat jou toepassingslêers, sensitiewe konfigurasielêers (.env, ens.) en rugsteunlêers nie direk via die web toeganklik is nie.

Jy kan ’n eenvoudige index.html-lêer in elke public-gids plaas om vinnig te bevestig watter bedienerblok werk. In produksie word hierdie gidse gewoonlik besit deur die www-data gebruiker of ’n spesifieke deploy-gebruiker. Lêertoestemmings van 755 vir gidse en 644 vir lêers is meestal voldoende. Vir WordPress of ander toepassings wat skryf, moet jy sekere gidse soos uploads spesiaal hanteer.

Stapsgewyse Nginx Bedienerblok Skep

Die volgende voorbeeld gebruik site1.com. Jy kan dieselfde proses herhaal vir tweede, derde en verdere webwerwe. Maak seker dat elke webwerf ’n unieke server_name, root en loglêers het.

1. Skep die webwerf-gids

Begin met om die gids vir jou webwerf-lêers te skep, bv. sudo mkdir -p /var/www/site1.com/public. Skep ’n basiese toetslêer by /var/www/site1.com/public/index.html met ’n duidelike teks soos “Hierdie is die site1.com toetsblad.”

Stel die lêereienaarskap korrek met sudo chown -R www-data:www-data /var/www/site1.com. As jy met ’n ander gebruiker ontplooi, pas die groepstoestemmings aan. Vermy die gebruik van 777 toestemmings in produksie, aangesien dit ’n veiligheidsrisiko inhou.

2. Skryf die bedienerblok-lêer

Die beste praktyk is om jou konfigurasies onder /etc/nginx/sites-available te hou en ’n simboliese skakel na /etc/nginx/sites-enabled te maak. Byvoorbeeld: /etc/nginx/sites-available/site1.com.

’n Basiese HTTP bedienerblok lyk so:
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;
  }
}

Hier luister listen 80 na HTTP-verkeer, server_name definieer die domeine vir hierdie blok, root wys waar die webwerf-lêers is, index stel die standaard lêers, en try_files sorg dat ’n 404 teruggestuur word as die versoekte lêer nie bestaan nie. Dit is voldoende vir statiese webwerwe.

3. Aktiveer die webwerf

Skep ’n simboliese skakel om die konfigurasie te aktiveer: sudo ln -s /etc/nginx/sites-available/site1.com /etc/nginx/sites-enabled/site1.com. Dit maak bestuur makliker aangesien jy net een hooflêer hoef te wysig en dit outomaties aktief is.

As die standaard Nginx bladsy jou webwerf oorheers, kan jy die standaard konfigurasie deaktiveer deur die simboliese skakel /etc/nginx/sites-enabled/default te verwyder. Maak seker jou webwerf werk korrek voordat jy dit doen.

4. Toets die konfigurasie en herlaai Nginx

Gebruik sudo nginx -t om jou sintaksis te toets. As dit suksesvol is, herlaai Nginx sonder onderbreking met sudo systemctl reload nginx. Die reload-opdrag is veiliger as restart, aangesien dit lopende verbindings sagkens hanteer.

As die toets misluk, gee Nginx gewoonlik ’n foutboodskap met lêernaam en lynnommer. Algemene probleme sluit in ontbrekende semikolon, verkeerde hakies, foutiewe pad na gidse of botsende server_name waardes. Los al hierdie foute op voor jy Nginx herlaai.

Voeg ’n Tweede en Derde Webwerf by

Die voordeel van verskeie webwerwe is dat jy die proses kan herhaal. Skep byvoorbeeld ’n gids vir site2.com by /var/www/site2.com/public, skryf ’n bedienerblok by /etc/nginx/sites-available/site2.com, pas root en log-lêers aan, maak ’n simboliese skakel, en toets Nginx weer.

’n Basiese bedienerblok vir die tweede webwerf:
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;
  }
}

Om afsonderlike loglêers te hê is baie waardevol. ’n Toename in 404-foute op een webwerf kan aandui ’n probleem, terwyl ander webwerwe normaal werk. Dit vergemaklik ook verkeer-analise, bot aanvalle, gebreekte skakels en prestasie-monitering.

SSL en HTTPS Konfigurasie

Vanaf 2026 is HTTPS nie net ’n veiligheidsmaatreël nie, maar ’n teken van gebruikersvertroue en tegniese kwaliteit. Blaaiers merk HTTP-webwerwe as onveilig aan; SSL is verpligtend vir betalings, aanmeldings, vorms en bestuurskoppelvlakke. Vir verskeie domeine moet jy vir elkeen die regte sertifikaat hê. Kyk by Hostragons na jou SSL-behoeftes op SSL sertifikate.

Met Let’s Encrypt kan jy met Certbot vir elke domein gratis sertifikate kry. Die opdrag certbot --nginx -d site1.com -d www.site1.com kan Nginx konfigurasie herken en ’n HTTPS blok outomaties byvoeg. Maak seker jy kontroleer die lêer na die outomatiese opdatering vir moontlike foute soos verkeerde herleidings of dubbele bedienerblokke.

Gewoonlik word HTTP-verkeer op poort 80 permanent (301) na HTTPS-poort 443 herlei. ’n 301 herleiding is SEO-vriendelik omdat dit duidelik maak dat die nuwe adres permanent is. Besluit of jy www wil gebruik en rig al die variasies na een kanonieke adres. Byvoorbeeld, as jy https://site1.com bo https://www.site1.com verkies, herlei albei HTTP en HTTPS www-verkeer na die nie-www weergawe, om duplikaatinhoud te voorkom.

Nginx Bedienerblokke vir PHP en WordPress Webwerwe

Statiese HTML webwerwe is maklik om op te stel, maar WordPress, Laravel en ander PHP-toepassings benodig integrasie met PHP-FPM. Jy sluit index.php in en stuur PHP-verzoeken na die toepaslike socket, bv. /run/php/php8.3-fpm.sock op Ubuntu met PHP 8.3. Die presiese pad kan verskil na gelang van jou PHP-weergawe.

Voorbeeld PHP bedienerblok:
server {
  listen 80;
  server_name wordpress-webwerf.com www.wordpress-webwerf.com;
  root /var/www/wordpress-webwerf.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;
  }
}

Die try_files-lyn verseker permanente skakels werk korrek in WordPress. Sekuriteitsmaatreëls soos beperking op xmlrpc.php, wp-login.php, en voorkoming van PHP-uitvoering in uploads-gidse moet oorweeg word. As jy baie WordPress-webwerwe op ’n enkele VPS host, gebruik aparte databasisse, gebruikers en ’n gestruktureerde opdateringsbeleid. Vir ’n bestuurde opsie, kyk na WordPress hosting.

Vergelyking tussen Nginx Bedienerblokke en Apache VirtualHosts

Nginx en Apache bereik soortgelyke doelwitte met verskillende argitekture. Albei kan verskeie webwerwe op een bediener hanteer. Jou keuse hang af van jou toepassing se behoeftes, bestuurstyl en prestasievereistes.

As jou toepassing intensief op .htaccess staatmaak, is Apache makliker. Vir hoë verkeer, reverse proxy, kas en moderne verspreiding is Nginx dikwels die beter keuse. Dit is ook moontlik om Nginx as reverse proxy en Apache as backend te kombineer.

Beste Sekuriteitspraktyke

Multi-webwerf hosting op een bediener bespaar kostes, maar verhoog sekuriteitsrisiko’s. Isolasie en minimale regte moet toegepas word om te voorkom dat ’n kwesbaarheid ’n ander webwerf beïnvloed.

• Skep aparte databasis en databasisgebruikers vir elke webwerf.
• Beperk die webwortel tot slegs die public-gids.
• Bêre rugsteun, .env, .git, konfigurasie- en SQL-lêers buite die webtoegang.
• Verander SSL-sertifikate gereeld en maak HTTPS verpligtend.
• Gebruik ’n firewall soos UFW en maak slegs die nodige poorte oop.
• Hou Nginx en jou bedryfstelsel op datum met opdaterings.
• Gebruik afsonderlike toegang- en foutlogboeke per webwerf.
• Beperk toegang tot bestuurspanele met IP-witlyste of ekstra verifikasie.
• Vermy suiwer 777-lêertoestemmings.

Dit is ook nuttig om sekuriteitskoppe soos X-Frame-Options, X-Content-Type-Options, Referrer-Policy en Content-Security-Policy te implementeer, alhoewel laasgenoemde deeglik getoets moet word om te verhoed dat styl- en skriplêers geblokkeer word. Vir meer inligting oor websekuriteit, sien webwerf veiligheid.

Prestasie en SEO Wenke

Nginx bedienerblokke beïnvloed nie net hosting nie, maar ook jou webwerf se spoed en SEO. Verkeerde herleidings, swak canonical tags, ontbrekende gzip of brotli kompressie, groot loglêers en swak kasinstellings kan jou webwerf vertraag. Google se bladsy-ervaring fokus op vinnige, veilige en betroubare webwerwe.

Maak seker jy kies ’n enkele kanonieke weergawe vir elke domein. Maak een stap herleidings van HTTP na HTTPS en van www na nie-www (of andersom) sonder kettings. Vermy byvoorbeeld http://site.com na http://www.site.com na https://www.site.com na https://site.com. ’n Enkele 301 herleiding is SEO-vriendeliker.

Gebruik cache-control koppe vir statiese lêers soos beelde, CSS en JavaScript. Vir gereelde veranderende lêers kan jy naam-weergawe of query string strategieë toepas. Gzip kompressie verminder bandwydte vir teksgebaseerde lêers. Vir hoë verkeer kan Nginx microcache, FastCGI cache of ’n CDN oorweeg word. Vir CDN en wêreldwye toegang lees meer by Wat is CDN.

Logbestuur en Monitering

Logboeke is die sleutel tot probleemoplossing in multi-webwerf hosting. Afsonderlike loglêers wys presies waar foutmeldings voorkom. access_log hou besoekersversoeke by, error_log registreer konfigurasie-, toestemmings- en bedienerfoute. ’n 502 Bad Gateway dui dikwels op PHP-FPM of backend-verbindinge, 403 Forbidden dui op toestemmingsprobleme, en 404 Not Found kan dui op verkeerde root of rewrite reëls.

Voorkom dat loglêers te groot word deur logrotate te konfigureer. Vir klein projekte is daaglikse of weeklikse rotasie genoeg. Vir groot webwerwe is ’n sentrale logversameling en monitering met waarskuwings beter. ’n Volle skyf kan veroorsaak dat Nginx nie logboeke kan skryf nie, databasis stop, en webwerwe ontoeganklik raak. Stel waarskuwings in vir skyfgebruik.

Algemene Probleme en Vinnige Oplossings

Hier is ’n lys van algemene probleme met Nginx bedienerblokke en hoe om dit vinnig reg te stel:

• Domein open die verkeerde webwerf: Kontroleer server_name botsings en die standaard bedienerblok.
• 403 Forbidden: Kyk na root gids, lêertoestemmings en of index-lêers bestaan.
• 404 Not Found: Kontroleer root pad en try_files reëls.
• 502 Bad Gateway: Maak seker PHP-FPM diens loop en die socket pad is korrek.
• SSL sertifikaat is verkeerd: Kyk na die server_name en sertifikaatlêers in die 443 bedienerblok.
• Herleidingslus: Vereenvoudig jou HTTP-HTTPS en www herleidingsreëls.
• Nginx kan nie herlaai nie: Gebruik sudo nginx -t om sintaksisfoute te vind en reg te stel.

’n Praktiese kontrolelys wat ervare bestuurders gebruik, is om te kyk of DNS korrek is, Nginx konfigurasie aktief is, root gids bestaan, toestemmings reg is, die diens slaag die toets, en wat die logboeke sê. Hierdie proses help om vinnig en sonder paniek oplossings te vind.

Praktiese Kontrolelys vir Produksie

Voordat jy jou webwerf lewendig maak, gebruik hierdie kontrolelys om seker te maak alles is reg. Dit is belangrik om hierdie stappe te dokumenteer, veral vir kliëntprojekte:

• Domein se A of AAAA rekord wys na die korrekte IP-adres.
• Een van www of nie-www is gekies as kanonieke URL.
• HTTP-verkeer word met ’n 301 herleiding na HTTPS gestuur.
• SSL sertifikaat is geldig en outomaties hernu.
• Elke webwerf het sy eie root en loglêers.
• Nginx konfigurasie is suksesvol getoets met sudo nginx -t.
• Rugsteunplan is in plek en hersteltoets is gedoen.
• Lêertoestemmings volg die minimum regte beginsel.
• Firewall maak net die nodige poorte oop.
• Foutlogboeke is ten minste 15 minute na live gaan nagegaan.

Al lyk hierdie lys eenvoudig, dit verminder aansienlik die risiko van onderbrekings of probleme. Spesifiek SSL-hernuwing, DNS kontrole en logmonitering vang dikwels ongemerkte probleme vroeg op.

Gevolgtrekking

Nginx bedienerblokke is ’n betroubare en doeltreffende manier om verskeie webwerwe op een bediener te bestuur. Met ’n goeie gidsstruktuur, afsonderlike konfigurasielêers, duidelike herleidings, HTTPS-implementering, aparte loglêers en gereelde toetse word multi-site bestuur makliker en veiliger. Of dit nou ’n klein portefeuljewebwerf is of ’n versameling kliëntprojekte, dieselfde beginsels geld.

As jy ’n nuwe projek wil bestuur, bepaal eers jou domeinnaam, bedienerhulpbronne en SSL-behoeftes. Volg dan die kontrolelys en stel jou Nginx-konfigurasie stap vir stap op. As jy ’n meer bestuurde omgewing verlang, kyk na Hostragons se Hosting pakkette, VPS Bediener en SSL sertifikate om die beste beginpunt vir jou projek te vind.

Gereelde Vrae

Hoeveel webwerwe kan ek met Nginx bedienerblokke host?

Teknies kan jy baie webwerwe op ’n enkele Nginx-bediener hê. Die limiet hang af van jou CPU, RAM, skyf, verkeer, databasislading en PHP-FPM kapasiteit. Vir lae-trafiek statiese webwerwe kan dit dosyne wees, maar vir hoë-trafiek WordPress- of e-handelswebwerwe is ’n laer aantal gesonder.

Is ’n aparte SSL-sertifikaat nodig vir elke webwerf?

Ja, elke domein of subdomein wat HTTPS gebruik, moet in ’n sertifikaat ingesluit wees. Jy kan individuele sertifikate gebruik, of SAN- en wildcard-sertifikate wat verskeie domeine dek. Die belangrikste is om die regte sertifikaat in jou Nginx 443 bedienerblok te koppel.

Kan ek subdomeine met Nginx bedienerblokke host?

Ja, jy kan subdomeine soos blog.site.com of paneel.site.com met ’n aparte server_name definieer en na ’n ander wortelgidse of backend-app verwys. Maak seker jy stel ’n A- of CNAME-rekord vir die subdomein in jou DNS op.

Wat is die verskil tussen sites-available en sites-enabled?

sites-available is die plek waar al jou konfigurasielêers gehou word, maar hulle is nie noodwendig aktief nie. sites-enabled bevat simboliese skakels na die aktiewe konfigurasielêers in sites-available. Hierdie stelsel maak dit maklik om webwerwe te aktiveer en deaktiveer sonder om lêers te kopieer.

Hoekom laai die verkeerde webwerf wanneer ek my domein besoek?

Algemene oorsake sluit in dat die DNS na die verkeerde IP wys, ’n foutiewe server_name waarde, die standaard Nginx blok wat versoeke vang, of ’n verkeerde SSL-blok op poort 443. Kontroleer eers jou DNS, voer sudo nginx -t uit, kyk na aktiewe simboliese skakels in sites-enabled, en ondersoek die relevant access_log lêers.