Apache vs. NGINX: melyik webszerver a legjobb a WordPresshez?

Ha saját VPS-en futtatod a WordPresst, az Apache és az NGINX is jól kiszolgálja az oldalt, de más kompromisszumokat kötnek. Nagy párhuzamosságnál, statikus fájlok kiszolgálásánál és az opcionális HTTP/3-nál általában az NGINX a jobb alapértelmezés. Az Apache akkor egyszerűbb, ha a WordPress-környezeted .htaccess-re vagy Apache-specifikus modulokra épül.

Ez az Apache és NGINX összehasonlítás azokra a különbségekre koncentrál, amelyek a WordPress szempontjából számítanak: architektúra, PHP-kezelés, konfiguráció, HTTP/3, és hogy megéri-e a plusz bonyolultság mindkettőt futtatni. A LiteSpeed és a Caddy nem tartozik ide.

Rövid válasz: saját kezelésű WordPress VPS-en alapértelmezésben válaszd az NGINX-et. Az Apache-ot akkor válaszd, ha az oldalad vagy a bővítményeid erősen támaszkodnak a .htaccess-re. Mindkettőt csak akkor futtasd, ha kifejezetten NGINX-re van szükséged elöl, az Apache-kompatibilitás feladása nélkül.

Mi az az Apache?

Az Apache széles körben használt nyílt forráskódú webszerver-szoftver, amelyet az amerikai nonprofit Apache Software Foundation (ASF) fejleszt és tart karban. Apache HTTP Server és HTTPD néven is ismert.

Az Apache letöltési oldala a 2026 júniusában megjelent 2.4.68-as verziót jelöli meg aktuális stabil kiadásként.

Az Apache HTTP Server moduláris nyílt forráskódú szerver, amely érett támogatást ad a könyvtárszintű .htaccess szabályokhoz, több többfeldolgozású modulhoz (MPM), a fordított proxyhoz, az URL-átíráshoz, a TLS-hez és a dinamikusan betöltött modulokhoz. WordPress esetén a legnagyobb gyakorlati előnye a konfigurációs kompatibilitás, nem a nyers sebesség.

Az Apache azon képességei, amelyek ebben az összehasonlításban a leginkább számítanak: a prefork, worker és event MPM-ek; a .htaccess; a HTTP/2; a fordított proxy és a terheléselosztás; a FastCGI-támogatás; a dinamikus modulok; az URL-átírás; és a TLS.

Mi az az NGINX?

Az NGINX („engine x”) nyílt forráskódú webszerver, fordított proxy, tartalomgyorsítótár, terheléselosztó, TCP/UDP-proxy és levelezőproxy, amelyet eredetileg Igor Sysoev írt. A worker folyamatai eseményvezérelt modellt használnak, amelyet sok egyidejű kapcsolat alacsony kapcsolatonkénti költséggel való kiszolgálására terveztek.

Az NGINX letöltési oldala lists the 1.30.x stable branch and the 1.31.x mainline branch.

Apache vs. NGINX: a legfontosabb különbségek WordPresshez

Az Apache és az NGINX leginkább abban tér el, hogyan kezeli a kapcsolatokat, a konfigurációt, a PHP-t és a protokolltámogatást. Az Apache viselkedése erősen függ a használt MPM-től, az NGINX viszont eseményvezérelt worker folyamatokat használ.

Apache vs. NGINX: architektúra

Az Apache kéréskezelési modellje attól függ, melyik MPM-et futtatod. A prefork folyamatalapú, a worker és az event pedig szálakat használ. Az NGINX eseményhurkokra épülő worker folyamatokkal dolgozik. Emiatt a jól ismert „folyamatvezérelt Apache kontra eseményvezérelt NGINX” összevetés túl leegyszerűsítő egy mai Apache 2.4-es telepítéshez.

Az Apache event MPM-je a tétlen keep-alive kapcsolatokat átadhatja a figyelő szálának, ahelyett hogy mindegyikhez lekötne egy worker szálat. Nagyon nagy számú egyidejű kapcsolatnál az NGINX kapcsolatonkénti terhelése továbbra is általában alacsonyabb, de az architekturális különbség sokkal kisebb, mint azt a prefork-korszak régi összevetései sugallják.

