Nginx vs Apache in 2026: Comparison, Configurations, How to Choose

Nginx vs Apache in 2026: What's the Real Difference?

If you're reading yet another "Nginx vs Apache" article expecting a definitive answer — there won't be one. But there will be something more useful: real production data, specific configs, and clear selection criteria.

Let's start with a fact: 70% of Hostiserver clients use Nginx (including configurations with Nginx as Reverse Proxy). Pure Apache is primarily found on legacy projects and specific Shared hosting. The trend in recent years is clear — Nginx + PHP-FPM is displacing Apache even where it was once the standard.

But this doesn't mean Apache is dead. In some scenarios, it's still irreplaceable — especially where dynamic configuration via .htaccess or specific modules is needed. That's why it's important to understand the strengths of both servers.

This guide will help you understand when to use what — without marketing fluff and with concrete examples from real projects.

Who Uses What in Practice

According to our statistics, project distribution looks like this:

Apache is chosen for:

• Legacy projects with many individual .htaccess modifications
• Bitrix, older Magento versions, and other systems critically dependent on .htaccess
• Shared hosting where user isolation is needed

Nginx is chosen for:

• High-load media portals
• APIs for mobile applications
• Modern SPAs on React/Vue/Angular
• WordPress and WooCommerce
• eCommerce platforms (PrestaShop, modern Magento)

Architecture: Why Nginx Is Faster

The difference between Nginx and Apache isn't about "code quality" or "modernity." The difference is in the architectural approach to connection handling. And this difference has practical consequences you'll feel under load.

Apache: One Process — One Connection

Apache was born in an era when servers handled dozens of concurrent users. Its classic model (prefork) works simply: one process per connection. It's reliable, easy to debug, but scales terribly.

Imagine: 1000 concurrent connections = 1000 processes. Each process with mod_php weighs 50-100 MB. Do the math: 50-100 GB of RAM just for the web server. During traffic spikes (or DDoS), the server crashes because it exhausts the MaxRequestWorkers limit.

This isn't a theoretical problem — it's #1 on our clients' Apache problem list: MaxClients/MaxRequestWorkers limit exhaustion. The site simply "dies" during bot floods or sudden traffic increases.

Nginx: One Process — Thousands of Connections

Nginx is built on event-driven architecture. One worker process handles thousands of connections simultaneously through non-blocking I/O. No context switching between processes, no overhead for creating new threads.

Result: Nginx with 4 worker processes (matching CPU cores) can serve as much traffic as Apache with hundreds of processes — while consuming 10x less RAM.

This explains why under sudden load (DDoS or viral traffic) Apache crashes much faster. Nginx usually holds — it might return 504 Gateway Timeout if the backend (PHP) can't keep up, but the web server itself continues working and accepting connections.

The C10k Problem

In the 2000s, the so-called "C10k problem" emerged — how to serve 10,000 concurrent connections. Apache with its "process per connection" model couldn't do this efficiently. Nginx was created specifically to solve this problem.

In 2026, Apache has improved thanks to MPM Event, but it still consumes more memory per new connection compared to Nginx. If your project expects significant loads — Nginx remains the better choice.

Real Performance: What Tests Show

Synthetic benchmarks are one thing, real production is another. Here's what we see on client projects.

WordPress: Nginx Is 15-30% Faster

Under identical conditions (same server, same PHP-FPM version) Nginx + PHP-FPM shows better TTFB (Time to First Byte) by 15-30%. With parallel requests, the difference is even greater — Apache starts "choking" earlier.

For WooCommerce with large catalogs, it's critical to configure fastcgi_buffer_size so large product pages don't create temporary files on disk. This can give an additional 10-20% speed boost on pages with many products.

Static Content: Nginx Is Unmatched

Serving images, CSS, JS — this is what Nginx was built for. It does this with minimal CPU load thanks to sendfile() and zero-copy data transfer. Apache loses even with mod_cache.

Recommended settings for static content in Nginx:

