NGINX Server Block Best Practices: Powering Your WordPress Multisite

At MathsRocket.Online, we pride ourselves on a robust and high-performance server infrastructure. Our choice of NGINX (pronounced “engine-x”) as a web server is pivotal to this. NGINX is known for its high concurrency, excellent performance as a reverse proxy, and efficient handling of static content, making it an ideal choice for dynamic applications like our WordPress Multisite.

This article delves into the best practices for configuring NGINX server blocks, particularly relevant for hosting WordPress, ensuring optimal performance, enhanced security, and streamlined management.

Understanding NGINX Server Blocks

In NGINX, a “server block” (analogous to Apache’s Virtual Host) defines the configuration for a specific website or domain. Each server block listens on a particular IP address and port, responding to requests for its designated domain names. This modular approach allows you to host multiple websites on a single server, each with its unique settings.

More Read

Mastering the DOM: A Foundation for Modern Web Development

The Symphony of Science: Unveiling the Deep Connection Between Mathematics and Physics

Your Digital Classroom: Building the Perfect Online Teaching Setup

Server block configurations are typically found in /etc/nginx/sites-available/ (with symbolic links to /etc/nginx/sites-enabled/ for active sites) on Ubuntu systems.

NGINX Server Block Best Practices for WordPress & Performance

Here’s a breakdown of essential configurations to include in your NGINX server blocks for a high-performing WordPress site, especially a Multisite on a subdirectory:

1. Basic Server Setup:

server {
listen 80;
listen [::]:80; # Listen for IPv6
server_name yourdomain.com www.yourdomain.com; # Your domain(s)
return 301 https://$host$request_uri; # Force HTTPS (crucial for security & SEO)
}

server {
listen 443 ssl http2; # Listen for HTTPS, enable HTTP/2
listen [::]:443 ssl http2;

server_name yourdomain.com www.yourdomain.com;

# SSL Configuration (replace with your actual paths)
ssl_certificate /etc/nginx/ssl/yourdomain.com/fullchain.pem;
ssl_certificate_key /etc/nginx/ssl/yourdomain.com/privkey.pem;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers “ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384”;
ssl_prefer_server_ciphers on;

root /var/www/html/yourdomain.com; # Your WordPress root directory
index index.php index.html index.htm;

# Error pages
error_page 404 /404.html;
error_page 500 502 503 504 /50x.html;

# Logging
access_log /var/log/nginx/yourdomain.com.access.log;
error_log /var/log/nginx/yourdomain.com.error.log;

# … (more configurations below)
}

• listen 80; and listen 443 ssl http2;: Ensure NGINX listens on both HTTP and HTTPS ports, with HTTP/2 enabled for faster loading.
• server_name: Define your domain(s). Always include both yourdomain.com and www.yourdomain.com and redirect one to the other (we recommend non-www to www or vice versa consistently for SEO).
• return 301 https://$host$request_uri;: Crucial for automatically redirecting all HTTP traffic to HTTPS, enforcing encryption.
• ssl_certificate / ssl_certificate_key: Paths to your SSL certificates (e.g., from Let’s Encrypt).
• ssl_protocols / ssl_ciphers: Use strong, modern TLS protocols and ciphers to ensure robust security.
• root: The absolute path to your WordPress installation directory.
• index: Define the order of index files.
• access_log / error_log: Define paths for your logs, which are vital for debugging and monitoring.

2. WordPress Rewrite Rules (Crucial for Permalinks):

location / { try_files $uri $uri/ /index.php?$args; }

This rule ensures WordPress permalinks work correctly by directing all requests to index.php if a file or directory isn’t found.

3. PHP Processing (FastCGI with PHP-FPM):

location ~ \.php$ {
include snippets/fastcgi-php.conf; # Common NGINX snippet for PHP-FPM
fastcgi_pass unix:/var/run/php/php8.2-fpm.sock; # Path to your PHP-FPM socket (adjust PHP version)
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}

• This block passes PHP requests to PHP-FPM (FastCGI Process Manager), which is the recommended way to handle PHP with NGINX for performance. Adjust the fastcgi_pass path to your PHP-FPM version.

4. NGINX FastCGI Cache for WordPress (Performance Booster):

This is a powerful caching mechanism that significantly speeds up page delivery.

In nginx.conf (http block, typically at /etc/nginx/nginx.conf):

