Apache 2.4 for PHP Apps: A Modern Baseline Configuration

Apache 2.4 for PHP Apps: A Modern Baseline Configuration

Your Apache config probably predates your PHP version. Time to fix that.

Most legacy PHP applications run behind Apache, and most Apache configurations are a collection of directives accumulated over years of Stack Overflow answers. They work, but they are rarely optimised, rarely secured to modern standards, and almost never reviewed as a whole.

This guide provides a complete, modern baseline Apache 2.4 configuration for PHP applications. It is not a minimal example. It is a production-ready starting point that handles MPM selection, PHP-FPM integration, TLS configuration, security headers, compression, caching, and logging. Every directive is explained so you understand what it does and why it is there.

Prerequisites

This guide assumes:

  • Apache 2.4.x (2.4.54 or later recommended)
  • PHP-FPM (not mod_php) as the PHP handler
  • TLS termination at Apache (not a reverse proxy)
  • A single virtual host serving one PHP application

If you are running PHP-FPM and want to optimise the PHP-FPM side, see the PHP-FPM Tuning by Measurement guide.

MPM Selection: event vs prefork vs worker

Apache’s Multi-Processing Module (MPM) determines how it handles concurrent connections. The choice affects memory usage, concurrency limits, and PHP-FPM compatibility.

1
LoadModule mpm_event_module modules/mod_mpm_event.so

mpm_event is the best choice for PHP-FPM setups. It uses threads for connection handling, with a dedicated thread for keep-alive connections. This means idle keep-alive connections consume minimal resources.

Key properties:

  • Thread-based: high concurrency with lower memory
  • Keep-alive connections are cheap to maintain
  • Requires PHP-FPM (not compatible with mod_php)

mpm_prefork (Legacy)

mpm_prefork is the traditional choice, required when using mod_php. Each connection gets a dedicated process. This is simple but memory-intensive.

If you are still using mod_php, the single most impactful change you can make is switching to PHP-FPM plus mpm_event. The memory savings alone justify the effort.

mpm_worker (Middle Ground)

mpm_worker uses threads like mpm_event but handles keep-alive connections less efficiently. There is no practical reason to choose it over mpm_event in 2026.

MPM Tuning

For mpm_event:

1
2
3
4
5
6
7
8
9
<IfModule mpm_event_module>
    ServerLimit             16
    StartServers             4
    MinSpareThreads         75
    MaxSpareThreads        250
    ThreadsPerChild         25
    MaxRequestWorkers      400
    MaxConnectionsPerChild   0
</IfModule>

What these mean:

  • ServerLimit: Maximum number of server processes. MaxRequestWorkers / ThreadsPerChild.
  • StartServers: Processes to start at launch. Start low; Apache will spawn more as needed.
  • MinSpareThreads / MaxSpareThreads: Keep this many idle threads ready. Prevents latency spikes when traffic bursts arrive.
  • ThreadsPerChild: Threads per process. 25 is a safe default for most systems.
  • MaxRequestWorkers: Total concurrent connections. Size this based on available memory and expected concurrency.
  • MaxConnectionsPerChild: Requests before a process recycles. 0 means never recycle. Set to a value (e.g., 10000) if you suspect memory leaks in loaded modules.

PHP-FPM Integration via mod_proxy_fcgi

The modern way to connect Apache to PHP-FPM is through mod_proxy_fcgi, not mod_php or mod_fastcgi:

1
2
3
4
5
6
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_fcgi_module modules/mod_proxy_fcgi.so

<FilesMatch "\.php$">
    SetHandler "proxy:unix:/run/php/php-fpm.sock|fcgi://localhost"
</FilesMatch>

This sends .php requests to PHP-FPM via a Unix socket. Unix sockets are faster than TCP connections for same-machine communication.

For TCP-based PHP-FPM (common in containerised setups):

1
2
3
<FilesMatch "\.php$">
    SetHandler "proxy:fcgi://127.0.0.1:9000"
</FilesMatch>

