Nginx szerverblokkokkal több weboldal hosztolása lépésről lépésre

Az Nginx szerverblokkok olyan virtuális hosztok, amelyek segítségével egyetlen Nginx telepítésen belül több domain vagy weboldal külön-külön konfigurálva futtatható. Például ugyanazon VPS-en az example.com, blog.example.com és masodik-oldal.hu különböző gyökérkönyvtárakkal, naplófájlokkal, SSL tanúsítványokkal és PHP beállításokkal kezelhetők. Röviden: minden oldalnak külön mappát hozunk létre, a domain DNS rekordjait a szerver IP-jére irányítjuk, a /etc/nginx/sites-available mappában külön szerverblokkot készítünk, amit a sites-enabled mappába szimbolikus linkként kapcsolunk, majd a konfigurációt ellenőrizzük és újratöltjük az Nginx szolgáltatást.

Ebben az útmutatóban az Nginx szerverblokkokkal történő többoldalas hosztolást mutatjuk be éles környezetre optimalizált megközelítéssel. Nemcsak egy működő konfiguráció felépítése a cél, hanem egy könnyen kezelhető, biztonságos, gyors, menthető és skálázható rendszer kialakítása. Különösen hasznos lehet ez digitális ügynökségeknek, fejlesztőknek, webáruház-tulajdonosoknak, több márkát kezelő vállalkozásoknak és rendszergazdáknak, akik egy szerveren több projektet futtatnak. Ha még nincs saját szervered, érdemes áttekintened a VPS szerver és a domain kezeléssel kapcsolatos Domain Nyilvántartás oldalakat.

Mi az az Nginx szerverblokk?

Az Nginx szerverblokkok az Nginx konfigurációban definiált, szerverként ismert egységek, amelyek megmondják, hogy egy adott HTTP vagy HTTPS kérés melyik weboldalhoz tartozik. Ez az Apache VirtualHost fogalmához hasonló. Amikor egy felhasználó beír egy domain nevet a böngészőbe, a DNS az adott domainhez társított IP-címet adja vissza. Az Nginx ezt követően megvizsgálja a kérés Host fejlécét, és a server_name érték alapján kiválasztja a megfelelő szerverblokkot.

Ennek köszönhetően ugyanazon IP-címen és fizikai vagy virtuális szerveren több tucat különböző weboldal futtatható. Mindegyikhez megadható egyedi root könyvtár, hozzáférési és hibanapló, átirányítási szabályok, SSL tanúsítvány, gyorsítótárazási szabályzat és biztonsági beállítás. Például a cég weboldalát a /var/www/ceg/public, a blogot a /var/www/blog/public, a tesztkörnyezetet pedig a /var/www/staging/public mappában tarthatod.

Az Nginx különösen hatékony ebben a felállásban, mivel eseményalapú működése révén magas párhuzamos kapcsolatszámot képes kis erőforrásigénnyel kezelni. Ezért gyakran használják megosztott tárhelyeken, VPS-eken, felhőszolgáltatásokon és nagy forgalmú alkalmazások alatt. A többoldalas hosztolás zökkenőmentes működéséhez azonban minden részletnek – a fájlengedélyektől a DNS beállításokon át az SSL telepítésig és a naplózásig – precíznek kell lennie.

Mikor érdemes Nginx szerverblokkokat használni?

Az Nginx szerverblokkok elsősorban akkor jönnek jól, ha egyetlen szerveren több weboldalt kell kezelni. Ez lehet néhány kisebb vállalati oldal, de akár több tucat ügyfélprojekt, aldomain vagy mikro-szolgáltatás is. A kulcs, hogy minden projekt logikailag elkülönüljön egymástól.

• Több domain név futtatása egy VPS-en.
• WWW-s és nem WWW-s domain verziók egyetlen kanonikus címre irányítása.
• Aldomain nevek külön mappákhoz vagy alkalmazásokhoz rendelése.
• Minden oldalhoz külön SSL tanúsítvány és biztonsági szabályok megadása.
• Ügyfélprojektek elkülönített naplózása.
• Különböző alkalmazások (pl. Laravel, WordPress, statikus HTML, Node.js) egy szerveren való futtatása.

