Värd med Nginx Serverblock: Så här hanterar du flera webbplatser

Nginx serverblock är en virtuell värdstruktur som låter dig publicera flera domäner eller webbplatser med separata konfigurationer i en enda Nginx-installation. Till exempel kan du definiera olika rotkataloger, loggfiler, SSL-certifikat och PHP-inställningar för example.com, blog.example.com och andra-site.com på samma VPS. Sammanfattningsvis innebär lösningen att skapa separata kataloger för varje webbplats, styra domänens DNS-poster till serverns IP-adress, skriva ett separat serverblock under /etc/nginx/sites-available, länka detta till sites-enabled-katalogen, testa konfigurationen och ladda om Nginx-tjänsten.

I denna guide kommer vi att gå igenom processen för att hantera flera webbplatser med Nginx serverblock på ett sätt som är lämpligt för produktionsmiljöer. Målet är inte bara att sätta upp en fungerande struktur, utan att skapa en hanterbar, säker, snabb, backupbar och skalbar konfiguration. Vi kommer att dela praktiska steg, särskilt för byråer, utvecklare, e-handelsägare, företag som hanterar flera varumärken och systemadministratörer som kör flera projekt på en enda server. Om du ännu inte har en server kan du kolla in sidorna för VPS-server och Domänregistrering för resursval.

Vad är Nginx Serverblock?

Nginx serverblock är konfigurationskomponenter inom Nginx som definierar serverblock och bestämmer vilken webbplats som ska dirigeras baserat på inkommande HTTP- eller HTTPS-förfrågningar. Det liknar begreppet VirtualHost i Apache. När en besökare skriver in en domännamn i webbläsaren, översätter DNS detta domännamn till serverns IP-adress. Därefter kollar Nginx på värdet av Host-huvudet i förfrågan och aktiverar det serverblock vars server_name matchar.

Detta gör det möjligt att publicera dussintals olika webbplatser på samma IP-adress och samma fysiska eller virtuella server. För varje webbplats kan du definiera en separat rotkatalog, åtkomstlogg, fel-logg, omdirigeringsregler, SSL-certifikat, cache-policy och säkerhetsregler. Till exempel kan du hålla din företagswebbplats i /var/www/foretag/public, din blogg i /var/www/blog/public och din testmiljö i /var/www/staging/public.

Nginx är mycket effektiv i denna struktur eftersom dess händelsestyrda arkitektur kan hantera hög samtidighet med låg resursförbrukning. Därför är det ofta det föredragna valet för delad hosting, VPS, molnservrar och högtrafikapplikationsinfrastruktur. För att flera webbplatser ska fungera korrekt måste dock alla detaljer, från filrättigheter till DNS-omdirigeringar, SSL-installationer till loggavskiljningar, planeras noggrant.

När används Nginx Serverblock?

Nginx serverblock används särskilt när du behöver hantera flera webbplatser på en enda server. Det kan vara två små företagswebbplatser eller dussintals kundprojekt, subdomäner eller mikrotjänster. Den kritiska punkten här är att logiskt separera varje projekt från varandra.

• Om du vill publicera flera domäner på samma VPS.
• Om du vill omdirigera www och icke-www domäner till en enda kanonisk adress.
• Om du vill koppla subdomäner till olika mappar eller applikationer.
• Om du vill definiera separata SSL-certifikat och säkerhetspolicyer för varje webbplats.
• Om du vill följa kundprojekt med separata loggfiler.
• Om du vill köra olika applikationer som Laravel, WordPress, statisk HTML och Node.js på samma server.

Till exempel är det tekniskt möjligt för en digital byrå att publicera 8 lågt trafikerade företagswebbplatser på en enda 4 GB RAM VPS. Men för varje webbplats måste trafik, diskförbrukning, antal PHP-processer, databasbelastning och frekvensen för backup beräknas. Om projekten får hög trafik eller resursernas isolering är kritisk, bör starkare VPS, molnservrar eller hanterade hostinglösningar övervägas. Vid denna punkt kan Web Hosting och Företags Hosting alternativ jämföras.

Krav innan du börjar

I den här guiden kommer vi att anta att vi använder en Linux-server baserad på Ubuntu eller Debian. Kommandon kan variera något beroende på distribution, men logiken är densamma. Se alltid till att ta backup innan du gör ändringar i produktionsmiljöer. En felaktig Nginx-konfiguration kan göra alla webbplatser tillfälligt otillgängliga.

Tekniska förberedelser