Timeout Configuration

1
ProxyTimeout 60

This is the time Apache waits for PHP-FPM to respond. Set it to match your PHP max_execution_time. If PHP-FPM takes longer than this, Apache returns a 504 Gateway Timeout.

Virtual Host Configuration

A complete virtual host for a PHP application:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
<VirtualHost *:443>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/example/public

    # TLS configuration (covered in next section)
    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem

    <Directory /var/www/example/public>
        Options -Indexes -FollowSymLinks
        AllowOverride None
        Require all granted

        # Front controller pattern
        RewriteEngine On
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteCond %{REQUEST_FILENAME} !-d
        RewriteRule ^ index.php [L]
    </Directory>

    # PHP-FPM handler
    <FilesMatch "\.php$">
        SetHandler "proxy:unix:/run/php/php-fpm.sock|fcgi://localhost"
    </FilesMatch>

    # Deny access to sensitive files
    <FilesMatch "(^\.ht|\.env|composer\.(json|lock))$">
        Require all denied
    </FilesMatch>

    # Logging
    ErrorLog /var/log/apache2/example-error.log
    CustomLog /var/log/apache2/example-access.log combined
</VirtualHost>

AllowOverride None

Notice AllowOverride None. This disables .htaccess processing entirely.

Every request, Apache walks the directory tree looking for .htaccess files. On an application with deep directory structures, this can mean ten or more filesystem stat calls per request. Disabling .htaccess and putting all directives in the virtual host configuration eliminates this overhead.

If your application relies on .htaccess files, move their contents into the <Directory> block and set AllowOverride None. This is a one-time migration that permanently eliminates the per-request filesystem overhead.

Security Headers

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
<IfModule mod_headers.c>
    # Prevent MIME type sniffing
    Header always set X-Content-Type-Options "nosniff"

    # Prevent clickjacking
    Header always set X-Frame-Options "SAMEORIGIN"

    # XSS protection (legacy browsers)
    Header always set X-XSS-Protection "1; mode=block"

    # Referrer policy
    Header always set Referrer-Policy "strict-origin-when-cross-origin"

    # Permissions policy
    Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"

    # Content Security Policy
    Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; font-src 'self'; connect-src 'self'; frame-ancestors 'self'; base-uri 'self'; form-action 'self'"

    # Strict Transport Security
    Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

    # Remove server version information
    Header always unset X-Powered-By
    ServerTokens Prod
    ServerSignature Off
</IfModule>

Every header has a purpose. Do not remove headers without understanding what protection they provide. Adjust Content-Security-Policy to match your application’s requirements. The example above is strict and disallows inline scripts.

TLS Configuration

1
2
3
4
5
6
7
8
9
<IfModule mod_ssl.c>
    SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
    SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
    SSLHonorCipherOrder on
    SSLCompression off
    SSLSessionTickets off
    SSLUseStapling on
    SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"
</IfModule>

This configuration:

  • Disables SSLv3, TLS 1.0, and TLS 1.1 (all have known vulnerabilities)
  • Uses only AEAD ciphers (GCM mode)
  • Enables OCSP stapling for faster TLS handshakes
  • Disables session tickets (potential forward secrecy risk with key rotation)

Compression

1
2
3
4
5
6
7
8
9
10
11
12
<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/html text/plain text/xml
    AddOutputFilterByType DEFLATE text/css text/javascript application/javascript
    AddOutputFilterByType DEFLATE application/json application/xml
    AddOutputFilterByType DEFLATE application/xhtml+xml application/rss+xml
    AddOutputFilterByType DEFLATE image/svg+xml

    # Do not compress already-compressed formats
    SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|webp|woff2?)$ no-gzip

    DeflateCompressionLevel 6
</IfModule>

DeflateCompressionLevel 6 is the sweet spot between compression ratio and CPU cost. Level 9 produces slightly smaller output but uses significantly more CPU. Level 1 is fast but barely compresses.