Apache vs. NGINX: teljesítmény

Az NGINX teljesítménybeli előnye főleg nagy párhuzamosságnál és statikus fájlok kiszolgálásánál jelenik meg. Eseményvezérelt worker folyamatai sok kapcsolatot tudnak nyitva tartani viszonylag alacsony kapcsolatonkénti terheléssel. Az Apache event MPM-je ezt a különbséget a régebbi prefork beállításokhoz képest jelentősen szűkíti.

A dinamikus WordPress-kérések más lapra tartoznak. Az NGINX általában továbbadja a PHP-t a FastCGI-nak, jellemzően a PHP-FPM-nek. Az Apache is használhatja a PHP-FPM-et FastCGI-on keresztül, vagy futtathatja a PHP-t egy Apache-modullal.

Amint a PHP futtatni kezdi a WordPresst, a bővítmények kódja, az adatbázis-lekérdezések, az objektum- vagy oldalgyorsítótár és a PHP worker-ek száma többet nyomhat a latban, mint az előtte álló webszerver. Ha egy bővítmény kérésenként egy tucat drága adatbázis-lekérdezést futtat, az Apache-ról NGINX-re váltás nem oldja meg a mögöttes gondot.

Apache vs. NGINX: HTTP/3- és QUIC-támogatás

A HTTP/3 a protokoll jelenlegi verziója, és TCP helyett QUIC felett fut. Hogy az oldalad egyáltalán kínálhatja-e, az előtte álló webszervertől függ, és ez az egyetlen összehasonlítási pont, ahol a két szerver nincs közel egymáshoz.

Az NGINX az 1.25.0-s verzió óta szállít HTTP/3 modult. Alapértelmezés szerint nem fordul bele, a build a --with-http_v3_module paramétert igényli.

Az NGINX HTTP/3 moduljának dokumentációja a modult továbbra is „experimental, caveat emptor applies” megjelöléssel írja le.

Az Apache 2.4 nem hoz natív HTTP/3- vagy QUIC-modult; a vele szállított protokolltámogatás a mod_http2-nél véget ér.

A gyakorlati következmény egy oldal üzemeltetőjének: egy szokványos Apache 2.4 telepítés nem kínál HTTP/3-at. Éles üzemben továbbra is az a járható út, hogy a HTTP/3-at egy HTTP/3-képes fordított proxy vagy CDN zárja le az Apache előtt. Ha kell a protokoll, az egyik lehetőség, hogy NGINX-et teszel az Apache elé, és az NGINX zárja le a kliensek kapcsolatait, pontosan az a felállás, amelyről lejjebb lesz szó.

Apache vs. NGINX: biztonság

Sem az Apache, sem az NGINX nem kategorikusan „biztonságosabb”. Mindkettő érett projekt aktív biztonsági karbantartással, és egy éles rendszer biztonsága inkább a javításoktól, az engedélyezett moduloktól, a TLS-beállítástól, a hozzáférés-szabályozástól, a sebességkorlátoktól és a szerver mögötti alkalmazástól függ.

Az érdemi összehasonlítás a támadási felületről és a konfigurációról szól, nem arról, ki a győztes. Kapcsold ki a nem használt modulokat és végpontokat, tartsd frissen a szervert, és keményítsd meg a mögötte lévő WordPress-környezetet.

Apache vs. NGINX: konfiguráció

Az Apache könyvtárszintű .htaccess fájljai akkor működnek, ha az AllowOverride engedi. Ez WordPress esetén hasznos, mert az átírási szabályok a globális szerverkonfiguráció módosítása nélkül változtathatók.

Ennek a kényelemnek ára van. Az Apache saját dokumentációja azt ajánlja, hogy a szabályokat a fő szerverkonfigurációba tedd, ha van root hozzáférésed: a .htaccess fájlokat a kérések során ellenőrzi a szerver, engedélyezésük pedig teljesítménybeli és biztonsági megfontolásokkal is jár.

