Nginx vs Apache v roce 2026: srovnání, konfigurace, jak vybrat

Nginx vs Apache v roce 2026: jaký je skutečný rozdíl?

Pokud čtete další článek „Nginx vs Apache" a očekáváte jednoznačnou odpověď — nebude. Ale bude něco užitečnějšího: reálná data z produkce, konkrétní konfigurace a jasná kritéria výběru.

Začněme faktem: 70 % klientů Hostiserver používá Nginx (včetně konfigurací s Nginx jako Reverse Proxy). Čistý Apache se vyskytuje převážně na legacy projektech a specifickém sdíleném hostingu. Trend posledních let je jednoznačný — Nginx + PHP-FPM vytlačuje Apache i tam, kde byl kdysi standardem.

To ale neznamená, že Apache je mrtvý. V některých scénářích je stále nenahraditelný — zejména tam, kde je potřeba dynamická konfigurace přes .htaccess nebo specifické moduly. Proto je důležité pochopit silné stránky obou serverů.

Tento průvodce vám pomůže pochopit, kdy co použít — bez marketingových frází a s konkrétními příklady z reálných projektů.

Kdo co používá v praxi

Podle naší statistiky vypadá rozdělení projektů takto:

Apache se volí pro:

• Legacy projekty s velkým množstvím individuálních úprav v .htaccess
• Bitrix, starší verze Magenta a další systémy kriticky závislé na .htaccess
• Sdílený hosting, kde je potřeba izolace uživatelů

Nginx se volí pro:

• Vysoce zatížené mediální portály
• API pro mobilní aplikace
• Moderní SPA na React/Vue/Angular
• WordPress a WooCommerce
• eCommerce platformy (PrestaShop, moderní Magento)

Architektura: proč je Nginx rychlejší

Rozdíl mezi Nginx a Apache není v „kvalitě kódu" nebo „modernosti". Rozdíl je v architektonickém přístupu ke zpracování spojení. A tento rozdíl má praktické důsledky, které pocítíte pod zátěží.

Apache: jeden proces — jedno spojení

Apache se narodil v éře, kdy server obsluhoval desítky současných uživatelů. Jeho klasický model (prefork) funguje jednoduše: pro každé spojení — samostatný proces. Je to spolehlivé, snadno se debuguje, ale špatně škáluje.

Představte si: 1000 současných spojení = 1000 procesů. Každý proces s mod_php váží 50–100 MB. Počítejme: 50–100 GB RAM jen na webový server. Při náporu provozu (nebo DDoS) server padá, protože vyčerpá limit MaxRequestWorkers.

Tohle není teoretický problém — je to #1 na seznamu problémů našich klientů s Apache: vyčerpání limitu MaxClients/MaxRequestWorkers. Web prostě „leží" při náporu botů nebo náhlém zvýšení provozu.

Nginx: jeden proces — tisíce spojení

Nginx je postaven na event-driven architektuře. Jeden worker proces zpracovává tisíce spojení současně pomocí neblokujícího I/O. Žádné přepínání kontextu mezi procesy, žádná režie na vytváření nových vláken.

Výsledek: Nginx se 4 worker procesy (podle počtu jader CPU) může obsluhovat stejně provozu jako Apache se stovkami procesů — a spotřebovat 10× méně RAM.

To vysvětluje, proč při náhlé zátěži (DDoS nebo virální provoz) Apache padá mnohem rychleji. Nginx obvykle drží — může vracet 504 Gateway Timeout, pokud backend (PHP) nestíhá, ale samotný webový server pokračuje v práci a přijímá spojení.

Problém C10k

V roce 2000 vznikl takzvaný „problém C10k" — jak obsluhovat 10 000 současných spojení. Apache s modelem „proces na spojení" to nemohl efektivně zvládnout. Nginx byl vytvořen právě pro řešení tohoto problému.

V roce 2026 se Apache zlepšil díky MPM Event, ale stále spotřebovává více paměti na každé nové spojení ve srovnání s Nginx. Pokud váš projekt očekává významné zátěže — Nginx zůstává lepší volbou.

Reálný výkon: co ukazují testy

