Nginx serverblokke: Sådan hoster du flere websites på én server

Nginx serverblokke (virtual hosts) er en effektiv måde at administrere flere domæner eller websites på én Nginx-installation, hver med deres egne konfigurationer. For eksempel kan du på samme VPS have både example.com, blog.example.com og anden-site.dk med separate root-mapper, logfiler, SSL-certifikater og PHP-indstillinger. Kort sagt: Opret en mappe for hvert site, peg domænets DNS-records til din server-IP, skriv en serverblok under /etc/nginx/sites-available, link til sites-enabled, test konfigurationen og genindlæs Nginx.

Denne guide gennemgår hosting af flere websites med Nginx serverblokke i et produktionsmiljø – ikke bare for at få det til at fungere, men for at skabe en løsning der er nem at administrere, sikker, hurtig, backup-venlig og skalérbar. Vi deler konkrete tips for webbureauer, udviklere, e-handelsejere, virksomheder med flere brands og sysadmins med flere projekter på samme server. Hvis du ikke har en server endnu, kan du læse om valg af ressourcer på VPS server, og om domænehåndtering på Domænetilsyn.

Hvad er Nginx serverblokke?

En Nginx serverblok er en server-sektion i konfigurationen, der bestemmer, hvilket website en indkommende HTTP- eller HTTPS-request skal vises på. Det svarer til Apache’s VirtualHost-koncept. Når en besøgende indtaster et domæne i browseren, opløser DNS domænet til serverens IP, og Nginx vælger serverblokken, hvor server_name matcher Host-headeren.

Dermed kan du hoste dusinvis af websites på samme IP og hardware (eller VPS). Hvert site kan få sin egen root-mappe, adgangslog, fejllog, redirect-regler, SSL-certifikat, cache-policy og sikkerhedsregler. Eksempel: Virksomhedssiden ligger i /var/www/virksomhed/public, bloggen i /var/www/blog/public, og testmiljøet i /var/www/staging/public.

Nginx er særdeles effektiv i denne struktur, fordi dens event-baserede arkitektur håndterer mange samtidige forbindelser med minimalt ressourceforbrug. Derfor bruges den ofte til VPS, cloud-servere og hosting med høj trafik. For at mulitsite-hosting fungerer, skal detaljer som filrettigheder, DNS-routing, SSL-installation og log-adskillelse planlægges korrekt.

Hvornår skal du bruge Nginx serverblokke?

Nginx serverblokke bruges, når du vil styre flere webmiljøer på én server – det kan være to små virksomheds-sites eller mange kundeprojekter, subdomæner eller microservices. Det afgørende er, at hvert projekt logisk adskilles fra de andre.

• Hvis du vil hoste flere domæner på samme VPS.
• Hvis du ønsker at omdirigere www og non-www til ét kanonisk domæne.
• Hvis du vil matche subdomæner til forskellige mapper eller applikationer.
• Hvis du vil have separate SSL-certifikater og sikkerhedspolitikker for hvert site.
• Hvis du vil analysere logfiler pr. kundeprojekt.
• Hvis du vil køre både Laravel, WordPress, statisk HTML og Node.js på én server.

Eksempel: Et digitalt bureau kan teknisk set hoste 8 lavtrafik-sites på én VPS med 4 GB RAM. Men trafik, diskforbrug, PHP-processer, databasebelastning og backup-frekvens skal beregnes for hvert site. Hvis projekterne har meget trafik eller kræver isolation, bør du overveje en stærkere VPS, cloud-server eller managed hosting. Sammenlign alternativerne på Webhosting og Virksomheds Hosting.

Krav før du starter

Guiden tager udgangspunkt i en Ubuntu- eller Debian-baseret Linux-server. Kommandoerne kan variere, men principperne er ens. Tag altid backup før du ændrer konfigurationer – én fejl kan gøre alle dine sites utilgængelige.

Tekniske forberedelser

• En Linux-bruger med root- eller sudo-adgang.
• Installeret og kørende Nginx-service.
• Mindst ét domæne peget til serverens IP-adresse.
• Port 80 og 443 åbne i firewall.
• En organiseret mappestruktur til sitefiler.
• Et gyldigt SSL-certifikat eller gratis Let’s Encrypt.
• PHP-FPM installeret for PHP-baserede sites.

