Nginx Config for WordPress (LEMP Stack)

LEMP — Linux, Nginx (pronounced “engine-x,” hence the E), MySQL/MariaDB, PHP — is the standard high-performance alternative to the older LAMP (Apache) stack for WordPress. Nginx handles static files and reverse-proxies dynamic requests to PHP-FPM directly, without the per-request overhead Apache’s module-based architecture carries. This is a practical walkthrough of the server block config that actually matters for a WordPress site, not just a generic Nginx tutorial.

Why Nginx for WordPress

Nginx uses an event-driven, asynchronous architecture that handles concurrent connections with a fixed, small number of worker processes, versus Apache’s traditional approach of spawning a process or thread per connection. In practice this means Nginx uses meaningfully less memory under load and handles traffic spikes more gracefully — a real advantage for WordPress sites that get spiky traffic from social shares or ad campaigns. The tradeoff is that Nginx doesn’t read .htaccess files at all, so every WordPress rewrite rule, redirect, and security restriction that a shared host might traditionally handle via .htaccess must live directly in the server block config instead.

The Core WordPress Server Block

A minimal working WordPress server block needs three things: the WordPress permalink rewrite rule, a PHP-FPM handler, and a rule blocking direct access to sensitive files.

server {
  listen 80;
  server_name example.com www.example.com;
  root /var/www/example.com/public_html;
  index index.php index.html;

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

  location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
  }

  location ~ /\.ht {
    deny all;
  }
}

The try_files $uri $uri/ /index.php?$args; line is the piece that makes WordPress’s pretty permalinks (like /2026/07/post-name/) actually resolve — without it, everything except the homepage returns a 404, since Nginx has no built-in concept of WordPress’s rewrite rules the way Apache’s mod_rewrite plus WordPress’s own .htaccess block provides.

Static File Caching

Add a location block for static assets so Nginx serves them directly without touching PHP at all:

location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff2?)$ {
  expires 30d;
  add_header Cache-Control "public, no-transform";
  access_log off;
}

This alone meaningfully cuts server load on image-heavy WordPress sites, since browser-cached and long-expiry static assets never generate a repeat request within the cache window.

Blocking Common WordPress Attack Vectors

A few targeted rules stop a large share of automated WordPress attack traffic before it reaches PHP:

location ~* wp-config.php { deny all; }
location ~* /(?:uploads|files)/.*\.php$ { deny all; }
location = /xmlrpc.php { deny all; }

The uploads-folder PHP block specifically stops a common exploitation pattern where an attacker uploads a PHP file disguised as media and then tries to execute it directly; legitimate WordPress uploads never need PHP execution rights. Disabling xmlrpc.php is worth doing unless you specifically need it (e.g. for the WordPress mobile app or certain Jetpack features), since it’s a frequent brute-force and DDoS-amplification target.

PHP-FPM Tuning Matters As Much As Nginx Config

Nginx just proxies to PHP-FPM — if PHP-FPM’s worker pool is misconfigured, Nginx’s efficiency doesn’t help. In /etc/php/8.3/fpm/pool.d/www.conf, the key settings are pm.max_children (total concurrent PHP processes, sized to available RAM — roughly total RAM divided by average PHP process memory footprint, commonly around 40-60MB per process on a typical WordPress site), pm.start_servers, and pm.min/max_spare_servers. Undersizing pm.max_children is one of the most common causes of a WordPress site that runs fine at low traffic but returns 502 errors under load — Nginx is working correctly, but PHP-FPM has no free worker to hand the request to.

Nginx vs Apache for WordPress

Factor	Nginx (LEMP)	Apache (LAMP)
Config location	Server block only, no .htaccess	httpd.conf plus per-directory .htaccess
Memory under concurrent load	Lower — event-driven workers	Higher — process/thread per connection
Ease of per-directory overrides	Harder — requires editing server block + reload	Easier — shared hosts commonly allow .htaccess edits directly
Typical use case	VPS/dedicated, high-traffic, performance-focused setups	Shared hosting, simpler self-managed setups

Verdict

LEMP is the better choice for WordPress sites on a VPS or dedicated server where you control the full stack and traffic is significant enough that Nginx’s lower memory footprint and static-file efficiency actually matter. It’s overkill — and a maintenance burden — for a low-traffic site on shared hosting where .htaccess-based Apache configuration is simpler to manage without SSH access. Get the try_files rewrite rule and PHP-FPM pool sizing right first; those two account for the large majority of “why isn’t this working” issues on a fresh LEMP WordPress setup.

FAQ

Why do my WordPress permalinks return a 404 on Nginx but worked fine on Apache?
Nginx doesn’t read WordPress’s .htaccess rewrite rules at all — you need the try_files $uri $uri/ /index.php?$args; line directly in the server block, which is Nginx’s equivalent of what WordPress’s .htaccess block handles automatically under Apache.

Do I need a separate config for HTTPS?
Yes — add a second server block listening on 443 with ssl_certificate/ssl_certificate_key directives, and typically a redirect from the port-80 block to the HTTPS version so all traffic ends up encrypted.

Can I use WordPress security/caching plugins that rely on .htaccess rules under Nginx?
Plugins that write .htaccess rules (many caching and security plugins default to this behavior) won’t do anything useful under Nginx since that file is never read — check whether the plugin has a documented Nginx-equivalent config snippet, and add it to the server block manually instead.

What causes 502 Bad Gateway errors specifically on a LEMP WordPress stack?
Almost always PHP-FPM running out of available worker processes (pm.max_children too low for the traffic) or PHP-FPM crashing/restarting due to a plugin error — check the PHP-FPM error log and Nginx error log together, since Nginx will report the gateway failure but PHP-FPM’s log has the actual root cause.

Is switching an existing Apache/LAMP WordPress site to Nginx/LEMP worth the effort?
Worth it if the site has meaningful, consistent traffic and you’re already comfortable managing server config directly; not worth it for a low-traffic site where Apache’s simpler .htaccess-based management outweighs Nginx’s performance edge.