• Maximum expires for static files
• Disable logging for static files (reduces I/O)
• sendfile on — use sendfile system call
• tcp_nopush on — TCP packet optimization

Under Load: The Difference Is Critical

During sudden traffic floods (DDoS, viral content, Reddit hug of death) Apache crashes faster. Nginx usually holds — it might return 504 Gateway Timeout if the backend (PHP) can't keep up, but the web server itself continues working.

Typical Performance Problems

Top 3 Apache Problems:

1. MaxClients/MaxRequestWorkers limit exhaustion (site "dies" during bot floods)
2. RAM overconsumption through mod_php (each process 50-100 MB)
3. Complex .htaccess conflicts that are hard to debug

Top 3 Nginx Problems:

1. fastcgi_params configuration errors (502 Bad Gateway)
2. Permission issues with PHP-FPM sockets
3. Incorrect redirect configuration (redirect loops)

Recommended Nginx Configurations

Theory is good, but you need working configs. Here's what we use in production.

WordPress + FastCGI Cache

This configuration can handle thousands of requests per second. Caching anonymous users is a must-have for any WordPress site. Logged-in users and POST requests automatically bypass the cache.

# Define cache zone in http block
fastcgi_cache_path /var/cache/nginx/wordpress 
    levels=1:2 
    keys_zone=WP_CACHE:100m 
    inactive=60m;
server {
    listen 443 quic reuseport; # HTTP/3
    listen 443 ssl;
    server_name example.com;
    # SSL settings
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_protocols TLSv1.3;
    
    # HTTP/3 announcement
    add_header Alt-Svc 'h3=":443"; ma=86400';
    root /var/www/wordpress;
    index index.php;
    # Cache bypass logic
    set $skip_cache 0;
    
    # Don't cache POST requests
    if ($request_method = POST) { 
        set $skip_cache 1; 
    }
    
    # Don't cache requests with query string
    if ($query_string != "") { 
        set $skip_cache 1; 
    }
    
    # Don't cache logged-in users
    if ($http_cookie ~* "comment_author|wordpress_logged_in|wp-postpass") {
        set $skip_cache 1;
    }
    # Static files with long caching
    location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
        access_log off;
    }
    location / {
        try_files $uri $uri/ /index.php?$args;
    }
    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        
        # Caching
        fastcgi_cache WP_CACHE;
        fastcgi_cache_valid 200 301 302 1h;
        fastcgi_cache_bypass $skip_cache;
        fastcgi_no_cache $skip_cache;
        
        # Debug header (shows HIT/MISS)
        add_header X-FastCGI-Cache $upstream_cache_status;
    }
}

Reverse Proxy for Node.js / Python / Go

Ideal for modern applications on NestJS, FastAPI, Django, Gin. Includes WebSocket support and real IP forwarding.

upstream backend {
    server 127.0.0.1:3000;
    server 127.0.0.1:3001 backup;
    keepalive 32;
}
server {
    listen 443 ssl http2;
    server_name api.example.com;
    ssl_certificate /etc/letsencrypt/live/api.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/api.example.com/privkey.pem;
    location / {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        
        # WebSocket support
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        
        # Real IP forwarding
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        
        # Timeouts
        proxy_connect_timeout 60s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;
        
        # Buffering
        proxy_buffering on;
        proxy_buffer_size 4k;
        proxy_buffers 8 4k;
    }
    
    # Health check endpoint
    location /health {
        proxy_pass http://backend;
        access_log off;
    }
}

Static File Optimization

# Global settings in http block
sendfile on;
tcp_nopush on;
tcp_nodelay on;
# Gzip compression
gzip on;
gzip_vary on;
gzip_min_length 1024;
gzip_types text/plain text/css application/json application/javascript 
           text/xml application/xml application/xml+rss text/javascript
           image/svg+xml;
# Static files
location ~* \.(jpg|jpeg|png|gif|ico|css|js|svg|woff|woff2|ttf|eot)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
    access_log off;
    log_not_found off;
}