Például egy digitális ügynökség technikailag képes egy 4 GB RAM-os VPS-en 8 alacsony forgalmú vállalati weboldalt futtatni. Ugyanakkor minden oldal esetében érdemes figyelembe venni a forgalmat, lemezhasználatot, PHP folyamatokat, adatbázis terhelést és mentési gyakoriságot. Ha a projektek nagy forgalmat generálnak vagy kritikus a források elkülönítése, akkor erősebb VPS, felhőalapú szerver vagy menedzselt tárhely megoldások javasoltak. Ebben az esetben érdemes összehasonlítani a Web Hosting és Vállalati Hosting opciókat.

Kezdés előtt: követelmények

Az útmutató Ubuntu vagy Debian alapú Linux szerverre fókuszál. A parancsok disztribúciótól függően változhatnak, de az alapelvek ugyanazok. Éles környezetben minden művelet előtt készíts mentést, mert egy hibás Nginx konfiguráció átmeneti elérhetetlenséget okozhat az összes oldal számára.

Szükséges technikai előkészületek

• Root vagy sudo jogosultsággal rendelkező Linux felhasználó.
• Telepített és futó Nginx szolgáltatás.
• Legalább egy domain, amely a szerver IP-címére mutat.
• A 80-as és 443-as portok nyitva vannak a tűzfalon.
• Rendezett mappastruktúra a weboldalak fájljainak.
• Érvényes SSL tanúsítvány vagy ingyenes Let’s Encrypt tanúsítvány használata.
• PHP alapú alkalmazásokhoz PHP-FPM telepítése.

A DNS-ben az A rekord a fő domain nevet az IPv4 címre, az AAAA rekord (ha van) az IPv6 címre irányítja. Az aldomain-ek (pl. www) CNAME vagy A rekorddal rendelhetők hozzá. A DNS terjedése általában néhány perctől 24 óráig tarthat. Új telepítéskor először a DNS rekordokat érdemes beállítani, majd az Nginx szerverblokkok konfigurálásával folytatni, így gyorsabb a folyamat.

Ajánlott mappaszerkezet

Több oldal hosztolásánál az egyik leggyakoribb hiba, hogy minden fájlt egyetlen mappában tartanak összevissza. Ez rövid távon egyszerűnek tűnhet, de karbantartás, mentés és hibakeresés során rengeteg időt veszítünk. Jobb, ha minden domainhez külön főmappát hozunk létre, és abban elkülönítjük a publikus fájlokat, naplókat és mentéseket.

Például az alábbi struktúrát alkalmazhatjuk: /var/www/site1.hu/public, /var/www/site1.hu/logs, /var/www/site2.hu/public, /var/www/site2.hu/logs. Az Nginx root beállítását mindig a public könyvtárra mutassuk, hogy az alkalmazásfájlok, .env vagy mentések ne legyenek közvetlenül elérhetők a weben.

Egyszerű statikus tesztoldal létrehozásához minden site mappában helyezzünk el egy index.html fájlt, amelyben szerepel a domain neve. Így gyorsan ellenőrizhető, melyik szerverblokk működik. Éles környezetben a mappák tulajdonosa általában a www-data vagy a telepítést végző speciális felhasználó. A fájlengedélyek 755 (mappákra) és 644 (fájlokra) általában elegendőek statikus oldalak esetén. Olyan alkalmazásoknál, mint például WordPress, az uploads mappa külön engedélyezést igényelhet.

Lépésről lépésre: Nginx szerverblokk létrehozása

Az alábbi példában a site1.hu domainon mutatjuk be a folyamatot. Ugyanezt megismételheted további oldalakhoz is. A lényeg, hogy minden weboldalhoz egyedi server_name, root és naplófájlok tartozzanak.

1. Weboldal mappa létrehozása

Első lépésként hozzuk létre a webfájlok helyét: például sudo mkdir -p /var/www/site1.hu/public. Ezután készítsünk egy egyszerű index.html fájlt a public mappába, amelyben például ez áll: „Ez a site1.hu tesztoldala”.

