“We verhuizen naar Nginx” komt in elke audit naar voren – soms met een goede reden, soms omdat een blog uit 2014 dat zegt. De gedeelde Apache host echter nog steeds duizenden WordPress zonder nood dankzij .htaccess. En moderne stacks draaien nginx vóór Apache, juist omdat niemand de regels heeft gemigreerd.
Nginx en Apache zijn geen twee religies. Dit zijn twee punten in het zoekpad met verschillende sterktes. Het kiezen van “het beste” zonder HTTP → PHP → statisch → cache in kaart te brengen, is het optimaliseren van de verkeerde fase.
Breng het pad van een verzoek in kaart
Voordat u benchmarks gaat vergelijken, moet u in kaart brengen wat er gebeurt als een bezoeker een pagina laadt. Gaat het verzoek eerst via een CDN? Levert de webserver statische bestanden rechtstreeks aan, of wordt alles teruggestuurd naar PHP? Wie kan de herschrijfregels wijzigen: het technische team of de klant via .htaccess?
| Stap | nginx-rol | Apache-rol |
|---|---|---|
| TLS-beëindiging | Geweldig | Correct (mod_ssl) |
| Statische bestanden | Zeer snel (verzendbestand) | Juist |
| Omgekeerde proxy-app | Inheems, lichtgewicht | mod_proxy |
| URL herschrijven | try_files, kaarten | .htaccess, mod_rewrite |
| PHP | Via PHP-FPM upstream | PHP-FPM of mod_php |
| Basisdirectoryverificatie | auth_basic | .htaccess AuthType |
De nuttige vraag: hoeveel verkeer bereikt de webserver vóór PHP — en wie zou de regels moeten kunnen veranderen zonder opnieuw te implementeren?
Concrete scenario's: drie typische profielen
Scenario A — SaaS PHP-FPM, API + SPA
Ongeveer zeventig procent van de activa loopt via een CDN. Geen .htaccess-client. Snelheidsbeperking en WebSocket-proxy nodig. Nginx alleen (of nginx + CDN) is voldoende; Apache brengt niets doorslaggevends.
Scenario B — WordPress multi-client gedeelde hosting
.htaccess-regels per site, plug-ins die herschrijfregels schrijven, historische mod_php-ondersteuning. Apache blijft de logische keuze – of nginx met handmatige conversie van regels, wat migratiekosten met zich meebrengt die vaak worden onderschat.
Scenario C — Geleidelijke overgang
Verouderde Apache + nieuwe Node-applicatie. Nginx front-end → Apache (poort 8080) + Node (poort 3000) per locatie blok. Gemeenschappelijke architectuur als u niet alles in één keer kunt migreren.
Prestaties: wat benchmarks vergeten
Nginx overwint gelijktijdige verbindingen en statische bestanden. Apache met mpm_event + PHP-FPM blijft concurrerend voor gematigde dynamische PHP. Het knelpunt is vaak PHP en MySQL, niet de webserver zelf.
Meten vóór de migratie: TTFB-oorsprong met en zonder cache, aandeel statische 304/200-reacties rechtstreeks geleverd door nginx, geheugenkosten van mod_php versus PHP-FPM. Een verandering van webserver zonder deze cijfers betekent soms wekenlange migratie voor een winst van vijf procent – terwijl een ontbrekende SQL-index vijftig procent waard is.
Gedeelde hosting, VPS of PaaS
Op shared worden Apache en .htaccess vaak opgelegd; nginx blijft zelden configureerbaar. Op VPS is de keuze vrij: nginx + PHP-FPM wordt aanbevolen voor een nieuw project zonder .htaccess-schuld. Op PaaS verbergt een abstractielaag (Caddy, Traefik) de webserver – u hoeft niet echt meer te kiezen.
Op VPS installeer je slechts één frontend tenzij gedocumenteerde hybride architectuur – vermijd nginx + Apache zonder reden (dubbele TLS-configuratie, dubbel foutoppervlak).
Specifiek voor WordPress maakt de vergelijking Apache of nginx voor WordPress deze lezing compleet. Voor een lichtere stapel, zie ook Nginx ou Caddy.
De top: reputatie vervangt zelden de query-inventaris
Het veranderen van webservers zonder profilering betekent soms weken migratie voor vijf procent winst – terwijl een database-index vijftig procent waard is.
Beslis en ga vooruit zonder blinde vlek
Ruim een halve dag kun je beslissen zonder blinde vlek. Traceer tien typische verzoeken (home, API, admin, asset). Maak een lijst van de vereiste .htaccess-afhankelijkheden en Apache-modules. Meet de TTFB om te controleren of de webserver echt de bottleneck is. Als u voor nginx kiest, plan dan regelconversie en test 301-omleidingen. Als je de twee combineert, zou nginx alleen als proxy moeten dienen: één eigenaar van de configuratie.
Zie Apache of nginx voor WordPress en Nginx of Caddy. Om de onderliggende hosting te kiezen, bladert u door de overzicht en de vergelijker.
Veelgestelde vragen
Vervangt Nginx nog steeds Apache?
Nee. Nginx is vaak beter aan de voorkant (TLS, cache, reverse proxy). Apache blijft relevant als je afhankelijk bent van .htaccess per map, oudere mod_php of modules zonder een nginx-equivalent. De juiste keuze lees je af in je stack, niet in de reputatie van het logo.
Welke combinatie voor moderne PHP?
Nginx + PHP-FPM is de huidige standaard. Apache + PHP-FPM werken ook. Vermijd mod_php op een drukke productie: werknemers combineren webbelasting en PHP-belasting, wat de dimensionering bemoeilijkt.
Kunnen we beide gebruiken?
Ja. Nginx als een reverse proxy voor Apache of voor Node/Python-applicaties is een veel voorkomende architectuur bij progressieve migratie. Het belangrijkste is om te documenteren wie TLS beëindigt en waar de herschrijfregels gelden.
Hoe beslis je in 30 minuten?
Vermeld het percentage statisch verkeer, de .htaccess-vereiste, de vereiste modules en de teamvaardigheid. Als tachtig procent statisch/CDN + PHP-FPM → nginx front-end. Als tientallen .htaccess-regels client → Apache- of nginx-migratiebudget.
Nginx of Apache wordt gekozen op het verzoekpad – niet op het logo van de dia-architectuur.