Apache vs. NGINX: welke webserver is het beste voor WordPress?

Als je WordPress op je eigen VPS draait, kunnen Apache en NGINX de site allebei prima serveren, maar ze maken andere afwegingen. NGINX is meestal de betere standaardkeuze bij hoge gelijktijdigheid, het serveren van statische bestanden en optioneel HTTP/3. Apache is makkelijker wanneer je WordPress-stack afhankelijk is van .htaccess of van Apache-specifieke modules.

Deze vergelijking tussen Apache en NGINX richt zich op de verschillen die ertoe doen voor WordPress: architectuur, PHP-afhandeling, configuratie, HTTP/3 en de vraag of beide draaien de extra complexiteit waard is. LiteSpeed en Caddy vallen buiten het bestek.

Kort antwoord: kies voor een zelfbeheerde WordPress-VPS standaard NGINX. Kies Apache als je site of je plug-ins sterk afhangen van .htaccess. Draai beide alleen wanneer je NGINX er echt voor nodig hebt zonder de Apache-compatibiliteit op te geven.

Wat is Apache?

Apache is populaire opensource-webserversoftware die wordt ontwikkeld en onderhouden door de Amerikaanse non-profitorganisatie Apache Software Foundation (ASF). Het staat ook bekend als Apache HTTP Server en HTTPD.

De downloadpagina van Apache vermeldt 2.4.68, uitgebracht in juni 2026, als de huidige stabiele release.

