Nginx is gemaakt om een groot aantal gelijktijdige verbindingen aan te kunnen en heeft zich gevestigd als hoofdwebserver of als reverse proxy voor andere servers. WordPress noemt hem samen met Apache als een van de robuustste servers om het CMS te hosten.
Hoe Nginx werkt
Volgens de documentatie start Nginx een masterproces en meerdere workerprocessen. De master leest en controleert de configuratie en beheert de workers; die verwerken de verzoeken, volgens een event-driven model. In plaats van een proces of thread per verbinding te reserveren, volgt elke worker veel verbindingen tegelijk en reageert hij zodra er één klaar is. Het aantal workers wordt vaak afgestemd op het aantal processorcores.
De configuratie staat in het bestand nginx.conf en de bestanden die het inlaadt. Een wijziging werkt pas na herladen (nginx -s reload): de master controleert de nieuwe configuratie, start nieuwe workers en stopt de oude rustig, of houdt de oude configuratie aan als de nieuwe een fout bevat.
Nginx en PHP
Nginx voert PHP niet zelf uit. Hij geeft de scripts met de directive fastcgi_pass door aan een FastCGI-server, bijna altijd PHP-FPM. De communicatie loopt via een Unix-socket of een lokale poort; de PHP-documentatie waarschuwt dat een FastCGI-eindpunt dat open staat naar het netwerk het uitvoeren van willekeurige code mogelijk maakt, vandaar de voorkeur voor een socket als alles op dezelfde machine draait.
Geen .htaccess
Dit is het verschil dat het meest verrast als je van Apache komt: de documentatie van WordPress benadrukt dat Nginx geen configuratiebestand per map heeft zoals de .htaccess. Alles wordt op serverniveau ingesteld, en WordPress kan zijn rewrite-regels niet zelf schrijven. Voor de permalinks is deze regel essentieel:
location / {
try_files $uri $uri/ /index.php?$args;
}Hij levert het opgevraagde bestand of de opgevraagde map als die bestaat, en geeft het verzoek anders door aan index.php, met behoud van de URL-parameters. Zonder deze regel geven aangepaste permalinks 404-fouten.
Voor WordPress
- Regels van plugins worden niet vanzelf toegepast: een plugin die in de .htaccess schrijft (cache, beveiliging, redirects), heeft op Nginx geen enkel effect. Je moet de regels naar de configuratie overzetten, of de hoster vragen dat te doen.
- Bescherm het beheer en gevoelige bestanden met
location-blokken, zoals onze gids laat zien om wp-admin op serverniveau te beschermen. - Achter een CDN of proxy stel je de module real_ip in om het adres van de bezoeker terug te krijgen; zie Cloudflare voor WordPress.
- Herlaad na elke wijziging en test de configuratie eerst met
nginx -t.
WP Masquerade werkt op Nginx zonder serverregels, met twee uitzonderingen: de bestandsaliassen van de Pro-versie, waarvoor de plugin het blok genereert dat je kopieert, en één regel die de map van de plugin verbergt, zoals de pagina compatibiliteit met hosters en caches uitlegt.
Veelgemaakte fouten
Beveiligingen in een .htaccess zetten op een Nginx-server en denken dat de site beschermd is; PHP-FPM laten luisteren op een adres dat vanaf internet bereikbaar is; ?$args vergeten in try_files, waardoor adressen met parameters niet meer werken. Veel hosters zetten Nginx ook vóór Apache: in dat geval werkt de .htaccess weer voor de verzoeken die naar Apache worden doorgestuurd.