• En Linux-användarkonto med root eller sudo-behörighet.
• En installerad och fungerande Nginx-tjänst.
• Minst en domän som pekar på serverns IP-adress.
• Öppna portar 80 och 443 i brandväggen.
• En organiserad katalogstruktur för webbplatsfiler.
• En giltig certifikat för SSL eller användning av gratis Let’s Encrypt.
• Installation av PHP-FPM för PHP-baserade applikationer.

På DNS-sidan pekar A-posten för huvuddomänen till IPv4-adressen, och AAAA-posten pekar till IPv6-adressen om det finns. CNAME eller A-poster kan användas för subdomäner som www. DNS-spridning tar vanligtvis några minuter till 24 timmar. Att förbereda DNS-posterna innan du gör en ny installation och sedan gå vidare till konfigurationen av Nginx serverblock kan snabba upp processen.

Rekommenderad katalogstruktur

En av de vanligaste misstagen vid hantering av flera webbplatser är att hålla alla filer i en enda oorganiserad katalog. Även om detta kan verka enkelt på kort sikt, kan det leda till betydande tidsförlust vid underhåll, backup och felsökning. En bättre metod är att använda en separat överkatalog för varje domän, med underkataloger som public, logs och backups.

En exempelstruktur kan planeras som följer: /var/www/site1.com/public, /var/www/site1.com/logs, /var/www/site2.com/public och /var/www/site2.com/logs. Nginx root-värdet ska peka direkt på public-katalogen, så att applikationsfiler, känsliga filer som .env och backups inte är direkt åtkomliga via webben.

För varje webbplatskatalog kan du placera en enkel index.html-fil för en statisk testwebbplats. Genom att skriva namnet på webbplatsen i innehållet kan du snabbt bekräfta vilket serverblock som är aktivt. I produktionsmiljöer är ägarskapet av dessa kataloger vanligtvis inställt på användaren www-data eller en speciell användare som gör distributioner. För filrättigheter är 755 för kataloger och 644 för filer tillräckligt i de flesta statiska scenarier. För applikationer som WordPress, som kräver skrivåtkomst, bör områden som uploads utvärderas separat.

Steg för steg: Skapa ett Nginx Serverblock

Nedan följer stegen som demonstreras med domännamnet site1.com. Du kan upprepa samma metod för andra webbplatser. Den kritiska punkten är att använda unika server_name, root och loggfiler för varje webbplats.

1. Skapa webbplatskatalogen

Det första steget är att skapa katalogen där webbfilen kommer att lagras. Exempel: sudo mkdir -p /var/www/site1.com/public. Skapa sedan en testfil /var/www/site1.com/public/index.html och skriv en distinkt text som "Detta är testwebbplatsen för site1.com".

För att ställa in ägarskapet korrekt kan kommandot sudo chown -R www-data:www-data /var/www/site1.com användas. Om du gör distributionsåtgärder med en annan användare, justera gruppbehörigheterna därefter. I produktionsmiljöer bör du undvika 777-behörigheter, där alla har skrivåtkomst. Dessa behörigheter kan låta angripare missbruka uppladdningskataloger.

2. Skapa serverblockfilen

En vanlig praxis i Nginx är att hålla inaktiva konfigurationer under /etc/nginx/sites-available och länka dem till /etc/nginx/sites-enabled med symboliska länkar. Exempel på fil: /etc/nginx/sites-available/site1.com.

En enkel HTTP serverblock skulle skrivas som följer: 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; } }

I denna konfiguration lyssnar listen 80 på HTTP-trafik, server_name anger vilka domäner som tillhör detta block, root visar katalogen där webbfilen finns, och index definierar standardfilen. try_files returnerar 404 om den begärda filen eller katalogen inte hittas. Denna struktur är tillräcklig för statiska webbplatser.

3. Aktivera webbplatsen

För att aktivera konfigurationen skapas en symbolisk länk: sudo ln -s /etc/nginx/sites-available/site1.com /etc/nginx/sites-enabled/site1.com. Denna metod är mer effektiv än att kopiera filer eftersom du arbetar med en enda huvudkonfigurationsfil. När du gör ändringar förblir den länkade filen uppdaterad.

Om du inte vill att den förvalda Nginx-sidan ska visas före din webbplats kan du inaktivera standardkonfigurationen. Detta kan göras genom att ta bort länken /etc/nginx/sites-enabled/default. Men se till att din egen serverblock fungerar korrekt innan du gör detta.

4. Testa konfigurationen och ladda om Nginx

