Is Apache still a good choice for WordPress in 2026?

Yes. Apache with MPM Event and PHP-FPM is a modern, performant stack that matches Nginx's concurrency characteristics for most WordPress workloads. The old reputation of Apache as slow applies to MPM Prefork with mod_php, which is legacy. The practical advantage of Apache remains .htaccess support, which allows WordPress to manage its own configuration on shared hosting environments.

What is the difference between MPM Prefork and MPM Event?

MPM Prefork spawns a separate process for each connection and is the legacy model used with mod_php. MPM Event uses an event-driven, non-blocking model that handles keep-alive connections efficiently with fewer resources. For WordPress with PHP-FPM, MPM Event is the correct choice – it handles thousands of concurrent connections with a fraction of the memory that Prefork would require.

Should I use mod_php or PHP-FPM with Apache?

PHP-FPM via mod_proxy_fcgi is the recommended approach. It separates PHP processing from Apache's connection handling, allowing each layer to be tuned independently. mod_php forces MPM Prefork (one process per connection), which is resource-intensive. PHP-FPM allows MPM Event, better isolation, per-site pool configuration, and independent PHP process management.

Does .htaccess hurt performance?

Yes, marginally. Apache must check for .htaccess files in every directory in the path for each request. On high-traffic sites, moving rules from .htaccess to the main VirtualHost configuration (with AllowOverride None) eliminates this overhead. However, for most WordPress sites the performance impact is negligible compared to the convenience of .htaccess-based configuration.

How does Apache compare to Nginx for WordPress?

With MPM Event and PHP-FPM, Apache's performance is comparable to Nginx for typical WordPress workloads. Nginx has a slight edge in raw static file serving and memory efficiency under extreme concurrency. Apache's advantage is .htaccess support and module ecosystem (mod_security, mod_rewrite). For VPS deployments, both are equally valid – the choice often comes down to team familiarity.

Know-how

Apache for WordPress – MPM Event, PHP-FPM, and Security

Published: April 14, 2026 · Author: Marcin Szewczyk-Wilgan

Apache HTTP Server remains one of the most widely deployed web servers in the world, and it is the default on a large proportion of shared hosting environments where WordPress runs. While Nginx gets more attention in performance discussions, Apache 2.4 with the Event MPM and PHP-FPM via mod_proxy_fcgi is a fully competitive stack for WordPress – and in some respects easier to work with, thanks to .htaccess support that lets WordPress manage its own rewrites without server configuration access. This guide covers the complete modern Apache setup for WordPress.

MPM Event – The Modern Apache Model

Apache's performance characteristics are defined largely by its Multi-Processing Module (MPM). The right choice for WordPress in 2026 is MPM Event.

MPM Prefork (legacy)Creates a separate process for each connection. Simple and stable, but extremely resource-intensive: each process runs a full copy of Apache with mod_php. Even with no traffic, dozens of processes sit idle consuming RAM. Still used when mod_php (libapache2-mod-php) is required, but should be considered legacy for any new deployment.

MPM WorkerUses threads instead of processes: each process handles multiple connections via threads. More efficient than Prefork but still blocks on I/O. Not compatible with mod_php due to thread-safety issues. Use with PHP-FPM via mod_proxy_fcgi or mod_fcgid.

MPM EventThe recommended choice for modern Apache + WordPress. Extends the Worker model with an event-driven connection handling mechanism that offloads keep-alive connections from active request threads. A dedicated listener thread handles connection management while worker threads focus on request processing. Significantly reduces memory usage compared to Prefork under high concurrency.

Enabling MPM EventOn Debian/Ubuntu: a2dismod mpm_prefork; a2dismod mpm_worker; a2enmod mpm_event; systemctl restart apache2. Also disable mod_php: a2dismod php8.3 and enable PHP-FPM: a2enmod proxy_fcgi setenvif; a2enconf php8.3-fpm.

PHP-FPM via mod_proxy_fcgi

With MPM Event, PHP execution is handled by PHP-FPM via the mod_proxy_fcgi module. This separates PHP processing from Apache's connection handling, giving each layer its own tuning parameters.

mod_proxy_fcgi

Connecting Apache to PHP-FPM

In the VirtualHost configuration: <FilesMatch "\.php$"> SetHandler "proxy:unix:/run/php/php8.3-fpm-wordpress.sock|fcgi://localhost/" </FilesMatch>. This passes all .php requests to PHP-FPM via a Unix socket. The pipe-separated syntax (unix:...) specifies the socket; fcgi://localhost/ is the FastCGI endpoint identifier.

mod_fcgid

Alternative FCGI module

mod_fcgid is an alternative to mod_proxy_fcgi that manages its own PHP-FPM-like process pool. It is simpler to configure on shared hosting environments. For VPS deployments where you control the full stack, mod_proxy_fcgi with a separately configured PHP-FPM pool gives better control over worker tuning and security isolation.

Unix socket vs TCP

Same rules as Nginx

