NGINX vs. Apache: zo kies je de beste webserver

Stel je voor: je zoekt nieuwe sneakers, je vindt een goede deal en besluit die op de website te bekijken.

Je wacht 10 seconden… 20 seconden… en de site wil maar niet laden. Je bent het wachten zat, dus je gaat naar een andere site. Wat er waarschijnlijk is gebeurd: de sneakerwebsite heeft veel tijd en geld gestoken in flitsende afbeeldingen en een strak ontwerp, maar dat is allemaal voor niets als het eeuwig duurt voordat de site laadt.

Kort samengevat: kies NGINX voor sites met veel verkeer, veel statische content of servers met beperkt geheugen. Dankzij de eventgestuurde architectuur verwerkt het duizenden verbindingen met minimaal geheugen. Kies Apache als je .htaccess-bestanden, de enorme modulebibliotheek of ingebouwde interpreters zoals mod_php nodig hebt. Je kunt NGINX ook als reverse proxy vóór Apache draaien en zo het beste van beide combineren.

Het internet staat vol met trage websites.

Uit benchmarkonderzoek van Google uit 2017 bleek dat een gemiddelde mobiele landingspagina 22 seconden nodig had om volledig te laden. Pagina's zijn sindsdien sneller geworden, maar een trage site is nog steeds funest voor je bedrijf.

Uit een onderzoek van Portent bleek dat een site die in minder dan een seconde laadt een drie keer hogere conversieratio heeft dan een site die vijf seconden nodig heeft om te laden.

Wat heeft dit nu te maken met onze vergelijking tussen NGINX en Apache?

Een belangrijke factor voor de snelheid van je site is je webserver: de software die je pagina's aan bezoekers levert.

Apache en NGINX zijn twee van de bekendste webservers die er zijn.

Volgens W3Techs draait NGINX per juli 2026 op 31,5% van alle websites waarvan de webserver bekend is, tegenover 23,1% voor Apache.

Is NGINX daarmee de duidelijke winnaar? Nog niet helemaal.

Beide webservers werken anders en passen bij verschillende toepassingen. In deze gids bekijken we de verschillen tussen Apache en NGINX en leggen we uit waar je op moet letten bij het kiezen van een server.

Laten we beginnen.

Wat zijn webservers?

Webservers zijn softwaretoepassingen die op een fysieke server draaien en binnenkomende verzoeken van gebruikers afhandelen.

Als je een URL zoals google.com, intypt, stuurt je browser een verzoek naar de webserver, waarop de bestanden staan die nodig zijn om de website te laten draaien.

De server stuurt vervolgens de juiste content terug, of dat nu HTML, CSS, JavaScript, afbeeldingen of iets anders is.

Webservers voeren achter de schermen veel belangrijke taken uit:

• HTTP-verbindingen en -verzoeken beheren
• Verzoeken waar nodig doorsturen naar de juiste backendapplicatie (zoals PHP, Python of Ruby on Rails)
• Bestanden van de schijf lezen en ernaar schrijven om statische bestanden te serveren
• Beveiligingsbeleid afdwingen
• Content comprimeren voor snellere overdracht
• Verzoeken loggen voor analyse

Nu we hebben besproken hoe webservers werken, bekijken we hoe NGINX en Apache deze taken aanpakken.

Wat is Apache?

Apache HTTP Server, meestal gewoon Apache genoemd, is populaire opensource webserversoftware die is ontwikkeld door de Apache Group en in 1995 voor het eerst verscheen. Het is gebaseerd op de NCSA HTTPd-server van Rob McCool.

De Apache Software Foundation, een non-profitorganisatie die in 1999 werd opgericht door leden van de oorspronkelijke Apache Group, onderhoudt en ondersteunt het project vandaag de dag.

Jarenlang was Apache de meestgebruikte webserver ter wereld, waarop talloze websites draaiden. Het speelde zelfs een belangrijke rol in de groei van het World Wide Web in de begintijd.

Enkele belangrijke functies en voordelen van Apache:

