fren
Log In

Apache or Nginx: which one?

2 min read07 November 2026

Apache and Nginx both serve HTTP, but their configuration and concurrency models differ. The choice is not about fashion: it depends on the existing application, how you want to manage rewrites and the skills available to operate the server.

Two architectures

Apache handles connections with processes or threads, depending on the active multi-processing module (MPM). Nginx uses an event loop: a few processes handle many connections, which lowers memory use per connection. That explains its reputation for static files and reverse proxying, not universal superiority.

Criterion Apache Nginx
Configuration central plus per-directory .htaccess centralized, no .htaccess
Rewrites mod_rewrite, convenient .htaccess rewrite inside the server block
PHP mod_php or PHP-FPM PHP-FPM only
Modules dynamic loading is common modules shipped as packages
Static files fine with MPM event highly efficient
Typical use legacy apps, control panels proxy, TLS, high concurrency

.htaccess and PHP-FPM

If the application ships a .htaccess file (WordPress, older CMS, rewrite rules), Apache applies it without a restart, at the cost of reading the file on every request. Nginx ignores .htaccess: rules must be translated into the server block. In both cases, PHP 8.4 runs through PHP-FPM on Debian 13; libapache2-mod-php8.4 still exists but mixes the web server and the interpreter in one process.

Practical criteria

  • Taking over an application documented for Apache, with many .htaccess rules: Apache is more direct.
  • Reverse proxy, TLS termination, several backends, lots of static content: Nginx is the usual choice.
  • A specific Apache module or a panel that requires it: Apache.
  • Team skills and consistency with staging: the decisive criterion, ahead of benchmarks.

Do not run both on port 80. Pick one and stop the other:

Bash
sudo systemctl disable --now apache2
sudo systemctl status nginx

Verify the configuration

Bash
sudo apachectl configtest
sudo nginx -t
sudo ss -ltnp '( sport = :80 or sport = :443 )'

The last check should show a single server listening per port. For a migration, test on a secondary port or a staging domain first, then compare HTTP codes with curl -I. A correct home page does not prove that rewrites work: test extensionless URLs, redirects and 404 responses.

When in doubt, keep the configuration your team can maintain. A server you understand and back up beats a theoretically faster server that is misconfigured.

Advertisement

Was this article helpful?

Read next