Recommended Apache Configurations

If you need Apache — use it correctly. The main rule: only MPM Event + PHP-FPM. mod_php is an anachronism that belongs in 2010.

MPM Event — The 2026 Gold Standard

MPM Event is closest to the Nginx model and works efficiently with keep-alive connections. Here's the optimal configuration:

# /etc/apache2/mods-enabled/mpm_event.conf
<IfModule mpm_event_module>
    # Number of processes at startup
    StartServers             3
    
    # Minimum spare threads
    MinSpareThreads          25
    
    # Maximum spare threads
    MaxSpareThreads          75
    
    # Maximum threads per process
    ThreadLimit              64
    ThreadsPerChild          25
    
    # Maximum concurrent requests
    # Calculate: RAM / ~50MB per worker
    MaxRequestWorkers        400
    
    # 0 = processes don't restart
    MaxConnectionsPerChild   0
</IfModule>

Connecting PHP-FPM

Forget about mod_php. PHP-FPM allows Apache processes to stay lightweight because PHP runs in separate processes.

# Enable required modules
# a2enmod proxy_fcgi setenvif
# a2enconf php8.3-fpm
<VirtualHost *:443>
    ServerName example.com
    DocumentRoot /var/www/html
    
    # SSL
    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
    # PHP via FPM
    <FilesMatch "\.php$">
        SetHandler "proxy:unix:/run/php/php8.3-fpm.sock|fcgi://localhost"
    </FilesMatch>
    <Directory /var/www/html>
        AllowOverride All
        Require all granted
        
        # Prevent PHP execution in uploads
        <Directory /var/www/html/wp-content/uploads>
            <FilesMatch "\.php$">
                Require all denied
            </FilesMatch>
        </Directory>
    </Directory>
    
    # Compression
    <IfModule mod_deflate.c>
        AddOutputFilterByType DEFLATE text/html text/plain text/css 
        AddOutputFilterByType DEFLATE application/javascript application/json
    </IfModule>
    
    # Static file caching
    <IfModule mod_expires.c>
        ExpiresActive On
        ExpiresByType image/jpg "access plus 1 year"
        ExpiresByType image/jpeg "access plus 1 year"
        ExpiresByType image/png "access plus 1 year"
        ExpiresByType image/gif "access plus 1 year"
        ExpiresByType text/css "access plus 1 month"
        ExpiresByType application/javascript "access plus 1 month"
    </IfModule>
</VirtualHost>

Why Not mod_php?

mod_php embeds the PHP interpreter in every Apache process. This means:

• Each process weighs 50-100 MB instead of 5-10 MB
• Even when Apache serves an image — the process still holds PHP in memory
• With 100 concurrent connections — 5-10 GB RAM just for Apache

With PHP-FPM, Apache processes stay lightweight, and PHP runs separately — only when needed.

HTTP/2, HTTP/3, and QUIC

HTTP/2: The Default Standard

In 2026, HTTP/2 is the baseline. Modern web is impossible without it. What HTTP/2 provides:

• Multiplexing — multiple requests over one connection
• Header compression — HPACK algorithm reduces overhead
• Server Push — server can proactively send resources
• Prioritization — important resources load first

Both servers support HTTP/2, but Nginx does it more efficiently thanks to its architecture.

HTTP/3 (QUIC): The Future Is Here

HTTP/3 is based on the QUIC protocol (UDP instead of TCP). In 2026, this is already stable technology, not an experiment.

HTTP/3 Advantages:

• Faster connection establishment — 0-RTT possible on repeat visits
• Better performance with packet loss — no head-of-line blocking
• Built-in encryption — TLS 1.3 integrated into the protocol
• Connection migration — when switching networks (WiFi → LTE) the connection doesn't break

In Nginx, HTTP/3 is supported through the ngx_http_v3_module and is production-ready.