Efter varje ändring bör syntaxen testas med kommandot sudo nginx -t. Om testet är framgångsrikt, ladda Nginx-tjänsten utan avbrott med kommandot sudo systemctl reload nginx. reload-kommandot är oftast säkrare än restart-kommandot eftersom det hanterar aktiva anslutningar mjukare.

Om testet misslyckas kommer felmeddelandet oftast att visa filnamnet och radnumret. Vanliga problem inkluderar saknade semikolon, felaktiga klamrar, felaktiga sökvägar eller kollisioner med server_name-värden. Nginx bör inte laddas om innan felet har åtgärdats.

Lägga till andra och tredje webbplatser

Skönheten med att hantera flera webbplatser är att processen blir repeterbar efter den första korrekta installationen. Skapa katalogen /var/www/site2.com/public för site2.com, skriv filen /etc/nginx/sites-available/site2.com, ändra root och loggvärden till site2.com, skapa en symbolisk länk och kör Nginx-testet.

För den andra webbplatsen kan den enkla strukturen skrivas som: 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; } }

Att använda separata loggar för varje webbplats är mycket värdefullt i verkliga livet. Till exempel kan 404-fel öka på en webbplats medan det inte finns några problem på en annan. Genom att ha en separat loggstruktur kan du snabbt hitta källan till felet. På samma sätt kan trafikanalys, botattacker, brutna länkar och prestandaproblem övervakas på webbplatsbasis.

SSL och HTTPS-konfiguration

Enligt SEO-standarderna 2026 är HTTPS inte bara en säkerhetsfunktion utan också en indikator på användartillit och teknisk kvalitet. Webbbläsare markerar HTTP-webbplatser som osäkra; SSL är obligatoriskt för projekt som involverar betalningar, medlemskap, formulär eller administrationspaneler. När du hanterar flera webbplatser ska varje domän ha rätt certifikat definierat. Kolla in sidan för SSL-certifikat på Hostragons för dina SSL-behov.

Om du använder Let’s Encrypt kan certifikat erhållas för varje domän med Certbot. I ett exempelkommando kan certbot --nginx -d site1.com -d www.site1.com upptäcka Nginx-konfigurationen och automatiskt lägga till HTTPS-blocket. Det är dock en bra vana att kontrollera filen efter automatisk redigering. Felaktiga omdirigeringar eller dubbla serverblockproblem kan uppstå.

I HTTPS-konfigurationen dirigeras vanligtvis trafik på port 80 permanent till port 443. En 301-omdirigering ger en permanent preferenssignal ur SEO-perspektiv. Bestäm om du vill använda www eller inte, och samla alla variationer till en enda kanonisk adress. Om du till exempel vill använda https://site1.com istället för https://www.site1.com, omdirigera både HTTP och HTTPS www-trafik till den icke-www-adressen. Detta minskar risken för duplicerat innehåll.

Nginx Serverblock för PHP och WordPress Webbplatser

I statiska HTML-webbplatser är konfigurationen enkel; men WordPress, Laravel eller specialbyggda PHP-applikationer kräver integration med PHP-FPM. I detta fall definieras index.php-filen och PHP-förfrågningar dirigeras till den relevanta socketen. Till exempel kan socketvägen för PHP 8.3 på Ubuntu vara /run/php/php8.3-fpm.sock. Versionen kan variera beroende på servern.

Exempel på PHP-logik: 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; } }

För att permanenta länkar ska fungera korrekt i WordPress är strukturen try_files $uri $uri/ /index.php?$args viktig. Dessutom bör säkerhetsåtgärder övervägas, såsom begränsning av åtkomst till xmlrpc.php, hastighetsbegränsning för wp-login.php och förhindrandet av PHP-exekvering i uploads-katalogen. Om du hostar många WordPress-webbplatser på samma VPS, använd en separat databas, separat användare och en regelbunden uppdateringspolicy för varje webbplats. För dem som letar efter alternativ för WordPress-hosting kan WordPress hosting vara ett mer hanterbart alternativ.

Jämförelse mellan Nginx Serverblock och Apache VirtualHost

Nginx och Apache når samma mål med olika arkitekturer. Båda kan hantera flera webbplatser på en enda server. Valet beror på applikationens behov, hanteringsvanor och prestandaförväntningar.

Om din applikation är starkt beroende av .htaccess-regler kan Apache vara lättare att använda. Men för hög trafik, omvänd proxy, cache och moderna distributionsflöden är Nginx ofta ett kraftfullt val för många projekt. I vissa infrastrukturer kan Nginx användas som en omvänd proxy, medan Apache fungerar som backend-applikationsserver.