På DNS-siden peger A-record til IPv4-adressen, og AAAA-record til IPv6 hvis relevant. Subdomæner som www kan bruge CNAME eller A-record. DNS-propagation tager normalt et par minutter til 24 timer. Opret DNS-records først, så går opsætningen af Nginx serverblokke hurtigere.

Anbefalet mappestruktur

En af de største fejl ved multisite-hosting er at blande alle filer i én mappe. Det virker nemt i starten, men komplicerer vedligehold, backup og fejlretning. Bedre er at have en hovedmappe for hvert domæne, og undermapper som public, logs og backups.

Eksempel: /var/www/site1.dk/public, /var/www/site1.dk/logs, /var/www/site2.dk/public osv. Nginx’s root-værdi skal pege direkte til public-mappen. Så undgår du, at applikationsfiler, .env eller backups kan tilgås direkte via web.

Du kan lægge en simpel index.html i hver site-mappe for at teste, hvilken serverblok der aktiveres. I produktion bør mappens ejerskab typisk være www-data eller en dedikeret deploy-bruger. Rettigheder: Mapper 755, filer 644 passer til de fleste statiske scenarier. For WordPress og lignende skal upload-mapper vurderes særskilt.

Trin-for-trin: Opret en Nginx serverblok

Eksemplerne bruger site1.dk. Gentag processen for flere sites – det vigtige er unik server_name, root og logfil pr. site.

1. Opret site-mappen

Start med at oprette mappen til webfilerne: sudo mkdir -p /var/www/site1.dk/public. Lav en testfil /var/www/site1.dk/public/index.html med teksten “Dette er en testside for site1.dk”.

Angiv korrekt ejer: sudo chown -R www-data:www-data /var/www/site1.dk. Hvis du deployer med en anden bruger, justér gruppe-rettigheder. Undgå 777-rettigheder, de gør upload-mapper sårbare for hackere.

2. Opret serverblok-konfigurationsfilen

Best practice: Opbevar inaktive konfigurationer under /etc/nginx/sites-available og aktivér dem med et symbolsk link til sites-enabled. Eksempel: /etc/nginx/sites-available/site1.dk.

En simpel HTTP-serverblok kunne være:

server {
    listen 80;
    server_name site1.dk www.site1.dk;
    root /var/www/site1.dk/public;
    index index.html index.htm;
    access_log /var/log/nginx/site1.dk.access.log;
    error_log /var/log/nginx/site1.dk.error.log;
    location / {
        try_files $uri $uri/ =404;
    }
}

listen 80 lytter på HTTP, server_name definerer domæner, root peger til webfiler, index angiver standardfil. try_files sender 404, hvis fil/mapper ikke findes. Dette er nok til statiske sites.

3. Aktivér sitet

Brug et symbolsk link: sudo ln -s /etc/nginx/sites-available/site1.dk /etc/nginx/sites-enabled/site1.dk. Det er mere robust end at kopiere filer – ændringer slår igennem begge steder.

Hvis du ikke ønsker, at Nginx’s default-site vises, kan du fjerne /etc/nginx/sites-enabled/default. Gør dette først, når din egen serverblok virker.

4. Test konfigurationen og genindlæs Nginx

Efter hver ændring: sudo nginx -t for syntaks-test. Hvis ok, genindlæs med sudo systemctl reload nginx – det er mere sikkert end restart, da aktive forbindelser håndteres blødere.

Ved fejl viser Nginx typisk filnavn og linje. De mest almindelige problemer er manglende semikolon, forkert bracering, ugyldig mappe eller overlappende server_name. Ret fejlen før du genstarter Nginx.

Tilføjelse af site nummer to og tre

Det smarte ved multisite-hosting er, at processen er ens for hvert site. Opret /var/www/site2.dk/public, skriv /etc/nginx/sites-available/site2.dk, skift root og lognavne, lav symlink og test.

Eksempel-konfiguration for site2.dk:

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

Separate logfiler er guld værd – hvis én site får mange 404-fejl, kan du hurtigt identificere problemet. Det samme gælder trafikmåling, bot-angreb, døde links og performance.

SSL og HTTPS konfiguration

HTTPS er nu et must for SEO, brugertillid og teknisk kvalitet. Browsere mærker HTTP-sites som usikre – SSL er obligatorisk for alt med betaling, login, formularer eller admin-paneler. Hvert domæne skal have sit eget certifikat. Se SSL certifikater for SSL-løsninger.