A fájlok tulajdonjogát állítsuk be helyesen: sudo chown -R www-data:www-data /var/www/site1.hu. Ha más felhasználó végzi a telepítést, a csoport jogosultságokat ennek megfelelően módosítsuk. Kerüljük a 777-es engedélyeket, mert ezek biztonsági kockázatot jelentenek és támadók számára nyithatnak kaput.

2. Szerverblokk fájl létrehozása

Az Nginx-ben bevett gyakorlat, hogy az elérhető konfigurációkat a /etc/nginx/sites-available mappában tartjuk, a ténylegesen aktívakat pedig a /etc/nginx/sites-enabled mappába szimbolikus linkkel kapcsoljuk be. Például a konfigurációs fájl neve lehet: /etc/nginx/sites-available/site1.hu.

Egy egyszerű HTTP szerverblokk így nézhet ki:

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

Ebben a konfigurációban a listen 80 az HTTP forgalmat fogadja, a server_name megadja, hogy mely domainekre reagál a blokk, a root a weboldal gyökérkönyvtára, az index az alapértelmezett fájl(ok), a try_files pedig a kért fájl vagy mappa meglétét ellenőrzi, hiány esetén 404-es hibát ad.

3. A szerverblokk aktiválása

A konfiguráció aktiválásához hozzunk létre szimbolikus linket:

sudo ln -s /etc/nginx/sites-available/site1.hu /etc/nginx/sites-enabled/site1.hu

Ez a módszer jobb, mint a fájlok másolása, mert így minden módosítás automatikusan érvényesül. Ha nem szeretnéd, hogy az alapértelmezett Nginx oldal megjelenjen, távolítsd el a /etc/nginx/sites-enabled/default szimbolikus linket, de előtte győződj meg róla, hogy az új blokk hibátlanul működik.

4. Konfiguráció ellenőrzése és Nginx újratöltése

Minden módosítás után futtasd a szintaxis ellenőrzést:

sudo nginx -t

Ha a teszt sikeres, töltsd újra az Nginx-et megszakítás nélkül:

sudo systemctl reload nginx

Az újratöltés általában biztonságosabb, mint az újraindítás, mert a meglévő kapcsolatok zavartalanul maradnak. Ha hiba lép fel, az üzenet megmutatja a problémás sort és fájlt. Gyakori hibák: hiányzó pontosvessző, rossz kapcsos zárójel, hibás elérési út vagy ütköző server_name értékek. Hiba javítása nélkül ne töltsd újra az Nginx-et.

Második és harmadik oldal hozzáadása

Több weboldal kezelése akkor egyszerű, ha az első helyes beállítás után a folyamatot megismétled. A site2.hu esetében hozz létre egy /var/www/site2.hu/public mappát, írj egy új szerverblokk fájlt /etc/nginx/sites-available/site2.hu néven, ahol a root és a naplófájlok nevei a site2.hu-hoz igazodnak, majd hozd létre a szimbolikus linket és futtasd az ellenőrzést.

Egyszerű szerverblokk példa a második oldalra:

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

A különálló naplózás valós helyzetben nagy segítség lehet: például ha az egyik oldalon megnő a 404-es hibák száma, míg a másikon nincs probléma. Így gyorsan megtalálható a hiba forrása. Ugyanígy követhetők a forgalmi adatok, robot támadások, törött linkek és teljesítményproblémák oldalanként.

SSL és HTTPS beállítása

2026-tól a SEO szabványok szerint a HTTPS nemcsak biztonsági előírás, hanem a felhasználói bizalom és a technikai minőség jele is. A böngészők az HTTP oldalakat „nem biztonságosnak” jelölik; fizetős, regisztrációs, űrlapos vagy adminisztrációs felületeket feltétlenül SSL-lel kell védeni. Többoldalas hosztolásnál mindegyik domainhez külön kell a megfelelő tanúsítványt hozzárendelni. Az SSL igényeidet a Hostragons SSL tanúsítványok oldalán ismerheted meg.

Ha Let’s Encrypt-et használsz, a Certbot segítségével minden domainhez kérhetsz tanúsítványt. Például a certbot --nginx -d site1.hu -d www.site1.hu parancs felismeri az Nginx konfigurációt és automatikusan hozzáadja a HTTPS blokkot. Az automatikus módosítás után érdemes ellenőrizni a fájlt, mert előfordulhatnak helytelen átirányítások vagy duplikált szerverblokkok.