Az NGINX-nek nincs .htaccess megfelelője. A konfigurációja központosított, így a WordPress nem tud helyetted szerverszintű átírási szabályokat írni. A permalink-szabályokat és a bővítményspecifikus szerverdirektívákat egy rendszergazdának kell hozzáadnia az NGINX konfigurációjához, majd újratöltenie azt.

Apache vs. NGINX: modulok és bővíthetőség

Az Apache érett támogatást ad a dinamikus megosztott objektumokhoz (DSO): a modulok külön fordíthatók és a LoadModule utasítással tölthetők be. Az NGINX is támogat dinamikusan betöltött modulokat a load_module segítségével, de a telepített NGINX-verzióval és annak fordítási beállításaival való bináris kompatibilitás nagyobb súlyt kap, amint nem szokványos, külső modulokat használsz.

Az Apache tehát előnyben van, ha szokatlan külső modulokra támaszkodsz. A megszokott WordPress-tárhelyeknél ez a különbség rendszerint kevesebbet nyom a latban, mint a .htaccess, a PHP kezelése és a már használt eszközkészleted.

Apache vs. NGINX: platformtámogatás

Az Apache fut Linuxon, Windowson, macOS-en és sok Unix-szerű rendszeren. Az NGINX is elérhető a főbb platformokon, de a natív Windows-változatának komoly korlátai vannak. Az NGINX továbbra is bétaként jelöli a Windows-verziót, jelzi, hogy nem szabad nagy teljesítményt és skálázódást várni tőle, megjegyzi, hogy ténylegesen csak egy worker dolgozik, és nem támogatja sem az UDP-t, sem a QUIC-et. Éles NGINX-telepítéshez egy Unix-szerű operációs rendszer a gyakorlatias választás.

Apache vs. NGINX: kérések kezelése

Az Apache rendes esetben a kérés URL-jét a DocumentRoot alatti fájlrendszerre képezi le, miközben a konfigurációs rendszere URI alapú helyeket, átírásokat és proxyszabályokat is alkalmazhat. Az NGINX előbb egy server blokkot, majd egy location blokkot választ, elsősorban a kérés URI-ja alapján, és csak azután dönti el, hogy fájlt szolgál ki vagy továbbadja a kérést.

Ez a különbség azt befolyásolja, hogyan írod a konfigurációt, önmagában viszont nem bizonyítja, hogy az NGINX gyorsabban továbbítja az adatokat.

Gyors összehasonlítás az NGINX és az Apache között

Így állnak a fenti szempontokban a szerverek, kiegészítve a protokolltámogatással és mindkettő aktuális verziójával.

Az Apache és az NGINX együttes használata

Igen, futtathatod mindkettőt. Egy gyakori hibrid elrendezésben az NGINX áll elöl kliens felőli fordított proxyként, az Apache pedig mögötte. Az NGINX le tudja zárni a TLS-t és a HTTP/2-t, a HTTP/3-at pedig akkor, ha a kísérleti HTTP/3 modulja be van fordítva és engedélyezve van. Emellett bizonyos statikus fájlokat maga is kiszolgálhat, az alkalmazáskéréseket meg továbbadja az Apache-nak.

A lényeges kikötés az, hogy kié a szabály. Egy kérés, amelyet az NGINX közvetlenül kiszolgál, sosem jut el az Apache-hoz, így az Apache .htaccess szabályai nem érvényesek rá. A két konfigurációnak egyet kell értenie az átírásokban, a gyorsítótárazásban, a kliens IP továbbadásában, a TLS működésében és abban, melyik szerveré melyik útvonal.

Az ára az, hogy mostantól két webszervert üzemeltetsz. Két konfiguráció, amelyeknek egyezniük kell, két frissítési ciklus, amit követni kell, és egy hellyel több, ahol nézelődni kell, ha egy kérés váratlan választ ad. Egyetlen kis oldalnál ez a teher rendszerint nagyobb, mint a haszon; akkor kezd megtérülni, amikor HTTP/3-at vagy gyorsabb statikus kiszolgálást akarsz úgy, hogy közben megmarad a .htaccess viselkedés, amelyre a bővítményeid építenek.

