Two web servers serve most of the web. Apache has been around since 1995 and is the one most tutorials assume; Nginx arrived in 2004 to solve a problem Apache had with many simultaneous connections and has since become the default for new deployments. The honest answer to "which one" depends on what you are hosting and who configures it.
How they differ underneath
Apache handles each connection with a process or thread (the MPM — prefork, worker or event). With PHP embedded via mod_php, every Apache worker carries a full PHP interpreter, so a server with 150 workers has 150 copies of PHP in memory whether or not the request needed PHP. With the newer event MPM and PHP-FPM, that improves substantially.
Nginx is event-driven: a handful of worker processes each handle thousands of connections with non-blocking I/O. It does not run PHP itself; it hands PHP requests to a separate PHP-FPM pool over a socket and serves everything else — images, CSS, cached pages — directly at very low cost.
The practical result: for static files and many concurrent connections, Nginx uses a fraction of the memory. For PHP, the difference narrows to almost nothing if Apache is configured with event MPM and PHP-FPM, which most default installs are not.
Configuration
Apache reads .htaccess files in every directory on every request. That is why WordPress permalinks, redirects and the rules plugins write "just work" on Apache: the application can change its own server config. It is also a performance cost (a filesystem lookup per directory per request) and a security concern (a compromised site can rewrite its own rules).
Nginx has no .htaccess. All configuration lives in server blocks that only root can edit, loaded once. Faster and safer; less convenient. A .htaccess rule a plugin expects to exist has to be translated into the Nginx config by hand. For WordPress that is a single try_files line; for applications with complex rewrite rules it can be real work.
Performance, honestly
Static files: Nginx, clearly, by memory use and by requests per second. PHP pages: near-identical when both use PHP-FPM, because the time is spent in PHP, not the web server. Where Nginx pulls ahead on PHP sites is as a cache: fastcgi_cache can serve whole pages from memory without touching PHP, which is what makes a WordPress site survive a traffic spike.
Why Plesk runs both
Plesk's default is Nginx in front of Apache: Nginx accepts every connection, serves static files itself and caches, and proxies dynamic requests to Apache, which still honours .htaccess. You get Nginx's efficiency where it matters and Apache's compatibility where applications expect it. The Serve static files directly by nginx and nginx caching options under Apache & nginx Settings are the two switches worth turning on; Proxy mode off turns Apache off entirely and runs PHP-FPM behind Nginx.
Which to choose
| Situation | Choose |
|---|---|
| WordPress or PHP app, you manage the server | Nginx + PHP-FPM, with fastcgi_cache |
PHP app that ships complex .htaccess rules you cannot translate |
Apache (event MPM + PHP-FPM), or Plesk's Nginx-in-front |
| Static site, API, reverse proxy, many connections | Nginx |
Shared hosting where customers need .htaccess |
Both, Nginx in front |
| A Node/Python/Go app behind a proxy | Nginx |
| You know Apache well and the site is fine | Apache — familiarity is worth more than a benchmark |
Other options
LiteSpeed and its open-source cousin OpenLiteSpeed are Apache-compatible (.htaccess works) with event-driven performance, and come with a well-integrated WordPress cache plugin. Good, but commercial, and less common on managed platforms. Caddy is the simplest to configure with automatic HTTPS, and a fine choice for a single developer's projects.
What we run
VPSPioneer shared plans run Plesk's Nginx-in-front-of-Apache with static files and caching handled by Nginx, so .htaccess works and the site is fast. On a managed VPS we default to Nginx with PHP-FPM and set up the cache, and switch to Apache behind it if the application needs it. A working Nginx configuration to start from is in the LEMP install guide.