Built to handle a large number of simultaneous connections, Nginx has become a leading web server, used on its own or as a reverse proxy in front of other servers. WordPress recommends it, alongside Apache, as one of the most robust servers for hosting the CMS.
How Nginx works
According to its documentation, Nginx runs one master process and several worker processes. The master reads and validates the configuration and manages the workers; the workers do the actual request processing, using an event-driven model. Instead of dedicating a process or thread to each connection, each worker keeps track of many connections at once and reacts as soon as one of them is ready. The number of workers is often set to the number of CPU cores.
The configuration lives in the nginx.conf file and its includes. A change only takes effect after a reload (nginx -s reload): the master checks the new configuration, starts new workers and gracefully shuts down the old ones, or keeps the old configuration if the new one contains an error.
Nginx and PHP
Nginx doesn't run PHP itself. It passes scripts to a FastCGI server, almost always PHP-FPM, with the fastcgi_pass directive. The exchange goes through a Unix socket or a local port; the PHP documentation warns that a FastCGI endpoint exposed to the network allows arbitrary code execution, which is why a socket is preferred when everything runs on the same machine.
No .htaccess
This is the difference that surprises people coming from Apache the most: the WordPress documentation points out that Nginx has no per-directory configuration file like .htaccess. Everything is configured at the server level, and WordPress can't write its own rewrite rules. For permalinks, the key line is:
location / {
try_files $uri $uri/ /index.php?$args;
}It serves the requested file or folder if it exists, and otherwise passes the request to index.php, keeping the URL parameters. Without it, custom permalinks return 404 errors.
For WordPress
- Plugin rules don't apply on their own: a plugin that writes to .htaccess (caching, security, redirects) has no effect on Nginx. Its rules have to be carried over into the configuration, or you have to ask the host to do it.
- Protect the admin area and sensitive files with
locationblocks, as shown in our guide to protecting wp-admin at the server level. - Behind a CDN or a proxy, configure the real_ip module to recover the visitor's address; see Cloudflare in front of WordPress.
- Reload after every change, and test the configuration first with
nginx -t.
WP Masquerade works on Nginx without server rules, with two exceptions: the Pro version's file aliases, for which the plugin generates the block to copy, and one line that hides the plugin's folder, as explained on the hosting and cache compatibility page.
Common mistakes
Adding protections to an .htaccess file on an Nginx server and thinking the site is protected; leaving PHP-FPM listening on an address reachable from the internet; forgetting ?$args in try_files, which breaks URLs with parameters. Many hosts also put Nginx in front of Apache: in that case, .htaccess works again for the requests passed on to Apache.