Static Asset Caching

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<IfModule mod_expires.c>
    ExpiresActive On

    # HTML: no cache (PHP responses)
    ExpiresByType text/html "access plus 0 seconds"

    # CSS and JavaScript: cache with versioned filenames
    ExpiresByType text/css "access plus 1 year"
    ExpiresByType application/javascript "access plus 1 year"

    # Images: long cache
    ExpiresByType image/jpeg "access plus 1 year"
    ExpiresByType image/png "access plus 1 year"
    ExpiresByType image/webp "access plus 1 year"
    ExpiresByType image/svg+xml "access plus 1 year"

    # Fonts: long cache
    ExpiresByType font/woff2 "access plus 1 year"
    ExpiresByType application/font-woff2 "access plus 1 year"
</IfModule>

This assumes you use versioned filenames for CSS and JavaScript (e.g., style.v3.css or style.css?v=abc123). If you change the file, you change the filename or query string. The long cache duration means returning visitors never re-download unchanged assets.

Logging

Access Log Format

1
2
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %D" combined_with_time
CustomLog /var/log/apache2/example-access.log combined_with_time

The %D at the end adds the request duration in microseconds. This is essential for performance monitoring. Without it, you cannot identify slow requests from access logs.

Error Log Level

1
LogLevel warn

In production, warn is the right level. info and debug produce too much output and can impact performance on high-traffic sites. Temporarily increase to debug when troubleshooting specific issues.

Modules to Disable

Apache loads many modules by default. Each loaded module consumes memory and increases the attack surface. Disable what you do not need:

1
2
3
4
5
6
7
8
# Modules to disable on a PHP-FPM setup
# (comment out or remove from the LoadModule section)
# LoadModule cgi_module
# LoadModule autoindex_module
# LoadModule status_module (unless you use server-status)
# LoadModule userdir_module
# LoadModule include_module (SSI)
# LoadModule negotiation_module

Run apachectl -M to see what is loaded. If you cannot explain why a module is active, disable it and test.

HTTP to HTTPS Redirect

1
2
3
4
5
<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    Redirect permanent / https://example.com/
</VirtualHost>

Use a simple redirect instead of RewriteRule. It is clearer, faster, and communicates intent better than a rewrite pattern.

Monitoring: server-status

1
2
3
4
5
6
7
8
9
<IfModule mod_status.c>
    <Location /server-status>
        SetHandler server-status
        Require ip 10.0.0.0/8
        Require ip 172.16.0.0/12
        Require ip 192.168.0.0/16
    </Location>
    ExtendedStatus On
</IfModule>

server-status shows active connections, request rates, and worker status. Restrict it to internal IPs only. Never expose it publicly.

ExtendedStatus On adds per-request details but has a small performance cost from additional tracking. Enable it in production; the monitoring value outweighs the cost.

FAQ

Should I use Apache or Nginx in 2026?
If your application relies on .htaccess files or Apache-specific modules and you are not ready to migrate, Apache remains a solid choice. If you are starting fresh, Nginx or Caddy are generally simpler for reverse-proxy-to-PHP-FPM setups.

Can I use HTTP/2 with Apache?
Yes. mod_http2 works with mpm_event. Add Protocols h2 http/1.1 to your virtual host. HTTP/2 reduces latency for pages with many assets.

Should I switch from mod_php to PHP-FPM?
Yes. Always. mod_php ties you to mpm_prefork, which is the least efficient MPM. PHP-FPM with mpm_event uses significantly less memory and handles more concurrent connections.

Applying This Baseline

Start with the complete configuration above. Adjust MaxRequestWorkers based on your available memory and expected traffic. Customise Content-Security-Policy for your application. Test with your full test suite.

For PHP-FPM pool configuration to match this Apache setup, see the PHP-FPM Tuning by Measurement guide. For understanding how the web server connects to PHP in the request lifecycle, see the Request Lifecycle Explained article.

The performance fundamentals that inform these tuning decisions are covered in the Performance Optimisation chapter of the Zend Framework book.