nginx.conf

Waar Apache zijn configuratie verspreidt over .htaccess-bestanden in de mappen van de site, centraliseert Nginx alles. Volgens de documentatie heet het bestand nginx.conf en staat het in /etc/nginx, /usr/local/nginx/conf of /usr/local/etc/nginx. Het laadt vaak andere bestanden in, één per site, die afhankelijk van de distributie in conf.d/ of sites-available/ staan.

Hoe nginx.conf is opgebouwd

Het bestand bestaat uit directives. Een eenvoudige directive eindigt op een puntkomma; een blokdirective bevat andere directives tussen accolades, en heet een context als er andere directives in kunnen. Wat buiten elk blok staat, hoort bij de hoofdcontext (main), die events en http bevat; server staat in http, en location in server.

Dit is de kern van een WordPress-site, met PHP-FPM luisterend op een socket:

server {
    listen 443 ssl;
    server_name voorbeeld.nl;
    root /var/www/voorbeeld;
    index index.php;
    location / {
        try_files $uri $uri/ /index.php?$args;
    }
    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass unix:/run/php/php-fpm.sock;
    }
}

De volgorde van de location-blokken

Dit is de meest voorkomende bron van fouten. Volgens de documentatie zoekt Nginx eerst een exacte overeenkomst (=), die het zoeken stopt. Daarna onthoudt hij het langste passende prefix; heeft dat prefix ^~, dan blijft hij daarbij. Anders test hij de reguliere expressies (~, hoofdlettergevoelig, en ~*, niet hoofdlettergevoelig) in de volgorde van het bestand, en de eerste die past, wint. Pas als er geen enkele overeenkomt, valt hij terug op het onthouden prefix. Praktisch gevolg: een blokkeerregel die als gewoon prefix is geschreven, kan worden omzeild door het blok ~ \.php$.

Testen en herladen

nginx -t controleert de syntaxis en de toegang tot de genoemde bestanden, zonder iets toe te passen. nginx -s reload past daarna de nieuwe configuratie toe: het masterproces controleert haar, start nieuwe workers en stopt de oude zodra hun lopende verzoeken klaar zijn; bij een fout houdt het de oude aan.

Voor WordPress

• Geen enkele plugin kan nginx.conf aanpassen: regels die een plugin in een .htaccess zou schrijven, moeten met de hand of door de hoster worden overgenomen.
• Blokkeer gevoelige bestanden met exacte locations of reguliere expressies die vóór het PHP-blok staan: back-ups, .git, .env, debug.log, zoals in ons artikel over blootgestelde bestanden.
• Beperk het beheer op IP of met HTTP-authenticatie, volgens onze gids om wp-admin aan de serverkant te beschermen.
• WP Masquerade heeft nginx.conf alleen nodig voor de bestandsaliassen van de Pro-versie, waarvan het het blok toont dat je in het server-blok kopieert, en voor één regel die zijn map verbergt: de pagina compatibiliteit met hosters en caches geeft deze regels. Test met nginx -t voordat je herlaadt.