Med Let’s Encrypt og Certbot kan du nemt få certifikater: certbot --nginx -d site1.dk -d www.site1.dk – Certbot detekterer Nginx og tilføjer HTTPS-blokken. Tjek dog konfigurationen bagefter, især for redirect- eller dublet-serverblokke.

Typisk redirectes al trafik på port 80 til port 443 med en permanent 301-redirect. Vælg om du vil bruge www eller ej, og saml alle variationer til én kanonisk version. Vil du have https://site1.dk som hovedadresse, skal både HTTP og HTTPS www-requests omdirigeres til non-www. Det minimerer duplicate content-risiko.

Nginx serverblokke for PHP og WordPress

For statiske HTML-sites er konfigurationen enkel; for WordPress, Laravel eller custom PHP kræves PHP-FPM integration. Her defineres index.php, og PHP-requests sendes til den rette socket, fx /run/php/php8.3-fpm.sock på Ubuntu. Versionen afhænger af installationen.

Eksempel for et WordPress-site:

server {
    listen 80;
    server_name wp-site.dk www.wp-site.dk;
    root /var/www/wp-site.dk/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;
    }
}

try_files $uri $uri/ /index.php?$args er vigtigt for WordPress permalinks. Overvej yderligere sikkerhed: Begræns xmlrpc.php-adgang, rate-limit wp-login.php, undgå PHP i uploads-mappen. Brug separat database, bruger og update-strategi for hvert site. Vil du have nemmere WordPress-hosting, så kig på WordPress hosting.

Sammenligning: Nginx serverblokke vs. Apache VirtualHost

Både Nginx og Apache kan hoste flere sites på én server, men tilgangen og performance er forskellig. Valget afhænger af dine behov, vaner og krav til hastighed.

Bruger du mange .htaccess-regler, kan Apache være nemmere. Men til høj trafik, reverse proxy, caching og moderne deployment er Nginx ofte bedst. Nogle løsninger kombinerer Nginx som reverse proxy og Apache som backend.

Bedste praksis for sikkerhed

Hosting af flere sites på én server er omkostningseffektivt, men kræver ekstra fokus på sikkerhed. Isolering og mindst mulige privilegier er nøgleord.

• Opret separat database og databasebruger for hvert site.
• Begræns web root til public-mappen.
• Hold backup, .env, .git, config og SQL-filer uden for web-adgang.
• Forny SSL-certifikater regelmæssigt, håndhæv HTTPS.
• Brug UFW eller lignende firewall – kun åbne nødvendige porte.
• Opdater Nginx og OS regelmæssigt.
• Log adskilt for hvert site: access_log og error_log.
• Begræns adgang til admin-paneler med IP-whitelists eller ekstra login.
• Undgå 777-rettigheder – brug mindst mulige privilegier.

Tilføj gerne sikkerheds-headere som X-Frame-Options, X-Content-Type-Options, Referrer-Policy og Content-Security-Policy – test dog først, især Content-Security-Policy, da den kan blokere scripts/styles. Læs mere om sikkerhed på websted sikkerhed.

Tips til performance og SEO

Nginx serverblokke påvirker ikke kun hosting, men også performance og SEO. Forkerte redirects, dårlig canonical-struktur, manglende gzip/brotli-komprimering, store logfiler og mangelfuld caching kan gøre sitet langsomt. Google’s page experience signaler belønner hurtige, sikre og stabile sites.

Vælg én kanonisk version pr. domæne. Redirect fra HTTP til HTTPS og fra www til non-www (eller omvendt) med én 301. Undgå redirect-chains som http://site.dk → http://www.site.dk → https://www.site.dk → https://site.dk, brug én redirect til målet.

Cache-control headers kan sættes for statiske filer som billeder, CSS og JS. Versionér filnavne eller brug query strings for hurtigt skiftende filer. Gzip-komprimering sparer båndbredde på HTML, CSS, JS og JSON. For sites med meget trafik kan du overveje microcache, FastCGI cache eller CDN. Læs mere på Hvad er CDN.

Log management og overvågning

Adskilte logfiler er nøglen til hurtig fejlretning ved multisite-hosting. access_log viser besøgsdata, error_log registrerer konfigurations-, rettigheds- og filfejl. 502 Bad Gateway skyldes typisk PHP-FPM eller backend-service, 403 Forbidden skyldes ofte rettigheder eller manglende index-fil, 404 Not Found skyldes forkert root, rewrite eller DNS.