Egyszerűbb az NGINX az Apache-nál?

Egyik sem egyszerűbb minden helyzetben. Az NGINX akkor, ha jobban szereted az egy helyen tartott konfigurációt, és nem zavar a server blokkok szerkesztése. Az Apache akkor, ha a WordPress vagy külső bővítmények .htaccess szabályokra számítanak, mert ezek könyvtárszinten működnek a globális szerverkonfiguráció módosítása nélkül.

Egy általad felügyelt szerveren az „egyszerűbb” főként azon múlik, melyik konfigurációs modellt várja el eleve a környezeted.

Mikor érdemes Apache-ot választani NGINX helyett?

Az Apache-ot akkor válaszd, ha a WordPress-környezeted .htaccess-re épül, ha a bővítmények vagy a vezérlőpult eszközei Apache-átírási direktívákat várnak, vagy ha egy konkrét Apache-modulra van szükséged. Ésszerű az Apache-nál maradni egy már jól működő oldalon is: webszervert cserélni egy elméleti benchmark-nyereményért ritkán éri meg a felfordulást.

Mikor érdemes NGINX-et választani Apache helyett?

Az NGINX-et akkor válaszd, ha sok egyidejű kapcsolatra számítasz, erős statikus- vagy fordítottproxy-réteget akarsz, a központosított konfigurációt kedveled, vagy nyitva akarod hagyni a HTTP/3 lehetőségét. WordPressnél ennek ára, hogy az átírási szabályok és a bővítményspecifikus szerverdirektívák rendszergazdai feladattá válnak, nem pedig olyasmivé, amit a WordPress beírhat a .htaccess-be.

NGINX vs Apache: Mely webszerver a legjobb a WordPress-hez?

Válaszd az NGINX-et. Egy általad felügyelt szerveren futó WordPress-oldalhoz ez a jobb alapértelmezés: alacsony kapcsolatonkénti terhelés nagy párhuzamosságnál, hatékony statikus kiszolgálás, és HTTP/3, ha kell.

A kivétel a .htaccess, és ez a kivétel sokat nyom. A WordPress tud Apache-átírási szabályokat írni, ha a .htaccess engedélyezett, de az NGINX szerverkonfigurációját nem tudja módosítani. Ha egy bővítmény átírási, biztonsági vagy gyorsítótárazási direktívákat vár, szükséged lesz az NGINX-hez való leírására vagy egy azzal egyenértékű szabályra a server blokkban, majd az NGINX újratöltésére. Ha ezt az üzemeltetői felelősséget nem akarod, a WordPresshez az Apache az egyszerűbb választás. Normál forgalmú oldalon a teljesítményt inkább a PHP, az adatbázis és a gyorsítótárazás fogja korlátozni, mint maga a webszerver.

Mindezek alatt egyetlen feltevés húzódik: a szervernek a tiédnek kell lennie, hogy változtathass rajta. Menedzselt WordPress-tárhelynél a webszerverről a szolgáltató dönt, és a kérdésre a válasz egyszerűen az, amit ő futtat. Ez az összehasonlítás annak szól, akinek root hozzáférése van a saját gépéhez.

Hogyan derítheted ki, hogy Apache vagy NGINX fut nálad?

Ha ez a saját VPS-ed, nézd meg közvetlenül a futó szolgáltatásokat:

systemctl status nginx
systemctl status apache2   # Debian/Ubuntu
systemctl status httpd     # RHEL/Fedora-family systems

Egy távoli oldalnál, amelyet nem te üzemeltetsz, a HTTP-válasz Server fejléce lehet nyom, de nem bizonyíték. Egy fordított proxy vagy CDN a saját szerverszoftverét mutathatja az eredetié helyett, a fejléc pedig el is rejthető vagy átírható.

Apache vagy NGINX üzemeltetése VPS-en