# Nginx with HTTP/3
server {
    # HTTP/3 on QUIC
    listen 443 quic reuseport;
    
    # Fallback to HTTP/2
    listen 443 ssl;
    http2 on;
    
    # TLS 1.3 only for HTTP/3
    ssl_protocols TLSv1.2 TLSv1.3;
    
    # HTTP/3 support announcement
    add_header Alt-Svc 'h3=":443"; ma=86400';
    
    # ECDSA certificate (faster than RSA)
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}

SSL/TLS Recommendations 2026

• TLS 1.3 — the only recommended version (TLS 1.2 for legacy)
• ECDSA certificates — faster than RSA, use P-256
• OCSP Stapling — reduces handshake time
• Session Tickets — for faster session resumption

Security: Common Vulnerabilities and Hardening

Common Configuration Mistakes

Most breaches aren't due to web server code vulnerabilities, but incorrect configuration. Here's what we see regularly:

Apache:

• Options +Indexes — allows viewing directory file lists. Attackers can find backup files, configs, temporary files
• Outdated CGI scripts with known vulnerabilities
• Exposed .env, .git, backup files (.sql, .bak)
• Outdated modules with CVEs

Nginx:

• Incorrect location ~ \.php$ — can execute PHP code in uploaded files (e.g., image.php.jpg)
• Missing access denial for hidden files (.git, .env)
• Exposed server version (server_tokens on) — makes CVE searching easier

Security Headers

Minimum security header set for 2026:

# Nginx Security Headers
# Prevents MIME-type sniffing
add_header X-Content-Type-Options "nosniff" always;
# Clickjacking protection
add_header X-Frame-Options "SAMEORIGIN" always;
# HTTPS only (enable after testing!)
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
# XSS protection (for older browsers)
add_header X-XSS-Protection "1; mode=block" always;
# Referrer Policy
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
# Content Security Policy (customize for your site!)
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline';" always;

Nginx Hardening

# Hide server version
server_tokens off;
# Deny access to hidden files
location ~ /\. {
    deny all;
    access_log off;
    log_not_found off;
}
# Deny access to sensitive files
location ~* \.(env|git|sql|bak|old|backup|log|ini|conf)$ {
    deny all;
}
# Limit HTTP methods
location / {
    limit_except GET HEAD POST { 
        deny all; 
    }
}
# Slowloris protection
client_body_timeout 10s;
client_header_timeout 10s;
keepalive_timeout 65s;
send_timeout 10s;
# Request size limits
client_max_body_size 10m;
client_body_buffer_size 128k;

Rate Limiting

For Layer 7 DDoS protection, Nginx has built-in tools — and they work much better than Apache mod_evasive.

# Define rate limiting zones
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
limit_req_zone $binary_remote_addr zone=api:10m rate=100r/s;
limit_conn_zone $binary_remote_addr zone=conn:10m;
# Apply to login
location /wp-login.php {
    limit_req zone=login burst=3 nodelay;
    limit_conn conn 5;
    
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}
# Apply to API
location /api/ {
    limit_req zone=api burst=50 nodelay;
    
    proxy_pass http://backend;
}

Apache: mod_evasive works worse — for serious protection, it's better to use Cloudflare, Fail2Ban, or iptables/ipset based on log analysis.

What to Choose: Decision Matrix 2026

Instead of abstract advice — a concrete selection table. Find your scenario:

When Does Nginx in Front of Apache Make Sense?

If you need .htaccess for developers but want to protect the server from slow connections (Slowloris attacks) — put Nginx as Reverse Proxy in front of Apache. Nginx buffers slow clients and passes only ready requests to Apache.

This configuration also allows:

• Caching static on Nginx (faster)
• SSL termination on Nginx (less load on Apache)
• Rate limiting on Nginx (more effective)
• Keeping .htaccess for specific rules

Common Mistakes: What We See at Clients

These mistakes come up regularly in consulting — don't repeat them:

Monitoring and Diagnostics

A configured web server is half the battle. You also need to see what's happening with it.

Containers and Kubernetes

In 2026, containerization is the standard for production. Here are best practices for web servers in containers.

Frequently Asked Questions