• Modulaire architectuur: de functionaliteit is uit te breiden met modules voor verschillende functies en talen.
• Werkt op verschillende besturingssystemen: Apache is platformonafhankelijk, zodat je je webserver op elk besturingssysteem kunt hosten, waaronder Linux, Windows en macOS.
• Uitgebreide documentatie en een grote community: helpt gebruikers en ontwikkelaars om samen problemen op te lossen en betere oplossingen te ontwikkelen.
• Flexibele configuratie: met .htaccess-bestanden kunnen gebruikers de configuratie per map aanpassen.
• Beveiligingsfuncties: Apache is redelijk goed beveiligd dankzij het opensource karakter en regelmatige updates die kwetsbaarheden en bugs verhelpen.

Toch heeft Apache ook een paar beperkingen:

• Hoger geheugengebruik: het gebruikt meer geheugen dan NGINX, vooral bij veel gelijktijdige verbindingen.
• Trager bij zware belasting: het kan trager zijn dan NGINX bij het serveren van statische bestanden, vooral onder zware belasting.
• Lastig te ontwikkelen en te onderhouden: door de groeiende complexiteit van de codebase is het in de loop der jaren lastiger geworden om eraan te bouwen en het te onderhouden.

Wat is NGINX?

NGINX (uitgesproken als Engine X) is gratis, opensource en krachtige webserversoftware die in 2004 voor het eerst verscheen. Het werd gemaakt door Igor Sysoev, een Russische software-engineer, om het probleem op te lossen van grote aantallen gebruikers die tegelijk een website bezoeken, iets waar andere webservers zoals Apache moeite mee hadden.

Sysoev begon in 2002 aan NGINX te werken. Hij wilde het C10k-probleem aanpakken: 10.000 gelijktijdige verbindingen afhandelen.

Zijn doel was een snelle, stabiele en schaalbare server. Door die focus op prestaties is NGINX uitzonderlijk goed in het serveren van statische content zoals HTML-pagina's, afbeeldingen en CSS-bestanden.

Naast snelheid blinkt NGINX uit als reverse proxy. Het ontvangt verzoeken van gebruikers en stuurt ze slim door naar andere servers, zoals Apache of webapplicaties, zodat resources optimaal worden benut.

Enkele belangrijke voordelen van NGINX:

• Gelijktijdige verwerking: NGINX bedient veel gebruikers tegelijk zonder buitensporig veel geheugen of CPU-kracht te vragen.
• Eenvoudig in te stellen en te configureren: NGINX heeft een eenvoudig en intuïtief formaat voor configuratiebestanden, zodat je de webserver gemakkelijk afstemt op jouw toepassing.
• Diverse prestatiefuncties: NGINX heeft veel ingebouwde functies voor load balancing, caching en het beveiligen van websites met SSL/TLS-versleuteling.
• Ondersteunt IMAP en POP3: NGINX werkt zelfs als mailproxyserver en ondersteunt protocollen zoals IMAP en POP3.

NGINX heeft echter ook een paar nadelen:

• Standaardinstellingen zijn niet optimaal: de standaardalgoritmen voor load balancing presteren niet in elke situatie optimaal.
• Geen ingebouwde taalcompilers: het biedt geen native ondersteuning voor het genereren van dynamische websites met server-side talen zoals PHP of Python. Je kunt dit wel omzeilen met een extensie van derden.

NGINX vs. Apache: wat zijn de verschillen?

Het kernverschil: Apache verwerkt elke verbinding met een eigen proces of thread, beheerd door de Multi-Processing Modules, terwijl NGINX een asynchroon, eventgestuurd model gebruikt waarin elk workerproces duizenden verbindingen tegelijk afhandelt. Daarom kan NGINX veel gelijktijdige verbindingen aan met minder geheugen, en daarom biedt Apache .htaccess-configuratie per map en ingebouwde interpreters voor programmeertalen.

Apache was ooit de populairste keuze als webserver. NGINX veroverde echter snel marktaandeel en is nu populair bij veel websites met veel verkeer.

Ben je van plan om met dedicated hosting te werken, dan is de keuze voor de juiste webserver een belangrijke beslissing.

Wat onderscheidt deze twee dan van elkaar?

Laten we ze eens nader bekijken.

Architectuur en gelijktijdigheid

Een van de grootste verschillen tussen NGINX en Apache is hoe ze binnenkomende verzoeken achter de schermen afhandelen.

Dat heeft een grote invloed op hun prestaties en op hoe efficiënt ze met resources omgaan.