Apache HTTP Server is een modulaire opensourceserver met volwassen ondersteuning voor .htaccess-regels per map, meerdere Multi-Processing Modules (MPM's), reverse proxying, URL-rewriting, TLS en dynamisch geladen modules. Voor WordPress is zijn grootste praktische voordeel configuratiecompatibiliteit, niet pure snelheid.

De Apache-functies die in deze vergelijking het zwaarst wegen zijn de MPM's prefork, worker en event; .htaccess; HTTP/2; reverse proxying en load balancing; FastCGI-ondersteuning; dynamische modules; URL-rewriting; en TLS.

Wat is NGINX?

NGINX ("engine x") is een opensource-webserver, reverse proxy, contentcache, load balancer, TCP/UDP-proxy en mailproxy, oorspronkelijk geschreven door Igor Sysoev. De workerprocessen gebruiken een event-gedreven model dat is ontworpen om veel gelijktijdige verbindingen met weinig overhead per verbinding af te handelen.

De downloadpagina van NGINX lists the 1.30.x stable branch and the 1.31.x mainline branch.

Apache vs. NGINX: de belangrijkste verschillen voor WordPress

Apache en NGINX verschillen het duidelijkst in hoe ze omgaan met verbindingen, configuratie, PHP en protocolondersteuning. Het gedrag van Apache hangt sterk af van de gebruikte MPM, terwijl NGINX event-gedreven workerprocessen inzet.

Apache vs. NGINX: architectuur

Het requestmodel van Apache hangt af van de MPM die je draait. Prefork is procesgebaseerd, terwijl worker en event threads gebruiken. NGINX gebruikt workerprocessen die rond event loops zijn opgebouwd. Daardoor is de bekende vergelijking "procesgestuurd Apache tegenover event-gestuurd NGINX" te simpel voor een actuele Apache 2.4-opstelling.

De event-MPM van Apache kan inactieve keep-alive-verbindingen doorgeven aan zijn listener-thread in plaats van voor elke verbinding een workerthread bezet te houden. NGINX heeft bij zeer grote aantallen gelijktijdige verbindingen doorgaans nog steeds minder overhead per verbinding, maar het architectuurverschil is veel kleiner dan oude vergelijkingen uit het prefork-tijdperk doen vermoeden.

Apache vs. NGINX: prestaties

Het prestatievoordeel van NGINX komt vooral naar voren bij hoge gelijktijdigheid en bij statische bestanden. De event-gedreven workers kunnen veel verbindingen openhouden met relatief weinig overhead per verbinding. De event-MPM van Apache verkleint dat gat aanzienlijk ten opzichte van oudere prefork-configuraties.

Dynamische WordPress-verzoeken zijn een ander verhaal. NGINX stuurt PHP normaal door naar FastCGI, meestal PHP-FPM. Apache kan PHP-FPM ook via FastCGI gebruiken, of PHP via een Apache-module draaien.

Zodra PHP WordPress begint uit te voeren, kunnen plugincode, databasequery's, object- of paginacaching en het aantal PHP-workers zwaarder wegen dan de webserver ervoor. Als een plug-in een stuk of twaalf dure databasequery's per verzoek uitvoert, lost overstappen van Apache naar NGINX het onderliggende probleem niet op.

Apache vs. NGINX: ondersteuning voor HTTP/3 en QUIC

HTTP/3 is de huidige versie van het protocol en loopt over QUIC in plaats van TCP. Of je site het überhaupt kan aanbieden hangt af van de webserver ervoor, en dit is het enige vergelijkingspunt waarop de twee servers niet dicht bij elkaar liggen.

NGINX levert sinds versie 1.25.0 een HTTP/3-module mee. Die wordt niet standaard meegebouwd, en de build heeft de parameter --with-http_v3_module nodig.

De documentatie van de HTTP/3-module van NGINX noemt de module nog steeds "experimental, caveat emptor applies".

Apache 2.4 levert geen native HTTP/3- of QUIC-module mee; de meegeleverde protocolondersteuning houdt op bij mod_http2.

Het praktische gevolg voor een sitebeheerder: een standaardinstallatie van Apache 2.4 biedt geen HTTP/3. In productie blijft de bruikbare optie om HTTP/3 te termineren op een HTTP/3-capabele reverse proxy of CDN vóór Apache. Wil je het protocol toch, dan kun je NGINX voor Apache zetten en NGINX de clientverbindingen laten afhandelen, precies de opstelling die verderop aan bod komt.

Apache vs. NGINX: beveiliging

Apache noch NGINX is categorisch "veiliger". Het zijn allebei volwassen projecten met actief beveiligingsonderhoud, en de veiligheid van een productieomgeving hangt vooral af van patches, ingeschakelde modules, TLS-configuratie, toegangscontrole, rate limits en de applicatie achter de server.

De zinvolle vergelijking gaat over aanvalsoppervlak en configuratie, niet over een absolute winnaar. Schakel modules en endpoints uit die je niet nodig hebt, houd de server gepatcht en hard de WordPress-stack erachter.

Apache vs. NGINX: configuratie

De .htaccess-bestanden per map van Apache werken zodra AllowOverride ze toestaat. Dat is handig voor WordPress, omdat rewrite-regels aangepast kunnen worden zonder de globale serverconfiguratie aan te raken.

Dat gemak heeft een prijs. De eigen documentatie van Apache raadt aan de regels in de hoofdconfiguratie van de server te zetten als je rootrechten hebt: .htaccess-bestanden worden tijdens verzoeken gecontroleerd, en ze inschakelen brengt zowel prestatie- als beveiligingsafwegingen mee.

NGINX heeft geen tegenhanger van .htaccess. De configuratie is centraal, dus WordPress kan geen rewrite-regels op serverniveau voor je schrijven. Permalink-regels en plugin-specifieke serverdirectieven moet een beheerder aan de NGINX-configuratie toevoegen en daarna herladen.

Apache vs. NGINX: modules en uitbreidbaarheid

Apache heeft volwassen ondersteuning voor Dynamic Shared Objects (DSO): modules kunnen apart worden gecompileerd en via LoadModule worden geladen. NGINX ondersteunt dynamisch geladen modules ook, via load_module, maar binaire compatibiliteit met de geïnstalleerde NGINX-versie en de buildconfiguratie weegt zwaarder zodra je niet-standaard modules van derden gebruikt.

Apache heeft dus een streepje voor als je afhankelijk bent van ongebruikelijke modules van derden. Voor gangbare WordPress-hosting weegt dat verschil meestal minder zwaar dan .htaccess, de PHP-afhandeling en je bestaande gereedschap.

Apache vs. NGINX: platformondersteuning

Apache draait op Linux, Windows, macOS en veel Unix-achtige systemen. NGINX is ook beschikbaar op de belangrijkste platformen, maar de native Windows-build kent belangrijke beperkingen. NGINX noemt de Windows-versie nog steeds bèta, zegt dat je geen hoge prestaties of schaalbaarheid moet verwachten, merkt op dat maar één worker echt werk doet en ondersteunt UDP noch QUIC. Voor productie-inzet van NGINX is een Unix-achtig besturingssysteem de praktische keuze.

Apache vs. NGINX: afhandeling van verzoeken

Apache vertaalt de URL van een verzoek normaal gesproken naar het bestandssysteem onder DocumentRoot, terwijl het configuratiesysteem ook URI-gebaseerde locations, rewrites en proxyregels kan toepassen. NGINX kiest eerst een server-blok en daarna een location-blok, vooral op basis van de request-URI, voordat het beslist of het een bestand serveert of het verzoek doorstuurt.

Dat verschil bepaalt hoe je configuratie schrijft, maar het is op zichzelf geen bewijs dat NGINX data sneller overdraagt.

Een snelle vergelijking tussen NGINX en Apache

Zo verhouden de twee servers zich op de bovenstaande punten, plus protocolondersteuning en de huidige versie van elke server.

Apache en NGINX samen gebruiken

Ja, je kunt ze allebei draaien. Een gangbare hybride opzet zet NGINX vooraan als reverse proxy richting de client en Apache erachter. NGINX kan TLS en HTTP/2 termineren, en HTTP/3 zodra de experimentele HTTP/3-module is meegebouwd en ingeschakeld. Het kan ook zelf bepaalde statische bestanden serveren en applicatieverzoeken doorsturen naar Apache.

Het belangrijkste voorbehoud is wie de regels bezit. Een verzoek dat NGINX zelf afhandelt bereikt Apache nooit, dus Apache's .htaccess-regels gelden er niet voor. De twee configuraties moeten het eens zijn over rewrites, caching, het doorgeven van het client-IP, TLS-gedrag en welke server welk pad beheert.

De prijs is dat je nu twee webservers draait. Twee configuraties die op elkaar moeten aansluiten, twee updatecycli om bij te houden, en een extra plek om te kijken als een verzoek iets onverwachts teruggeeft. Op één kleine site weegt die last meestal zwaarder dan het voordeel; het gaat lonen zodra je HTTP/3 of snellere statische levering wilt zonder het .htaccess-gedrag op te geven waar je plug-ins van afhangen.

Is NGINX makkelijker dan Apache?

Geen van beide is universeel makkelijker. NGINX is dat als je één centrale configuratie prettig vindt en geen moeite hebt met het bewerken van server-blokken. Apache is dat wanneer WordPress of plug-ins van derden .htaccess-regels verwachten, want die regels werken op mapniveau zonder de globale serverconfiguratie te veranderen.

Op een server die je zelf beheert komt "makkelijker" vooral neer op welk configuratiemodel je stack al verwacht.

Wanneer kies je Apache boven NGINX?

Kies Apache als je WordPress-stack afhangt van .htaccess, als plug-ins of controlepaneel-tooling Apache-rewrite-directieven verwachten, of als je een specifieke Apache-module nodig hebt. Het is ook verstandig om Apache te laten staan op een bestaande site die al goed draait: van webserver wisselen voor theoretische benchmarkwinst is de verstoring zelden waard.

Wanneer kies je NGINX boven Apache?

Kies NGINX als je veel gelijktijdige verbindingen verwacht, een sterke laag voor statische bestanden of reverse proxying wilt, een centrale configuratie prefereert, of de mogelijkheid wilt hebben om HTTP/3 aan te zetten. Voor WordPress is de keerzijde dat rewrite-regels en plugin-specifieke serverdirectieven een beheerderstaak worden in plaats van iets dat WordPress in .htaccess kan schrijven.

NGINX vs Apache: Welke webserver is het beste voor WordPress?

Draai NGINX. Voor een WordPress-site op een server die je zelf beheert is het de betere standaardkeuze: lage overhead per verbinding bij hoge gelijktijdigheid, efficiënte levering van statische bestanden en HTTP/3 beschikbaar als je dat wilt.

De uitzondering is .htaccess, en die weegt zwaar. WordPress kan Apache-rewrite-regels schrijven als .htaccess aanstaat, maar het kan de serverconfiguratie van NGINX niet aanpassen. Verwacht een plug-in rewrite-, beveiligings- of cachingdirectieven, dan heb je de NGINX-instructies ervan nodig of een gelijkwaardige regel in het server-blok, gevolgd door een herlaad van NGINX. Wil je die operationele verantwoordelijkheid niet, dan is Apache de eenvoudigere WordPress-keuze. Op een site met normaal verkeer beperken PHP, database en caching de prestaties eerder dan de webserver zelf.

Onder dit alles ligt één aanname: de server moet van jou zijn en aanpasbaar. Bij managed WordPress-hosting beslist de host over de webserver, en het antwoord op deze vraag is gewoon wat daar al draait. Deze vergelijking is bedoeld voor iemand met rootrechten op de eigen machine.

Hoe controleer je of je Apache of NGINX draait?

Is dit je eigen VPS, controleer dan direct de draaiende services:

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

Bij een website van iemand anders is de HTTP-responseheader Server hooguit een aanwijzing, geen bewijs. Een reverse proxy of CDN kan zijn eigen serversoftware tonen in plaats van die van de origin, en de header kan ook verborgen of aangepast zijn.

Apache of NGINX hosten op een VPS

Als de VPS van jou is, zijn beide servers eenvoudig te draaien. Dimensioneer de machine voor de hele WordPress-stack, niet alleen voor Apache of NGINX: PHP-workers, de database, caching, verkeer en achtergrondtaken verbruiken doorgaans meer resources dan de webserver zelf.

Welke server je ook kiest, configuratie, updates, TLS, back-ups en monitoring zijn jouw verantwoordelijkheid. Beide draaien voegt een extra configuratie en een extra updatepad toe, dus gebruik de hybride opzet alleen als je er een concrete reden voor hebt.

De NGINX-VPS van Cloudzy is een zelfbeheerde Linux-VPS met volledige rootrechten, dus de serverconfiguratie blijft van jou.

De Apache HTTP Server-image in onze marketplace installeert op dezelfde manier, met één klik, zodat het opzetten van de een, de ander of allebei niet begint met compileren vanaf de broncode.

LEES

Caddy vs Nginx op een VPS: de vergelijking van configuratiebestanden

Veelgestelde vragen

Is Apache beter dan NGINX?

Geen van beide is universeel beter. NGINX is meestal de sterkere standaardkeuze als je hecht aan hoge gelijktijdigheid, statische levering, reverse proxying of HTTP/3. Apache is meestal makkelijker als je WordPress-stack afhangt van .htaccess of Apache-specifieke modules.

Waarom is NGINX sneller dan Apache?

NGINX kan veel verbindingen binnen de event loop van elke worker afhandelen, waardoor de overhead per verbinding laag blijft bij hoge gelijktijdigheid. De event-MPM van Apache handelt verbindingen ook asynchroon af, dus het gat is kleiner dan oude prefork-vergelijkingen doen vermoeden. Bij WordPress kunnen PHP, databasequery's en caching zwaarder wegen dan het verschil tussen de webservers.

Moet ik Apache of NGINX gebruiken voor WordPress?

Voor een zelfbeheerde WordPress-VPS is NGINX een sterke standaardkeuze als je zelf de regels in server-blokken wilt beheren. Kies Apache als je leunt op .htaccess of op plug-ins die Apache-rewrite-regels verwachten en je wilt dat die met minder handmatige serverconfiguratie werken.

Waarom is NGINX zo populair?

NGINX combineert efficiënte verwerking van verzoeken bij hoge gelijktijdigheid met reverse proxying, load balancing, caching, FastCGI-ondersteuning en TLS-terminatie. Daardoor is het bruikbaar als primaire webserver én als frontproxy.

Waarom wordt Apache nog steeds gebruikt?

Apache wordt nog steeds veel gebruikt vanwege het module-ecosysteem, de .htaccess-ondersteuning, volwassen gereedschap, brede platformondersteuning en de compatibiliteit met hosting- en controlepaneelworkflows die eromheen zijn gebouwd.

Wat is het verschil tussen Apache en apache2?

Op Debian en Ubuntu is apache2 de pakket- en servicenaam van Apache HTTP Server. Systemen uit de RHEL- en Fedora-familie noemen die service meestal httpd. Het zijn geen verschillende webservers: beide verwijzen naar Apache HTTP Server. De huidige stabiele Apache-tak is 2.4, met 2.4.68 als nieuwste versie.

Ondersteunt Apache HTTP/3?

Niet native. Apache HTTP Server 2.4 levert geen HTTP/3- of QUIC-module mee; de meegeleverde protocolondersteuning houdt op bij HTTP/2. Heb je HTTP/3 nodig in productie, dan kun je het termineren op een HTTP/3-capabele reverse proxy of CDN vóór Apache.