Unix sockets are faster for same-server communication. Configure PHP-FPM to listen on a Unix socket (listen = /run/php/php8.3-fpm-wordpress.sock) and point Apache's mod_proxy_fcgi at that socket. TCP (127.0.0.1:9000) is required only when PHP-FPM is on a separate server.

MPM Event tuning

ThreadsPerChild and MaxRequestWorkers

Key MPM Event parameters: ServerLimit 16, StartServers 4, ThreadsPerChild 25, MaxRequestWorkers 400, MinSpareThreads 50, MaxSpareThreads 150. MaxRequestWorkers = ServerLimit × ThreadsPerChild. Tune based on server RAM after measuring PHP-FPM worker sizes.

WordPress .htaccess and Configuration

Apache's .htaccess support is its main advantage over Nginx for WordPress environments where server configuration access is limited. WordPress writes its own rewrite rules to .htaccess automatically.

Standard WordPress .htaccessWordPress generates a standard .htaccess with RewriteEngine On and a catch-all rule that passes unresolved requests to index.php. This handles pretty permalinks, feeds, pagination, and custom post types without any server configuration changes. Never edit the WordPress-managed section between # BEGIN WordPress and # END WordPress markers.

AllowOverrideFor WordPress .htaccess to work, the VirtualHost must include AllowOverride All (or at minimum AllowOverride FileInfo Options) for the document root. Without this, Apache ignores .htaccess files entirely and WordPress rewrite rules do not function.

AllowOverride None in productionThe performance cost of .htaccess is that Apache checks for .htaccess files in every directory on every request. For maximum performance, set AllowOverride None globally and include the WordPress rewrite rules directly in the VirtualHost configuration. Apache then never checks for .htaccess files, eliminating the I/O overhead.

Security in .htaccessWordPress's default .htaccess protects wp-config.php: <Files wp-config.php> deny from all </Files>. Add similar rules to block direct access to .env files, XML-RPC if unused, and PHP execution in the uploads directory: <Directory "/uploads"> php_admin_value engine off </Directory> (or via the SetHandler directive with MPM Event).

mod_security and WAF

Apache's mod_security is a mature Web Application Firewall module that inspects HTTP requests against a ruleset before they reach WordPress.

OWASP CRSThe OWASP Core Rule Set (CRS) is the standard ruleset for mod_security. It blocks SQL injection, XSS, local/remote file inclusion, and other common attack patterns. Version 4.x is the current release. Install with apt install libapache2-mod-security2 and configure CRS rules from the owasp-modsecurity-crs package.

False positivesCRS at high paranoia levels frequently blocks legitimate WordPress admin actions: WP-CLI commands, plugin installers, REST API calls. Start at Paranoia Level 1 and adjust upward carefully. Use detection-only mode (SecRuleEngine DetectionOnly) to identify false positives before enabling blocking mode.

WordPress-specific exclusionsOWASP CRS includes WordPress-specific exclusion rules that whitelist known WordPress admin patterns. Enable these exclusions to significantly reduce false positives: Include /etc/modsecurity/crs/plugins/wordpress-config.conf. Review the exclusion rules before enabling in production.

Performance impactmod_security adds latency to every request it inspects. The exact overhead depends on ruleset size and server resources, but 1–5ms per request is typical at Paranoia Level 1. For high-traffic sites, consider Nginx ModSecurity (via the ngx_http_modsecurity_module) or a dedicated WAF appliance for better performance.

Security Hardening

Apache has several server-level security settings that should be configured on every WordPress server.

ServerTokens

Hide Apache version

By default, Apache includes its version number and OS in error responses and headers. Set ServerTokens Prod and ServerSignature Off to suppress this. Version disclosure helps attackers match known vulnerabilities to your specific Apache version.

Options

Disable directory browsing

Set Options -Indexes globally or per-directory to prevent Apache from generating directory listings when no index file is present. Directory browsing can expose file structure, uploaded content, and backup files. WordPress's .htaccess does not prevent this by default.

Security headers

Adding via mod_headers

Enable mod_headers (a2enmod headers) and add: Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains", Header always set X-Content-Type-Options "nosniff", Header always set X-Frame-Options "SAMEORIGIN", Header always set Referrer-Policy "strict-origin-when-cross-origin".

mod_evasive

Basic DDoS protection

mod_evasive detects and temporarily blocks IP addresses making an abnormally high number of requests. It is not a replacement for a proper network-level DDoS mitigation, but it provides basic protection against simple HTTP floods. Configure DOSHashTableSize, DOSPageCount, and DOSSiteCount thresholds based on your expected legitimate traffic.

Apache 2.4.66 and Recent Changes

Apache 2.4.66 (released in 2025) brought several improvements relevant to WordPress hosting. The most significant for performance is improved HTTP/2 server push integration and better handling of keep-alive connections under the Event MPM. Security improvements include updates to mod_ssl's cipher handling and improved request smuggling protections.

The key practical change for WordPress operators is impro