http {
# … other http configurations …
fastcgi_cache_path /var/run/nginx-cache levels=1:2 keys_zone=WORDPRESS_CACHE:100m inactive=60m max_size=1G;
fastcgi_cache_key “$scheme$request_method$host$request_uri”;
fastcgi_cache_valid 200 301 302 60m; # Cache valid responses for 60 minutes
fastcgi_cache_use_stale error timeout invalid_header updating http_500 http_503;
fastcgi_ignore_headers Cache-Control Expires Set-Cookie;
}

In your server block (yourdomain.com.conf):

location ~ \.php$ {
# … existing PHP-FPM configuration …

fastcgi_cache WORDPRESS_CACHE;
fastcgi_cache_valid 200 60m; # Cache 200 responses for 60 minutes
fastcgi_cache_bypass $http_pragma $http_authorization $cookie_wordpress_logged_in;
fastcgi_no_cache $http_pragma $http_authorization $cookie_wordpress_logged_in;
}

# Don’t cache specific paths (admin, wp-login, etc.)
location ~ /(wp-admin|wp-login.php|wp-cron.php|wp-json|xmlrpc.php) {
fastcgi_cache off;
proxy_no_cache 1;
expires off;
access_log off; # Optionally turn off access logs for these busy paths
}

# Also avoid caching AJAX requests if they are dynamic
location ~ /wp-admin/admin-ajax.php {
fastcgi_cache off;
proxy_no_cache 1;
expires off;
access_log off;
}

• fastcgi_cache_path: Defines where NGINX stores cached files.
• fastcgi_cache_key: Generates a unique key for each cached response.
• fastcgi_cache_valid: Specifies how long cached items are considered valid.
• fastcgi_cache_bypass / fastcgi_no_cache: Crucially, these directives prevent caching for logged-in users, the WordPress admin area, and other dynamic sections to avoid serving stale content.

5. Static File Caching (Browser Caching):

location ~* \.(jpg|jpeg|gif|png|webp|ico|css|js|woff|woff2|ttf|otf|eot|svg)$ {
expires 30d; # Cache static files for 30 days in browser
add_header Cache-Control “public, no-transform”;
access_log off; # Reduce log noise for static assets
}

• This tells browsers to cache static assets for a specified duration, reducing subsequent requests to the server.

6. Security Enhancements:

• Hide NGINX Version:

server_tokens off; # In http block in nginx.conf

• Block XML-RPC (if not used):

location ~* /xmlrpc.php$ {
deny all;
access_log off;
log_not_found off;
}

• Deny Access to Sensitive Files:

location ~ /\. {
deny all;
access_log off;
log_not_found off;
}
location ~ /wp-content/uploads/.*\.php$ {
deny all;
}

• HTTP Security Headers: Add headers like Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, X-XSS-Protection, Referrer-Policy, and Content-Security-Policy for enhanced browser security.

7. WordPress Multisite Specific Configuration (Subdirectory Mode):

If you’re running a subdirectory multisite, your location / block needs modification:

server {
# … other configurations …

location / {
try_files $uri $uri/ /index.php?$args;
}

# Add this block for Multisite subdirectory mode
rewrite /wp-admin$ $scheme://$host$uri/ permanent;
if (-f $request_filename) {
expires max;
break;
}
if (!-e $request_filename) {
rewrite ^/[_0-9a-zA-Z-]+(/wp-.*) $1 last;
rewrite ^/[_0-9a-zA-Z-]+/(.*\.php)$ $1 last;
}
if (!-e $request_filename) {
rewrite . /index.php last;
}
}

• These rules are critical for routing requests correctly to the various subsites within your WordPress Multisite setup.

Final Steps: Testing and Reloading NGINX

1. Test Configuration: After making changes, always test your NGINX configuration for syntax errors:

sudo nginx -t

2.Reload NGINX: If the test is successful, reload NGINX to apply the changes:

sudo systemctl reload nginx

By implementing these NGINX server block best practices, especially when combined with Redis for object caching and OPcache for PHP performance (which we meticulously configure on our Ubuntu servers), MathsRocket.Online ensures that our WordPress Multisite operates at peak efficiency. This robust server architecture is the technical bedrock supporting our mission to provide unparalleled Math education, custom web solutions, and powerful coding services.