Ha a VPS a tiéd, mindkét szervert egyszerű futtatni. A gépet a teljes WordPress-környezetre méretezd, ne csak az Apache-ra vagy az NGINX-re: a PHP worker-ek, az adatbázis, a gyorsítótárazás, a forgalom és a háttérfeladatok rendszerint több erőforrást esznek, mint maga a webszerver.

Bármelyik szervert választod, a konfiguráció, a frissítések, a TLS, a mentések és a felügyelet a te dolgod. Mindkettő futtatása egy újabb konfigurációt és egy újabb frissítési útvonalat hoz, ezért a hibrid felállást csak akkor használd, ha konkrét okod van rá.

A Cloudzy NGINX VPS-e egy saját kezelésű Linux VPS teljes root hozzáféréssel, így a szerverkonfiguráció a tiéd marad.

A marketplace-ünkben lévő Apache HTTP Server image ugyanígy, egyetlen kattintással települ, így bármelyik szerver, vagy akár mindkettő elindítása nem forráskódból fordítással kezdődik.

OLVASD

Caddy kontra Nginx egy VPS-en: a konfigurációsfájl-összehasonlítás

Gyakran ismételt kérdések

Jobb az Apache az NGINX-nél?

Egyik sem jobb minden helyzetben. Az NGINX általában az erősebb alapértelmezés, ha számít a nagy párhuzamosság, a statikus kiszolgálás, a fordított proxy vagy a HTTP/3. Az Apache többnyire egyszerűbb, ha a WordPress-környezeted .htaccess-re vagy Apache-specifikus modulokra épül.

Miért gyorsabb az NGINX az Apache-nál?

Az NGINX sok kapcsolatot tud kezelni az egyes worker-ek eseményhurkán belül, ami nagy párhuzamosságnál alacsonyan tartja a kapcsolatonkénti terhelést. Az Apache event MPM-je szintén aszinkron módon kezeli a kapcsolatokat, így a különbség kisebb, mint amit a régi prefork-összevetések sugallnak. WordPressnél a PHP, az adatbázis-lekérdezések és a gyorsítótárazás többet nyomhatnak a latban, mint a két webszerver közti eltérés.

Apache-ot vagy NGINX-et használjak WordPresshez?

Saját kezelésű WordPress VPS-en az NGINX erős alapértelmezés, ha nem zavar, hogy a server blokkok szabályait magad kezeled. Az Apache-ot válaszd, ha a .htaccess-re vagy Apache-átírási szabályokat váró bővítményekre támaszkodsz, és azt szeretnéd, hogy ezek kevesebb kézi szerverbeállítással működjenek.

Miért ilyen népszerű az NGINX?

Az NGINX a nagy párhuzamosságnál is hatékony kéréskezelést köti össze a fordított proxyval, a terheléselosztással, a gyorsítótárazással, a FastCGI-támogatással és a TLS lezárásával. Ettől lesz hasznos elsődleges webszerverként és elöl álló proxyként is.

Miért használják még mindig az Apache-ot?

Az Apache továbbra is széles körben használt a modulökoszisztémája, a .htaccess-támogatás, az érett eszközkészlet, a széles platformtámogatás, valamint a köré épült tárhely- és vezérlőpult-munkafolyamatokkal való kompatibilitás miatt.

Mi a különbség az Apache és az apache2 között?

Debianon és Ubuntun az apache2 az Apache HTTP Server csomag- és szolgáltatásneve. A RHEL és Fedora családba tartozó rendszerek ezt a szolgáltatást jellemzően httpd néven futtatják. Nem különböző webszerverekről van szó: mindkettő az Apache HTTP Servert jelenti. Az Apache jelenlegi stabil ága a 2.4, a legutóbbi kiadása pedig a 2.4.68.

Támogatja az Apache a HTTP/3-at?

Natívan nem. Az Apache HTTP Server 2.4 nem hoz HTTP/3- vagy QUIC-modult; a vele szállított protokolltámogatás a HTTP/2-nél véget ér. Ha éles üzemben kell a HTTP/3, lezárhatod egy HTTP/3-képes fordított proxyn vagy CDN-en az Apache előtt.