HTTPS beállításnál általában a 80-as portforgalmat véglegesen (301-es átirányítással) a 443-as portra irányítjuk. Ez SEO szempontból a legjobb gyakorlat. Döntsd el, hogy www-t használsz-e, és az összes forgalmat irányítsd a kiválasztott kanonikus címre. Például ha https://site1.hu-t választod, akkor az összes http://www.site1.hu, https://www.site1.hu és http://site1.hu kérést erre az egy címre irányítsd. Így elkerülhető a tartalomduplikáció.

PHP és WordPress oldalak Nginx szerverblokkjai

Statikus HTML oldalakon egyszerű a konfiguráció, de WordPress, Laravel vagy egyedi PHP alkalmazások esetén PHP-FPM integráció szükséges. Ilyenkor az index.php-t is meg kell adni, a PHP kéréseket pedig a megfelelő socketre kell továbbítani. Ubuntu alatt például a PHP 8.3 socket elérési útja lehet: /run/php/php8.3-fpm.sock, de verziótól függően eltérhet.

Példa PHP-alapú szerverblokk:

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

A try_files sor a WordPress állandó permalinkek (permalinkek) működéséhez létfontosságú. Emellett érdemes biztonsági beállításokat is alkalmazni, például xmlrpc.php elérés korlátozása, wp-login.php forgalom szabályozás, PHP futtatás tiltása az uploads mappában. Ha sok WordPress oldalt futtatsz egy VPS-en, minden oldalnak legyen külön adatbázisa, felhasználója és rendszeres frissítési politikája. WordPress tárhely megoldások iránt érdeklődőknek a WordPress hosting oldalt ajánljuk, amely egyszerűbb kezelhetőséget kínál.

Nginx szerverblokkok vs. Apache VirtualHost

Az Nginx és az Apache eltérő architektúrával ugyanazt a célt szolgálja: több oldal futtatását egy szerveren. A választás az alkalmazás igényeitől, a kezelési szokásoktól és a teljesítmény elvárásoktól függ.

Ha az alkalmazásod erősen támaszkodik .htaccess szabályokra, az Apache kényelmesebb lehet. Magas forgalmú, proxyzást és cache-t igénylő környezetben az Nginx a jobb választás. Egyes rendszerekben az Nginx működhet reverse proxyként, míg az Apache a háttéralkalmazás szerverként szolgál.

Biztonsági legjobb gyakorlatok

Több oldal egy szerveren költséghatékony, de a biztonsági felelősség is nő. Egy oldal se tudja veszélyeztetni a többieket izoláció és minimális jogosultságok alkalmazásával.

• Minden oldalhoz külön adatbázis és külön adatbázis-felhasználó.
• Webkönyvtár szigorúan csak a public mappára korlátozva.
• Mentéseket, .env, .git, config és SQL fájlokat kizárni a webes hozzáférésből.
• SSL tanúsítványokat rendszeresen megújítani és HTTPS átirányítást kötelezővé tenni.
• UFW vagy hasonló tűzfal használata, csak a szükséges portok nyitva tartása.
• Az Nginx és az operációs rendszer frissítéseinek rendszeres telepítése.
• Minden oldalhoz külön access_log és error_log naplózás.
• Admin felületek IP alapú korlátozása vagy további hitelesítés bevezetése.
• Kerülni a 777-es, túl nyitott fájlengedélyeket.

Hasznos lehet biztonsági HTTP fejlécek alkalmazása is, mint az X-Frame-Options, X-Content-Type-Options, Referrer-Policy és Content-Security-Policy. A CSP-t különösen óvatosan kell beállítani, mert téves konfiguráció esetén blokkolhatja a szkripteket vagy stílusokat. Mielőtt élesíted, tesztkörnyezetben próbáld ki. Több biztonsági tanácsért nézd meg a weboldal biztonság cikkeinket.

Teljesítmény és SEO tippek