Bästa praxis för säkerhet

Att hosta flera webbplatser på samma server ger kostnadsfördelar; men det ökar också säkerhetsansvaret. För att säkerställa att en sårbarhet på en webbplats inte påverkar de andra, bör isolering och principen om minimiåtkomst tillämpas.

• Skapa en separat databas och separat databas-användare för varje webbplats.
• Begränsa webbrotkatalogen till endast public-mappen.
• Håll backup, .env, .git, config och SQL-filer utanför webben.
• Förnya SSL-certifikat regelbundet och gör HTTPS-omdirigering obligatorisk.
• Använd UFW eller liknande brandvägg på servern; öppna endast nödvändiga portar.
• Applicera regelbundna uppdateringar av Nginx och operativsystemet.
• Ha separata access_log och error_log för varje webbplats.
• Lägg till IP-begränsningar eller extra autentisering på administrationspaneler.
• Undvik breda behörigheter som 777 i filrättigheter.

Det är också användbart att lägga till grundläggande säkerhetsrubriker. Rubriker som X-Frame-Options, X-Content-Type-Options, Referrer-Policy och Content-Security-Policy kan övervägas för lämpliga projekt. Men särskilt Content-Security-Policy kan blockera skript och stilfiler om det tillämpas felaktigt; så det bör testas i en testmiljö först. För mer innehåll om säkerhet kan du länka till artiklar om Webbsidans säkerhet.

Prestanda och SEO att tänka på

Nginx serverblock påverkar inte bara publiceringen utan även prestanda och SEO-kvalitet. Felaktiga omdirigeringskedjor, felaktiga kanoniska val, saknad gzip eller brotli-komprimering, stora loggfiler och otillräckliga cache-inställningar kan minska hastigheten på webbplatsen. Googles signaler om sidupplevelse är användarcentrerade; snabba, säkra och stabila webbplatser tenderar att prestera bättre.

Bestäm först en enda kanonisk version för varje domän. Omdirigera från HTTP till HTTPS, www till icke-www eller vice versa i ett enda steg. Kedjan bör inte vara: http://site.com först till http://www.site.com, sedan till https://www.site.com, och slutligen till https://site.com. Istället bör du gå direkt till målet med en enda 301-omdirigering.

Cache-control-rubriker kan användas för statiska filer. Bilder, CSS och JS-filer kan lagras i webbläsaren under en viss tid. Men för ofta föränderliga filer bör versionshantering eller query-strängstrategi användas. Gzip-komprimering minskar bandbredden för textbaserade filer som HTML, CSS, JS och JSON. För webbplatser med hög trafik kan användning av Nginx microcache, FastCGI-cache eller CDN övervägas. För CDN och globala åtkomstbehov kan du länka till en artikel som Vad är CDN.

Loggförvaltning och övervakning

Loggförvaltning är nyckeln till problemlösning vid hantering av flera webbplatser. Separata loggfiler visar tydligt vilken webbplats som har vilka fel. access_log registrerar besökarförfrågningar, medan error_log registrerar konfigurationsfel, behörighetsproblem, fil inte funnen och upstream-fel. 502 Bad Gateway-fel är vanligtvis relaterade till PHP-FPM eller backend-tjänstanslutningen. 403 Forbidden kan vara ett behörighetsproblem eller ett indexfilproblem. 404 Not Found kan indikera felaktig sökväg, rewrite eller felaktig root efter DNS.

För att förhindra att loggfiler växer oändligt bör logrotate-konfigurationen kontrolleras. För små projekt kan daglig eller veckovis rotation vara tillräckligt. För högtrafikerade webbplatser bör centrala logginsamlings-, metrisk övervakning- och varningssystem användas. Diskfullhet kan förhindra Nginx från att skriva loggar, stoppa databasen och göra webbplatser otillgängliga. Därför är det praktiskt att sätta tröskelvärden för disk användning.

Vanliga fel och snabba lösningar

När du arbetar med Nginx serverblock kan vissa fel uppstå i nästan varje projekt. Att känna till dessa kan avsevärt förkorta installationstiden.

• Fel domän öppnas: Kontrollera server_name-kollisioner och standardserverblock.
• 403 Forbidden-fel: Kontrollera root-katalog, filrättigheter och indexfilens existens.
• 404 Not Found-fel: Granska root-vägen och try_files-regeln.
• 502 Bad Gateway-fel: Bekräfta att PHP-FPM-tjänsten körs och att sökvägen till socketen är korrekt.
• SSL-certifikat verkar vara för fel webbplats: Kontrollera server_name och certifikatfiler på port 443.
• Omdirigeringsloop uppstår: Förenkla HTTP-HTTPS och www-omdirigeringsregler.
• Nginx laddas inte om: Åtgärda syntaxfelet baserat på radnumret i sudo nginx -t-utdata.