Syntetické benchmarky jsou jedno, reálná produkce je něco jiného. Zde je to, co vidíme na projektech klientů.

WordPress: Nginx je o 15–30 % rychlejší

Za identických podmínek (stejný server, stejná verze PHP-FPM) Nginx + PHP-FPM ukazuje lepší TTFB (Time to First Byte) o 15–30 %. Při paralelních požadavcích je rozdíl ještě větší — Apache začíná „dusit" dříve.

Pro WooCommerce s velkými katalogy je kritické nastavit fastcgi_buffer_size, aby velké stránky produktů nevytvářely dočasné soubory na disku. To může přinést dalších 10–20 % rychlosti na stránkách s mnoha produkty.

Statický obsah: Nginx je bezkonkurenční

Doručování obrázků, CSS, JS — to je to, pro co byl Nginx stvořen. Dělá to s minimální zátěží CPU díky sendfile() a nulovému kopírování dat. Apache prohrává i s mod_cache.

Doporučená nastavení pro statiku v Nginx:

• Maximální expires pro statické soubory
• Vypnutí logování pro statiku (snižuje I/O)
• sendfile on — použití systémového volání sendfile
• tcp_nopush on — optimalizace TCP paketů

Pod zátěží: rozdíl je kritický

Při náhlém náporu provozu (DDoS, virální obsah, Reddit hug of death) Apache padá rychleji. Nginx obvykle drží — může vracet 504 Gateway Timeout, pokud backend (PHP) nestíhá, ale samotný webový server pokračuje v práci.

Typické problémy s výkonem

Top 3 problémy Apache:

1. Vyčerpání limitu MaxClients/MaxRequestWorkers (web „leží" při náporu botů)
2. Nadměrná spotřeba RAM přes mod_php (každý proces 50–100 MB)
3. Složité konflikty v .htaccess, které se těžko debugují

Top 3 problémy Nginx:

1. Chyby konfigurace fastcgi_params (502 Bad Gateway)
2. Problémy s oprávněními k soketům PHP-FPM
3. Nesprávné nastavení přesměrování (smyčky přesměrování)

Doporučené konfigurace Nginx

Teorie je dobrá, ale potřebujete fungující konfigurace. Zde je to, co používáme v produkci.

WordPress + FastCGI Cache

Tato konfigurace zvládne tisíce požadavků za sekundu. Caching anonymních uživatelů je must-have pro jakýkoli WordPress web. Přihlášení uživatelé a POST požadavky automaticky obcházejí cache.

# Definice zóny cache v http bloku
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 nastavení
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_protocols TLSv1.3;
    
    # Oznámení HTTP/3
    add_header Alt-Svc 'h3=":443"; ma=86400';
    root /var/www/wordpress;
    index index.php;
    # Logika obcházení cache
    set $skip_cache 0;
    
    # POST požadavky necachujeme
    if ($request_method = POST) { 
        set $skip_cache 1; 
    }
    
    # Požadavky s query string necachujeme
    if ($query_string != "") { 
        set $skip_cache 1; 
    }
    
    # Přihlášené uživatele necachujeme
    if ($http_cookie ~* "comment_author|wordpress_logged_in|wp-postpass") {
        set $skip_cache 1;
    }
    # Statika s dlouhým cachingem
    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 hlavička (ukazuje HIT/MISS)
        add_header X-FastCGI-Cache $upstream_cache_status;
    }
}

Reverse Proxy pro Node.js / Python / Go

Ideální pro moderní aplikace na NestJS, FastAPI, Django, Gin. Zahrnuje podporu WebSocketů a předávání reálných IP adres.

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 podpora
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        
        # Předávání reálných IP
        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;
        
        # Timeouty
        proxy_connect_timeout 60s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;
        
        # Bufferování
        proxy_buffering on;
        proxy_buffer_size 4k;
        proxy_buffers 8 4k;
    }
    
    # Health check endpoint
    location /health {
        proxy_pass http://backend;
        access_log off;
    }
}

Optimalizace pro statiku

# Globální nastavení v http bloku
sendfile on;
tcp_nopush on;
tcp_nodelay on;
# Gzip komprese
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;
# Statika
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;
}