Az Nginx szerverblokkok nemcsak a működést, hanem a sebességet és a keresőoptimalizálást is befolyásolják. Rossz átirányítási láncok, helytelen kanonikus címek, hiányzó gzip vagy brotli tömörítés, nagy naplófájlok és nem megfelelő cache-beállítások lassíthatják az oldalt. A Google oldalélmény értékelése a felhasználói élményre fókuszál; a gyors, biztonságos és stabil oldalak előnyben vannak.

Minden domainhez csak egy kanonikus verziót állíts be. Az átirányítás legyen egy lépéses, például ne http://site.hu-ról előbb http://www.site.hu-ra, majd onnan https://www.site.hu-ra, és végül https://site.hu-ra irányíts. Ehelyett egyből 301-es átirányítással juttasd el a látogatót a végső címre.

Statikus fájlok esetén használj cache-control fejléceket, hogy a böngészők hosszabb ideig tárolják azokat. A gyakran változó fájloknál alkalmazz verziószámozást vagy lekérdezési stringet. A gzip tömörítés csökkenti a sávszélesség-használatot HTML, CSS, JS és JSON esetén. Nagy forgalmú weboldalaknál érdemes Nginx microcache-t, FastCGI cache-t vagy CDN-t alkalmazni. Globális eléréshez a Mi az a CDN? tartalom is hasznos lehet.

Naplózás és monitorozás

Több oldal hosztolásánál a naplózás a hibakeresés kulcsa. Külön naplófájlok mutatják, hogy melyik oldalon milyen hiba történt. Az access_log a látogatói kéréseket, az error_log pedig konfigurációs, jogosultsági, fájlhiány vagy backend problémákat rögzít. A 502 Bad Gateway hiba jellemzően PHP-FPM vagy háttérszolgáltatás kapcsolódási gondot jelez. A 403 Forbidden engedélyezési problémára, az index fájl hiányára utalhat. A 404 Not Found általában rossz útvonal, átírás vagy DNS beállítási hiba következménye lehet.

A naplók méretének korlátlan növekedése elkerülendő, ezért ellenőrizd a logrotate konfigurációt. Kisebb projektekben napi vagy heti rotáció elegendő. Nagy forgalmú oldalakon központi naplógyűjtés, metrikakövetés és riasztási rendszer ajánlott. A lemez megtelése megakadályozza a naplóírást, ami adatbázis leálláshoz, majd az oldalak elérhetetlenségéhez vezethet. Ezért érdemes korlátokat beállítani a lemezhasználatra.

Gyakori hibák és gyors megoldások

Az Nginx szerverblokkokkal dolgozva bizonyos hibák gyakran előfordulnak. Ezek ismerete jelentősen lerövidíti a telepítési időt.

• Nem a megfelelő oldal töltődik be: ellenőrizd a server_name ütközéseket és az alapértelmezett szerverblokkot.
• 403 Forbidden hiba: ellenőrizd a root könyvtárat, a fájlengedélyeket és az index fájl meglétét.
• 404 Not Found hiba: nézd át a root útvonalat és a try_files szabályt.
• 502 Bad Gateway hiba: győződj meg a PHP-FPM futásáról és a socket elérhetőségéről.
• Az SSL tanúsítvány rossz oldalhoz csatlakozik: ellenőrizd a 443-as port szerverblokkjait és tanúsítványfájljait.
• Átirányítási hurok: egyszerűsítsd le az HTTP-HTTPS és www átirányítási szabályokat.
• Nem töltődik újra az Nginx: javítsd a szintaxis hibákat a sudo nginx -t kimenete alapján.

Tapasztalt rendszergazdák egy egyszerű ellenőrző listát követnek: DNS megfelelő-e, Nginx konfiguráció aktív és hibamentes, root mappa létezik és jogosultságok rendben vannak, szolgáltatás teszt sikeres, naplók mit mutatnak? Ezzel a sorrenddel gyorsan és nyugodtan oldható meg a legtöbb probléma.

Éles környezethez hasznos ellenőrző lista

Az élesítés előtt a következőket mindenképp ellenőrizd, különösen ügyfélprojektek esetén, hiszen ezek dokumentálása professzionális munkát tükröz.