Brug logrotate for at undgå uendeligt voksende logfiler – daglig eller ugentlig rotation er nok for mindre sites. For store sites bør du bruge central logindsamling og alerts. Fyldt disk forhindrer Nginx i at skrive log, kan stoppe databasen og gøre sites utilgængelige – sæt derfor threshold for diskbrug.

Typiske fejl og hurtige løsninger

Følgende fejl er almindelige ved Nginx serverblokke – kendskab sparer tid:

• Domæne viser det forkerte site: Tjek server_name-konflikter og default-serverblokken.
• 403 Forbidden: Tjek root-mappe, filrettigheder og om index-fil eksisterer.
• 404 Not Found: Tjek root-path og try_files-regler.
• 502 Bad Gateway: Tjek om PHP-FPM kører og socket-path er korrekt.
• Forkert SSL-certifikat på site: Tjek server_name og certifikatfil i port 443-blokken.
• Redirect-loop: Simplificer HTTP-HTTPS og www-redirects.
• Nginx reload fejler: Løs syntax-fejl baseret på sudo nginx -t-output.

Erfarne admins følger en tjekliste: Er DNS korrekt? Er Nginx-konfigurationen aktiv? Findes root-mappen? Rettigheder ok? Bestod syntax-test? Hvad siger loggen? Sådan løser du problemer hurtigt og roligt.

Praktisk tjekliste til produktion

Før go-live, gennemgå hvert site med denne tjekliste. Dokumentér gerne punkterne før levering til kunder – det er professionelt.

• Domænets A/AAAA-record peger til korrekt IP.
• Én kanonisk version valgt (www eller non-www).
• HTTP redirectes til HTTPS med 301.
• SSL-certifikat gyldigt, auto-renew aktiveret.
• Unik root- og logfil pr. site.
• Konfiguration valideret med sudo nginx -t.
• Backup-plan lagt og restore-testet.
• Filrettigheder følger mindst mulige privilegier.
• Kun nødvendige porte åbne i firewall.
• Fejllogs overvåget mindst 15 minutter efter go-live.

Listen er lille, men reducerer risiko for nedetid markant. Især SSL-fornyelse, DNS og log-overvågning fanger de fleste skjulte fejl tidligt.

Konklusion

Nginx serverblokke er en af de bedste metoder til at hoste flere sites samlet, sikkert og effektivt på én server. Med korrekt mappestruktur, adskilte konfigurationsfiler, klare redirects, HTTPS, adskilte logs og løbende test får du et robust multisite-miljø. Samme principper gælder fra små portefølje-sites til store kundeprojekter.

Skal du lancere et nyt projekt, så afklar domæne, serverressourcer og SSL først, og følg tjeklisten ovenfor trin for trin. Vil du have en mere administrerbar platform, kan du se Hostragons’ Hostingpakker, VPS server og SSL certifikater for relevante startpunkter.

Ofte stillede spørgsmål

Hvor mange sites kan man hoste med Nginx serverblokke?

Du kan teknisk set hoste mange sites på én server; det afhænger af CPU, RAM, disk, trafik, databasebelastning og PHP-FPM-kapacitet. På statiske lavtrafik-sites kan du have mange, mens tunge WordPress- eller e-commerce-sites kræver færre for stabil drift.

Skal hvert site have sit eget SSL-certifikat?

Ja, hvert domæne eller subdomæne der skal køre HTTPS, skal have et certifikat. Du kan bruge individuelle certifikater eller SAN/wildcard, så længe certifikatet matcher domænet i Nginx’s port 443-blok.

Kan man hoste subdomæner med Nginx serverblokke?

Ja. Du kan definere fx blog.site.dk eller admin.site.dk som egne server_name, og pege til separate root-mapper eller backend-apps. DNS skal have korrekt A- eller CNAME-record for hvert subdomæne.

Hvad er forskellen på sites-available og sites-enabled?

sites-available er til rådighed for konfigurationsfiler; sites-enabled indeholder de aktive. Typisk laves et symbolsk link fra sites-enabled til sites-available, så sites nemt aktiveres/deaktiveres.

Hvorfor viser domænet det forkerte site?

Typiske årsager: DNS peger til forkert IP, server_name er forkert, default Nginx-blok fanger request, eller SSL-blokken på port 443 matcher ikke domænet. Tjek DNS, nginx -t-output, aktive symlinks i sites-enabled og access_log for det relevante site.