Doporučené konfigurace Apache

Pokud potřebujete Apache — používejte ho správně. Hlavní pravidlo: pouze MPM Event + PHP-FPM. mod_php je anachronismus, který patří do roku 2010.

MPM Event — zlatý standard 2026

MPM Event je nejbližší modelu Nginx a efektivně pracuje s keep-alive spojeními. Zde je optimální konfigurace:

# /etc/apache2/mods-enabled/mpm_event.conf
<IfModule mpm_event_module>
    # Počet procesů při startu
    StartServers             3
    
    # Minimum volných vláken
    MinSpareThreads          25
    
    # Maximum volných vláken
    MaxSpareThreads          75
    
    # Maximum vláken na proces
    ThreadLimit              64
    ThreadsPerChild          25
    
    # Maximum současných požadavků
    # Počítejte: RAM / ~50MB na worker
    MaxRequestWorkers        400
    
    # 0 = procesy se nerestartují
    MaxConnectionsPerChild   0
</IfModule>

Připojení PHP-FPM

Zapomeňte na mod_php. PHP-FPM umožňuje Apache procesům zůstat lehkými, protože PHP běží v samostatných procesech.

# Povolení potřebných modulů
# 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 přes FPM
    <FilesMatch "\.php$">
        SetHandler "proxy:unix:/run/php/php8.3-fpm.sock|fcgi://localhost"
    </FilesMatch>
    <Directory /var/www/html>
        AllowOverride All
        Require all granted
        
        # Zákaz spouštění PHP v uploads
        <Directory /var/www/html/wp-content/uploads>
            <FilesMatch "\.php$">
                Require all denied
            </FilesMatch>
        </Directory>
    </Directory>
    
    # Komprese
    <IfModule mod_deflate.c>
        AddOutputFilterByType DEFLATE text/html text/plain text/css 
        AddOutputFilterByType DEFLATE application/javascript application/json
    </IfModule>
    
    # Caching statiky
    <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>

Proč ne mod_php?

mod_php vkládá interpret PHP do každého Apache procesu. To znamená:

• Každý proces váží 50–100 MB místo 5–10 MB
• I když Apache doručuje obrázek — proces stále drží PHP v paměti
• Při 100 současných spojeních — 5–10 GB RAM jen na Apache

S PHP-FPM jsou Apache procesy lehké a PHP běží samostatně — pouze když je potřeba.

HTTP/2, HTTP/3 a QUIC

HTTP/2: výchozí standard

V roce 2026 je HTTP/2 baseline. Bez něj je moderní web nemožný. Co HTTP/2 poskytuje:

• Multiplexing — více požadavků přes jedno spojení
• Komprese hlaviček — HPACK algoritmus snižuje režii
• Server Push — server může proaktivně posílat zdroje
• Prioritizace — důležitější zdroje se načítají první

Oba servery podporují HTTP/2, ale Nginx to dělá efektivněji díky své architektuře.

HTTP/3 (QUIC): budoucnost je tady

HTTP/3 je založen na protokolu QUIC (UDP místo TCP). V roce 2026 je to již stabilní technologie, ne experiment.

Výhody HTTP/3:

• Rychlejší navázání spojení — 0-RTT možný při opakovaných návštěvách
• Lepší práce při ztrátě paketů — žádný head-of-line blocking
• Vestavěné šifrování — TLS 1.3 integrován do protokolu
• Migrace spojení — při změně sítě (WiFi → LTE) spojení se nepřeruší

V Nginx je HTTP/3 podporován přes modul ngx_http_v3_module a je připraven pro produkci.

# Nginx s HTTP/3
server {
    # HTTP/3 na QUIC
    listen 443 quic reuseport;
    
    # Fallback na HTTP/2
    listen 443 ssl;
    http2 on;
    
    # Pouze TLS 1.3 pro HTTP/3
    ssl_protocols TLSv1.2 TLSv1.3;
    
    # Oznámení podpory HTTP/3
    add_header Alt-Svc 'h3=":443"; ma=86400';
    
    # ECDSA certifikát (rychlejší než RSA)
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}

SSL/TLS doporučení 2026