• A domain A vagy AAAA rekordja a megfelelő IP-re mutat.
• A www-s és nem www-s verzió közül egy kanonikus cím kiválasztva.
• HTTP forgalom HTTPS-re 301-es átirányítással irányul.
• Az SSL tanúsítvány érvényes és automatikus megújítás beállítva.
• Minden oldalhoz külön gyökérkönyvtár és naplófájl van definiálva.
• Nginx konfigurációt sudo nginx -t paranccsal ellenőrizted.
• Mentési terv készült és visszaállítás tesztelve.
• Fájlengedélyek a minimális jogosultság elve szerint vannak beállítva.
• A tűzfalon csak a szükséges portok nyitottak.
• Legalább 15 percig figyelemmel kísérted a hibanaplókat az élesítés után.

Bár ez a lista egyszerűnek tűnik, éles környezetben jelentősen csökkenti a leállás kockázatát. Különösen az SSL megújítás, DNS ellenőrzés és naplófigyelés lépései segítenek korán kiszűrni a rejtett hibákat.

Összegzés

Az Nginx szerverblokkok az egyik legjobb módszer arra, hogy egy szerveren több weboldalt biztonságosan, rendezett módon és hatékonyan futtassunk. A megfelelő mappaszerkezet, külön konfigurációs fájlok, egyértelmű átirányítási szabályok, HTTPS alkalmazása, naplózás elkülönítése és rendszeres tesztelés révén a többoldalas menedzsment gördülékennyé válik. Legyen szó egy kis portfólió oldalról vagy több ügyfélprojektjéről, ugyanazok az alapelvek érvényesek.

Ha új projektet indítasz, először tedd rendbe a domain nevet, a szerver erőforrásait és az SSL igényeket, majd a fenti ellenőrzőlistát használva lépésről lépésre állítsd össze az Nginx konfigurációt. Ha kényelmesebb, menedzselt megoldást keresel, a Hostragons Hosting csomagok, VPS szerver és SSL tanúsítványok szolgáltatásai jó kiindulópontot jelentenek.

Gyakran ismételt kérdések

Hány weboldalt lehet hosztolni Nginx szerverblokkokkal?

Technikailag korlátlan számú oldalt futtathatsz, a határ inkább a CPU, RAM, lemez, forgalom, adatbázis terhelés és PHP-FPM kapacitás függvénye. Alacsony forgalmú statikus oldalakból sok is elfér, de nagy forgalmú WordPress vagy webáruház esetén kevesebb oldalt érdemes hostolni.

Minden oldalhoz külön SSL tanúsítvány kell?

Igen, ha minden domain vagy aldomain HTTPS-en fut, akkor a tanúsítványnak le kell fednie az adott címet. Lehet külön tanúsítvány oldalanként, de használhatsz SAN vagy wildcard tanúsítványt is. Fontos, hogy az Nginx 443-as szerverblokkban a megfelelő tanúsítvány fájlokat rendeld hozzá a domainhez.

Lehet subdomaint hosztolni Nginx szerverblokkal?

Igen, például blog.site.hu vagy panel.site.hu aldomainhez külön server_name beállítást adhatsz, és más root könyvtárra vagy backend alkalmazásra irányíthatod őket. A DNS-ben az adott aldomainhez A vagy CNAME rekordot kell létrehozni.

Miben különbözik a sites-available és a sites-enabled mappa?

A sites-available a rendelkezésre álló konfigurációs fájlokat tartalmazza, míg a sites-enabled az aktív, betöltött konfigurációkat. Általában a sites-enabled-ben szimbolikus linkek vannak a sites-available fájlokra, így könnyen lehet aktiválni vagy deaktiválni oldalakat.

Ha rossz oldal töltődik be, mi lehet a probléma?

Leggyakoribb okok: a DNS rossz IP-re mutat, a server_name helytelen, az alapértelmezett Nginx blokk fogadja a kérést vagy a 443-as SSL blokk nincs jól beállítva. Ellenőrizd a DNS rekordokat, használd a nginx -t parancsot, vizsgáld meg az aktív sites-enabled linkeket és a kapcsolódó naplófájlokat.