De procesgebaseerde architectuur van Apache

Apache volgt een procesgebaseerd model en start voor elk binnenkomend verzoek een nieuwe thread of een nieuw proces.

Deze processen of threads worden beheerd door Multi-Processing Modules (MPM's):

• Prefork MPM: het oorspronkelijke model van Apache. Elk proces heeft één thread en verwerkt één verbinding tegelijk. Het is eenvoudig, maar kan veel geheugen gebruiken.
• Worker MPM: gebruikt meerdere threads per proces, die elk één verbinding afhandelen. Dit is zuiniger met geheugen dan prefork, maar veel verkeer en zware verzoeken kunnen de CPU nog steeds overbelasten, met prestatieproblemen als gevolg.
• Event MPM: vergelijkbaar met de worker MPM, maar geoptimaliseerd voor keep-alive-verbindingen (verbindingen die een browser tussen verzoeken openhoudt). Toch is het nog steeds niet volledig asynchroon.

Dit zijn allemaal goede modules, maar ze hebben één groot nadeel: Apache moet voor elke binnenkomende verbinding nieuwe processen of threads aanmaken en die daarna weer opruimen. Apache probeert dit op te vangen door vooraf een aantal inactieve processen klaar te zetten.

Maar als veel mensen tegelijk verbinding willen maken met de site, kan Apache zijn bestaande pool overschrijden en moet het snel extra processen aanmaken. Dat kost tijd en vreet geheugen.

Dit model werkt prima voor sites met weinig tot gemiddeld verkeer. Toch kan Apache het zwaar krijgen bij veel gelijktijdige verbindingen.

Al die afzonderlijke processen zijn niet bepaald efficiënt. Zelfs met de event MPM ontkomt Apache niet helemaal aan het model van één thread per verbinding.

De gebeurtenisgestuurde architectuur van NGINX

NGINX pakt het heel anders aan. In plaats van aparte processen of threads voor elke verbinding gebruikt NGINX een asynchrone, eventgestuurde architectuur.

Zo werkt het:

• NGINX heeft één masterproces dat meerdere workerprocessen beheert (meestal één worker per CPU-kern). Elke worker kan duizenden gelijktijdige verbindingen aan. Workers hoeven geen nieuwe threads te starten of elk verzoek naar een eigen proces door te sturen.
• In plaats daarvan hebben de workers een eventloop. Daarmee houden ze met mechanismen van het besturingssysteem, zoals kqueue of epoll, efficiënt in de gaten of er nieuwe events zijn op bestaande verbindingen. Zo kunnen ze binnen één thread met meerdere verbindingen tegelijk jongleren. Gebeurt er iets, zoals een nieuw binnenkomend verzoek of een reactie van een backendserver, dan stuurt NGINX dat snel door naar een vrije plek in de worker.
• Dit is veel efficiënter dan het model van Apache. NGINX kan enorm veel verzoeken afhandelen met heel weinig geheugen. Het schaalt ongelooflijk goed, en daarom draaien veel van de drukste sites op het web erop.

Het nadeel is dat NGINX geen code-interpreters kan inbouwen zoals Apache dat doet.

Als je PHP- of Python-code wilt uitvoeren, stuurt NGINX verzoeken door naar een aparte FastCGI-procesmanager zoals php-fpm. Dat proces voert de code uit en zet die om in iets wat de browser van de gebruiker begrijpt.

Apache kan daarentegen talen als PHP, Perl en Python binnen zijn eigen processen uitvoeren.

Omdat NGINX dat niet kan, kan het configuratiebestand iets complexer worden.

De prestatiewinst weegt meestal wel op tegen het extra gedoe.

Prestaties

NGINX staat bekend om zijn uitstekende prestaties bij het serveren van statische bestanden zoals HTML-pagina's, afbeeldingen, CSS en JavaScript.

De eventgestuurde architectuur helpt daarbij, maar NGINX heeft nog meer trucs achter de hand.

Ten eerste hoeft NGINX, anders dan Apache, niet voor elk verzoek via de cache naar de schijf te gaan. Het kan bestanden rechtstreeks van de schijf serveren. Daarnaast schrapt NGINX de overhead van het controleren van rechten en het vergrendelen van bestanden.

Het model van Apache, waarin elke verbinding een eigen proces of thread krijgt, brengt per verzoek simpelweg meer overhead met zich mee dan de eventloop van NGINX.

Kleinere websites merken dit knelpunt niet, omdat alles achter de schermen zo snel wordt verwerkt. Maar een grote site met een paar duizend verzoeken per seconde gaat merken dat deze problemen de gebruikerservaring vertragen.

NGINX heeft ook een ingebouwde bestandscache. Die slaat open bestandsdescriptors en metadata van bestanden op in plaats van de inhoud, waardoor de schijfbelasting per verzoek daalt. NGINX controleert gecachete items opnieuw met een instelbaar interval, zodat wijzigingen op de schijf kort daarna worden opgepikt.

Deze optimalisaties tellen op. NGINX serveert statische bestanden doorgaans aanzienlijk sneller dan een standaardinstallatie van Apache, en het verschil wordt groter naarmate het aantal gelijktijdige verzoeken toeneemt.

Een bonus: dit kan je ook helpen je Core Web Vitals te verbeteren, wat je een extra zetje geeft in Google.

Apache is overigens ook niet traag. Je moet er alleen tijd in steken om het goed af te stellen. Ook Apache kan statische bestanden heel snel serveren.

Maar wil je een snelle webserver die meteen goed presteert, dan is NGINX de beste keuze.

Configuratie en syntaxis

NGINX en Apache hebben een verschillende visie op configuratie.

Apache staat bekend om zijn uitgebreide configuratiemogelijkheden. Naast apache2.conf voeg je je regels en configuraties toe aan het bestand .htaccess.

De configuratiebestanden gebruiken een XML-achtige syntaxis en bieden ongelooflijk veel flexibiliteit. Apache heeft een enorme lijst directieven waarmee je elk aspect van het gedrag van de server kunt bijstellen.

Je kunt configuratieopties globaal instellen of ze overschrijven voor specifieke mappen of virtuele hosts.

De echte kracht van Apache zit in het uitgebreide ecosysteem van modules. Met een enorm aanbod aan officiële modules en modules van derden kun je van alles, van URL's herschrijven tot beveiligingsfilters en geavanceerde caching. Om een module te gebruiken, laad je die in je Apache-configuratie.

De keerzijde is dat de configuratie van Apache snel complex kan worden, vooral bij uitgebreide opstellingen. Directieven kunnen elkaar overschrijven in lastige overervingsketens. Configuratieopties zijn vaak verspreid over meerdere bestanden in verschillende submappen van de hoofdmap config. Het is superflexibel, maar het kost tijd om het onder de knie te krijgen.

De configuratie van NGINX draait daarentegen om eenvoud en leesbaarheid. Een bestand .htaccess is er hier niet. Je configureert de sites gewoon in je nginx.conf en de map sites-enabled, en je bent klaar.

De syntaxis leent zijn stijl van gangbare programmeertalen. Hij is nog steeds krachtig, maar minder uitgebreid dan die van Apache.

In plaats van modules heeft NGINX een kleinere set kerndirectieven en functies die standaard zijn ingebouwd. Alle opties voor een bepaalde functie staan meestal samen in één blok (tussen accolades { }).

Sommige geavanceerde functies, zoals loadbalancing en caching, configureer je in het hoofdbestand nginx.conf en niet in aparte bestanden.

Het resultaat: configuratiebestanden van NGINX zijn doorgaans compacter en makkelijker te lezen en te configureren dan de omvangrijke bestanden van Apache, terwijl je er nog steeds veel mee kunt. En stap je over van de ene naar de andere, dan kunnen AI-assistenten als startpunt serverblokken voor nginx.conf opstellen of herschrijfregels uit .htaccess omzetten naar NGINX-syntaxis. Test het resultaat wel voordat je het in gebruik neemt.

Beveiliging

NGINX en Apache zijn opensourceprojecten met grote, actieve community's van ontwikkelaars die voortdurend werken aan het opsporen en dichten van kwetsbaarheden. Beide krijgen regelmatig beveiligingsupdates en staan erom bekend problemen snel aan te pakken.

Toch zijn er enkele verschillen in hoe ze met beveiliging omgaan.

Een paar belangrijke punten om rekening mee te houden:

• Modulariteit: dankzij de modulaire architectuur van Apache schakel je alleen de functies in die je gebruikt, waardoor het aanvalsoppervlak klein blijft. Bij NGINX zijn veel standaardfuncties direct in de kern ingebouwd, wat het volgens sommigen minder flexibel maakt op het gebied van beveiliging.
• Filteren van verzoeken: NGINX heeft een krachtige ingebouwde filterengine voor verzoeken die kan helpen veelvoorkomende webaanvallen te blokkeren, zoals SQL-injectie en cross-site scripting (XSS). Apache biedt vergelijkbare mogelijkheden via modules zoals mod_security.
• SSL/TLS-configuratie: beide servers ondersteunen SSL/TLS voor versleutelde verbindingen, maar NGINX zou makkelijker te configureren zijn. Het heeft duidelijkere documentatie en standaard veiligere instellingen.
• Procesisolatie: doordat NGINX één masterproces met meerdere workerprocessen gebruikt, kunnen probleemgebieden beter worden geïsoleerd. De MPM-varianten prefork en worker van Apache bieden vergelijkbare isolatie op procesniveau, maar verbruiken daarvoor meer resources.
• DDoS-bescherming: dankzij de eventgestuurde architectuur van NGINX en de efficiënte afhandeling van gelijktijdige verbindingen is het een populaire keuze om kleine tot middelgrote DDoS-aanvallen af te slaan. Met een paar extra modules en wat afstemming kun je ook Apache bestand maken tegen DDoS-aanvallen.

Dynamische content, modules en ecosysteem

Apache is al lang de favoriet voor het serveren van dynamische content, omdat het talen aan de serverkant makkelijk integreert. Met de MPM-varianten prefork en worker kun je ondersteuning voor talen als PHP, Python en Perl direct in de binary van Apache compileren.

Apache draait vervolgens een interpreter binnen elk van zijn workerprocessen. Dat is lekker eenvoudig: Apache kan verzoeken voor .php-bestanden doorgeven aan de ingebouwde PHP-interpreter en krijgt de gerenderde uitvoer terug.

NGINX heeft geen ingebouwde ondersteuning voor server-side talen. Wil je PHP, Python of Ruby on Rails met NGINX draaien, dan heb je een aparte service nodig zoals php-fpm, die de interpreter van de taal uitvoert. NGINX ontvangt verzoeken en stuurt ze als proxy door naar de backend, die de code verwerkt en een antwoord terugstuurt.

Dat vraagt iets meer installatiewerk dan de alles-in-één-aanpak van Apache. Aan de andere kant past het bij de filosofie van NGINX: één ding doen (verzoeken afhandelen) en dat goed doen.

Wat andere functies betreft, levert NGINX een compacte kern van nuttige functies, zoals loadbalancing, proxyfunctionaliteit, caching, snelheidsbeperking, compressie en SSL-terminatie. Maar aan de enorme breedte van het module-ecosysteem van Apache kan het niet tippen. Bij Apache heb je modules voor authenticatiemethoden, contentfiltering, ingebedde scripttalen en nog veel meer.

Niet al deze functies zijn uniek. NGINX kan veel van dezelfde taken uitvoeren, alleen op een andere manier. Toch is de modulebibliotheek van Apache behoorlijk uitgebreid.

Heb je een heel specifieke functie nodig, dan heeft Apache hier misschien een streepje voor.

Toch is de functieset van NGINX ruim voldoende voor de meeste gangbare webservertaken.

Gebruik in de praktijk, prestaties en community

De populariteit van NGINX is het afgelopen decennium gestegen.

Volgens W3Techs draait in juli 2026 31,5% van alle websites waarvan de server bekend is op NGINX, tegenover 23,1% op Apache.

Houd er wel rekening mee: je merkt het verschil tussen deze webservers pas als je een grote website hebt of een heel kleine server.

Misschien houd je van de uitgebreide configuratiemogelijkheden van Apache en de alles-in-één-aanpak voor dynamische content. De documentatie van Apache is een van de beste, en de community is enorm als je ooit hulp nodig hebt.

NGINX is misschien beter als je maximale gelijktijdigheid nastreeft of een enorme site bouwt. De architectuur is iets toekomstbestendiger en gebouwd om op te schalen. En de NGINX-community is snel gegroeid. Ook de documentatie is degelijk: je vindt genoeg handleidingen en ondersteuning.

NGINX vs. Apache: wat is beter voor WordPress?

WordPress draait goed op beide. De officiële hostingvereisten van WordPress.org raden zowel Apache als NGINX aan, dus compatibiliteit is het probleem niet: het draait echt om prestaties en configuratie.

Op Apache schrijft WordPress de herschrijfregels voor nette permalinks automatisch naar .htaccess. Beheer je je eigen server, dan is dat de weg van de minste weerstand.

NGINX leest .htaccess helemaal niet. Volgens de NGINX-handleiding van WordPress.org zet je herschrijfregels in plaats daarvan in de serverconfiguratie, en draait PHP via een aparte php-fpm-dienst. Dat vraagt iets meer installatiewerk, maar NGINX met php-fpm is de gangbare krachtige stack voor WordPress.

Het is ook wat veel beheerde WordPress-hosts gebruiken: DreamPress, de beheerde WordPress-hosting van DreamHost, draait elk abonnement op NGINX met ingebouwde servercaching. Zo krijg je de prestaties zonder ook maar één configuratiebestand aan te raken.

Kort gezegd: draait je site op .htaccess-regels of wil je de eenvoudigste zelfbeheerde opstelling, kies dan Apache. Wil je optimale snelheid bij veel verkeer, of zit je op beheerde WordPress-hosting, dan ben je waarschijnlijk beter af met NGINX (of gebruik je het al).

NGINX vs. Apache: welke past bij jou?

Kies NGINX voor implementaties met veel verkeer, veel statische content of weinig geheugen. Kies Apache als je .htaccess, mod_php of de modulebibliotheek nodig hebt. En heb je de sterke punten van allebei nodig, draai ze dan samen, met NGINX als reverse proxy vóór Apache. Zo zien die vuistregels er in detail uit:

NGINX is beter als:

• Je een site met heel veel verkeer hebt.
• Je snel een enorme hoeveelheid statische bestanden moet serveren.
• Je een microservicesarchitectuur bouwt.
• Je de voorkeur geeft aan een overzichtelijkere configuratiestijl.
• Je containers of VPS-hosting gebruikt, waar elke megabyte geheugen telt.

Apache is beter als:

• Je volledige compatibiliteit nodig hebt met functies die alleen Apache heeft, zoals .htaccess.
• Je modules wilt voor heel specifieke functionaliteit.
• Je oudere webapps moet draaien die zijn gebouwd voor Apache en mod_php.
• Je gewoon erg gesteld bent op het configuratiesysteem van Apache.
• Je server vooral een ontwikkelmachine is en prestaties minder belangrijk zijn.

Nergens staat dat je er één moet kiezen.

NGINX als reverse proxy vóór Apache draaien is heel gebruikelijk. Zo combineer je de ongeëvenaarde snelheid van NGINX bij statische bestanden en gelijktijdige verwerking met de uitgebreide ondersteuning van Apache voor dynamische talen op de backend: het beste van twee werelden.

Veelgestelde vragen over NGINX vs. Apache

Tot slot

Apache en NGINX zijn allebei uitstekend, dus je keuze hangt vooral af van wat het best bij jouw behoeften past.

Onthoud: zelfs de krachtigste webserver is maar één radertje in het geheel. Voelt je site traag aan, dan hoeft de webserversoftware of hardware dus niet per se het eerste te zijn wat je optimaliseert.

Slimmere caching, een goed afgestelde database, geoptimaliseerde code en degelijke hardware kunnen je stack allemaal meer versnellen dan urenlang sleutelen aan NGINX of Apache.

Wil je een server om mee te experimenteren? Probeer dan de VPS van DreamHost. Met een VPS kies je zelf welke software je installeert, hoe de server op verzoeken reageert en meer. Bovendien kun je dankzij de flexibiliteit van een VPS meerdere websites op één server hosten en de resources naar behoefte over die sites verdelen.

Daarnaast worden alle DreamPress-abonnementen nu met NGINX geleverd.

De enige manier om de ideale configuratie te vinden, is experimenteren. Start een VPS, installeer NGINX en Apache en kijk wat voor jou het beste werkt!