• TLS 1.3 — jediná doporučená verze (TLS 1.2 pro legacy)
• ECDSA certifikáty — rychlejší než RSA, používejte P-256
• OCSP Stapling — snižuje čas handshake
• Session Tickets — pro rychlejší obnovení relací

Bezpečnost: typické zranitelnosti a hardening

Typické chyby v konfiguraci

Většina průniků není kvůli zranitelnostem v kódu webového serveru, ale kvůli nesprávné konfiguraci. Zde je to, co pravidelně vidíme:

Apache:

• Options +Indexes — umožňuje zobrazit seznam souborů v adresáři. Útočník může najít záložní soubory, konfigurace, dočasné soubory
• Zastaralé CGI skripty se známými zranitelnostmi
• Vystavené .env, .git, záložní soubory (.sql, .bak)
• Zastaralé moduly s CVE

Nginx:

• Nesprávný location ~ \.php$ — může spustit PHP kód v nahraném souboru (např. image.php.jpg)
• Chybějící zákaz přístupu ke skrytým souborům (.git, .env)
• Vystavená verze serveru (server_tokens on) — usnadňuje hledání CVE

Security Headers

Minimální sada bezpečnostních hlaviček pro rok 2026:

# Nginx Security Headers
# Zabraňuje MIME-type sniffing
add_header X-Content-Type-Options "nosniff" always;
# Ochrana před clickjacking
add_header X-Frame-Options "SAMEORIGIN" always;
# Pouze HTTPS (povolte po testování!)
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
# XSS ochrana (pro starší prohlížeče)
add_header X-XSS-Protection "1; mode=block" always;
# Referrer Policy
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
# Content Security Policy (přizpůsobte pro svůj web!)
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline';" always;

Nginx Hardening

# Skrýt verzi serveru
server_tokens off;
# Zákaz přístupu ke skrytým souborům
location ~ /\. {
    deny all;
    access_log off;
    log_not_found off;
}
# Zákaz přístupu k citlivým souborům
location ~* \.(env|git|sql|bak|old|backup|log|ini|conf)$ {
    deny all;
}
# Omezení HTTP metod
location / {
    limit_except GET HEAD POST { 
        deny all; 
    }
}
# Ochrana před Slowloris
client_body_timeout 10s;
client_header_timeout 10s;
keepalive_timeout 65s;
send_timeout 10s;
# Omezení velikosti požadavků
client_max_body_size 10m;
client_body_buffer_size 128k;

Rate Limiting

Pro ochranu před Layer 7 DDoS má Nginx vestavěné nástroje — a fungují mnohem lépe než Apache mod_evasive.

# Definice zón rate limiting
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;
# Aplikace na 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;
}
# Aplikace na API
location /api/ {
    limit_req zone=api burst=50 nodelay;
    
    proxy_pass http://backend;
}

Apache: mod_evasive funguje hůře — pro seriózní ochranu je lepší použít Cloudflare, Fail2Ban nebo iptables/ipset na základě analýzy logů.

Co vybrat: Decision Matrix 2026

Místo abstraktních rad — konkrétní tabulka výběru. Najděte svůj scénář:

Kdy má Nginx před Apache smysl?

Pokud potřebujete .htaccess pro vývojáře, ale chcete chránit server před pomalými spojeními (Slowloris útoky) — dejte Nginx jako Reverse Proxy před Apache. Nginx bufferuje pomalé klienty a předává Apache pouze připravené požadavky.

Tato konfigurace také umožňuje:

• Cachovat statiku na Nginx (rychleji)
• SSL terminaci na Nginx (menší zátěž Apache)
• Rate limiting na Nginx (efektivnější)
• Ponechat .htaccess pro specifická pravidla

Časté chyby: co vidíme u klientů

Tyto chyby se pravidelně objevují při konzultacích — neopakujte je:

Monitoring a diagnostika

Nakonfigurovaný webový server je polovina úspěchu. Potřebujete také vidět, co se s ním děje.

Kontejnery a Kubernetes

V roce 2026 je kontejnerizace standardem pro produkci. Zde jsou best practices pro webové servery v kontejnerech.

Často kladené otázky