Det finns en enkel kontrollista som erfarna administratörer använder: Är DNS korrekt, är Nginx-konfigurationen aktiv, finns root-katalogen, är rättigheterna korrekta, har tjänsten klarat testet, vad säger loggen? Att gå igenom dessa steg i ordning gör att du kan lösa problem snabbt utan panik.

Praktisk kontrollista för produktionsmiljö

Innan du går live, bekräfta varje webbplats med följande kontrollista. Särskilt för kundprojekt är det professionellt att dokumentera dessa punkter innan leverans.

• Domänens A- eller AAAA-post pekar på rätt IP-adress.
• Antingen www-versionen eller icke-www-versionen har valts som kanonisk.
• HTTP-trafik omdirigeras till HTTPS med 301.
• SSL-certifikatet är giltigt och automatisk förnyelse är aktiv.
• Separata root- och loggfiler har definierats för varje webbplats.
• Nginx-konfigurationen har verifierats med sudo nginx -t.
• Backupplanen har definierats och återställningstest har utförts.
• Filrättigheterna följer minimiåtkomstprincipen.
• Endast nödvändiga portar är öppna i brandväggen.
• Fel-loggar har övervakats i minst 15 minuter efter lansering.

Denna lista kan verka kort, men den kan avsevärt minska risken för driftstopp i verkliga projekt. Särskilt stegen för SSL-förnyelse, DNS-kontroll och loggövervakning fångar många osynliga fel i tid.

Slutsats

Nginx serverblock är en av de grundläggande metoderna för att ordna, säkert och effektivt hantera flera webbplatser på en enda server. Genom att använda rätt katalogstruktur, separata konfigurationsfiler, tydliga omdirigeringsregler, användning av HTTPS, loggavskiljning och en regelbunden testprocess kan hanteringen av flera webbplatser göras mycket effektiv. Samma principer kan tillämpas från en liten portföljwebbplats till flera kundprojekt.

Om du planerar att lansera ett nytt projekt, börja med att klargöra dina domän-, serverresurs- och SSL-behov; följ sedan kontrollistan ovan för att steg för steg sätta upp din Nginx-konfiguration. Om du letar efter en mer hanterbar infrastruktur kan du utforska Hostingpaket, VPS-server och SSL-certifikat från Hostragons för att välja en lämplig startpunkt för ditt projekt.

Vanliga frågor

Hur många webbplatser kan hostas med Nginx serverblock?

Tekniskt kan du hosta många webbplatser på samma server med Nginx; gränsen beror vanligtvis på CPU, RAM, disk, trafik, databasbelastning och PHP-FPM-kapacitet. Det kan vara möjligt att ha dussintals lågt traffikerade statiska webbplatser, medan det kan vara bättre att hosta färre webbplatser för trafikintensiva WordPress- eller e-handelsprojekt.

Behövs separata SSL-certifikat för varje webbplats?

Ja, varje domän eller subdomän som ska publiceras via HTTPS bör inkluderas i certifikatets omfattning. Antingen kan separata certifikat användas, eller så kan SAN- eller wildcard-certifikat väljas. Det viktiga är att de rätta certifikatfilerna är kopplade till rätt domän i Nginx 443-serverblocket.

Kan subdomäner publiceras med Nginx serverblock?

Ja. Du kan definiera separata server_name för subdomäner som blog.site.com eller panel.site.com och dirigera dem till olika rotkataloger eller olika backend-applikationer. På DNS-sidan måste relevanta A- eller CNAME-poster skapas för subdomänen.

Vad är skillnaden mellan sites-available och sites-enabled?

sites-available är platsen för tillgängliga konfigurationsfiler; sites-enabled innehåller aktiva konfigurationer. Vanligtvis skapas en symbolisk länk i sites-enabled till filen i sites-available. Denna metod gör det mer organiserat att aktivera och inaktivera webbplatser.

Vad kan orsaka att fel webbplats öppnas?

De vanligaste orsakerna är att DNS pekar på fel IP, att server_name-värdet är felaktigt, att standard Nginx-blocket fångar förfrågan eller att ett felaktigt SSL-block körs på port 443. Kontrollera först DNS-posterna, sedan utdata från nginx -t, aktiva länkar i sites-enabled och relevanta access_log-filer.