Nginx vs Apache у 2026: порівняння, конфігурації, вибір

Nginx vs Apache у 2026: яка різниця насправді?

Якщо ви читаєте черговий "Nginx vs Apache" і чекаєте на однозначну відповідь — її не буде. Але буде дещо корисніше: реальні дані з продакшену, конкретні конфіги та чіткі критерії вибору.

Почнемо з факту: 70% клієнтів Hostiserver використовують Nginx (включаючи конфігурації з Nginx як Reverse Proxy). Чистий Apache зустрічається переважно на legacy-проєктах та специфічному Shared-хостингу. Тренд останніх років однозначний — Nginx + PHP-FPM витісняє Apache навіть там, де він колись був стандартом.

Але це не означає, що Apache мертвий. У деяких сценаріях він досі незамінний — особливо там, де потрібна динамічна конфігурація через .htaccess або специфічні модулі. Саме тому важливо розуміти сильні сторони обох серверів.

Цей гайд допоможе зрозуміти, коли що використовувати — без маркетингової води та з конкретними прикладами з реальних проєктів.

Хто що використовує на практиці

За нашою статистикою, розподіл проєктів виглядає так:

Apache обирають для:

• Legacy-проєктів з великою кількістю індивідуальних правок у .htaccess
• Bitrix, старих версій Magento та інших систем, що критично залежать від .htaccess
• Shared-хостингу, де потрібна ізоляція користувачів

Nginx обирають для:

• Високонавантажених медіа-порталів
• API для мобільних додатків
• Сучасних SPA на React/Vue/Angular
• WordPress та WooCommerce
• eCommerce платформ (PrestaShop, сучасних Magento)

Архітектура: чому Nginx швидший

Різниця між Nginx та Apache — не в "якості коду" чи "сучасності". Різниця в архітектурному підході до обробки з'єднань. І ця різниця має практичні наслідки, які ви відчуєте під навантаженням.

Apache: один процес — одне з'єднання

Apache народився в епоху, коли сервер обслуговував десятки одночасних користувачів. Його класична модель (prefork) працює просто: для кожного з'єднання — окремий процес. Це надійно, легко дебажити, але жахливо масштабується.

Уявіть: 1000 одночасних з'єднань = 1000 процесів. Кожен процес з mod_php важить 50-100 МБ. Рахуємо: 50-100 ГБ RAM тільки на веб-сервер. При напливі трафіку (або DDoS) сервер падає, бо вичерпується ліміт MaxRequestWorkers.

Це не теоретична проблема — це топ-1 у списку проблем наших клієнтів з Apache: вичерпання ліміту MaxClients/MaxRequestWorkers. Сайт просто "лежить" при напливі ботів або раптовому збільшенні трафіку.

Nginx: один процес — тисячі з'єднань

Nginx побудований на event-driven архітектурі. Один робочий процес обробляє тисячі з'єднань одночасно через неблокуючий I/O. Немає перемикання контексту між процесами, немає накладних витрат на створення нових потоків.

Результат: Nginx з 4 worker-процесами (по кількості ядер CPU) може обслуговувати стільки ж трафіку, скільки Apache з сотнями процесів — і споживати в 10 разів менше RAM.

Це пояснює, чому під раптовим навантаженням (DDoS або вірусний трафік) Apache падає значно швидше. Nginx зазвичай тримається — може віддавати 504 Gateway Timeout, якщо бекенд (PHP) не встигає, але сам веб-сервер продовжує працювати і приймати з'єднання.

Проблема C10k

У 2000-х роках виникла так звана "проблема C10k" — як обслуговувати 10 000 одночасних з'єднань. Apache з моделлю "процес на з'єднання" не міг це зробити ефективно. Nginx був створений саме для вирішення цієї проблеми.

У 2026 році Apache став кращим завдяки MPM Event, але він все ще споживає більше пам'яті на кожне нове з'єднання порівняно з Nginx. Якщо ваш проєкт очікує значні навантаження — Nginx залишається кращим вибором.

Реальна продуктивність: що показують тести

Синтетичні бенчмарки — це одне, а реальний продакшен — інше. Ось що ми бачимо на проєктах клієнтів.

WordPress: Nginx швидший на 15-30%

При однакових умовах (той самий сервер, та сама версія PHP-FPM) Nginx + PHP-FPM показує кращий TTFB (Time to First Byte) на 15-30%. При паралельних запитах різниця ще більша — Apache починає "захлинатись" раніше.

Для WooCommerce з великими каталогами критично налаштувати fastcgi_buffer_size, щоб великі сторінки товарів не створювали тимчасові файли на диску. Це може дати додаткові 10-20% до швидкості на сторінках з багатьма товарами.

Статичний контент: Nginx поза конкуренцією

Віддача картинок, CSS, JS — це те, для чого Nginx створений. Він робить це з мінімальним навантаженням на CPU завдяки sendfile() та нульовому копіюванню даних. Apache навіть з mod_cache програє.

Рекомендовані налаштування для статики в Nginx:

• Максимальний expires для статичних файлів
• Вимкнення логів для статики (зменшує I/O)
• sendfile on — використання системного виклику sendfile
• tcp_nopush on — оптимізація TCP-пакетів

Під навантаженням: різниця критична

При раптовому напливі трафіку (DDoS, вірусний контент, Reddit hug of death) Apache падає швидше. Nginx зазвичай тримається — може віддавати 504 Gateway Timeout, якщо бекенд (PHP) не встигає, але сам веб-сервер продовжує працювати.

Типові проблеми продуктивності

Топ-3 проблеми Apache:

1. Вичерпання ліміту MaxClients/MaxRequestWorkers (сайт "лежить" при напливі ботів)
2. Перевитрата RAM через mod_php (кожен процес 50-100 МБ)
3. Складні конфлікти в .htaccess, які важко дебажити

Топ-3 проблеми Nginx:

1. Помилки конфігурації fastcgi_params (502 Bad Gateway)
2. Проблеми з правами доступу до сокетів PHP-FPM
3. Неправильне налаштування редіректів (циклічні редіректи)

Рекомендовані конфігурації Nginx

Теорія — це добре, але вам потрібні робочі конфіги. Ось що ми використовуємо на продакшені.

WordPress + FastCGI Cache

Ця конфігурація дозволяє витримувати тисячі запитів за секунду. Кешування анонімних користувачів — must-have для будь-якого WordPress-сайту. Залогінені користувачі та POST-запити автоматично проходять повз кеш.

# Визначаємо зону кешування в http блоці
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 налаштування
    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
    add_header Alt-Svc 'h3=":443"; ma=86400';
    root /var/www/wordpress;
    index index.php;
    # Логіка визначення, що кешувати
    set $skip_cache 0;
    
    # POST запити не кешуємо
    if ($request_method = POST) { 
        set $skip_cache 1; 
    }
    
    # Запити з query string не кешуємо
    if ($query_string != "") { 
        set $skip_cache 1; 
    }
    
    # Залогінених користувачів не кешуємо
    if ($http_cookie ~* "comment_author|wordpress_logged_in|wp-postpass") {
        set $skip_cache 1;
    }
    # Статика з довгим кешуванням
    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;
        
        # Кешування
        fastcgi_cache WP_CACHE;
        fastcgi_cache_valid 200 301 302 1h;
        fastcgi_cache_bypass $skip_cache;
        fastcgi_no_cache $skip_cache;
        
        # Заголовок для дебагу (показує HIT/MISS)
        add_header X-FastCGI-Cache $upstream_cache_status;
    }
}

Reverse Proxy для Node.js / Python / Go

Ідеально для сучасних застосунків на NestJS, FastAPI, Django, Gin. Включає підтримку WebSockets та передачу реальних IP-адрес.

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;
        
        # WebSockets підтримка
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        
        # Передача реальних 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;
        
        # Таймаути
        proxy_connect_timeout 60s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;
        
        # Буферизація
        proxy_buffering on;
        proxy_buffer_size 4k;
        proxy_buffers 8 4k;
    }
    
    # Health check endpoint
    location /health {
        proxy_pass http://backend;
        access_log off;
    }
}

Оптимізація для статики

# Глобальні налаштування в http блоці
sendfile on;
tcp_nopush on;
tcp_nodelay on;
# Gzip стиснення
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;
# Статика
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;
}

Рекомендовані конфігурації Apache

Якщо вам потрібен Apache — використовуйте його правильно. Головне правило: тільки MPM Event + PHP-FPM. mod_php — це анахронізм, якому місце в 2010 році.

MPM Event — золотий стандарт 2026

MPM Event найбільш наближений до моделі Nginx і ефективно працює з keep-alive з'єднаннями. Ось оптимальна конфігурація:

# /etc/apache2/mods-enabled/mpm_event.conf
<IfModule mpm_event_module>
    # Кількість процесів при старті
    StartServers             3
    
    # Мінімум вільних потоків
    MinSpareThreads          25
    
    # Максимум вільних потоків
    MaxSpareThreads          75
    
    # Максимум потоків на процес
    ThreadLimit              64
    ThreadsPerChild          25
    
    # Максимум одночасних запитів
    # Розраховуйте: RAM / ~50MB на worker
    MaxRequestWorkers        400
    
    # 0 = процеси не перезапускаються
    MaxConnectionsPerChild   0
</IfModule>

Підключення PHP-FPM

Забудьте про mod_php. PHP-FPM дозволяє Apache-процесам залишатися легкими, бо PHP виконується в окремих процесах.

# Увімкнути необхідні модулі
# 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 через FPM
    <FilesMatch "\.php$">
        SetHandler "proxy:unix:/run/php/php8.3-fpm.sock|fcgi://localhost"
    </FilesMatch>
    <Directory /var/www/html>
        AllowOverride All
        Require all granted
        
        # Заборона виконання PHP в uploads
        <Directory /var/www/html/wp-content/uploads>
            <FilesMatch "\.php$">
                Require all denied
            </FilesMatch>
        </Directory>
    </Directory>
    
    # Стиснення
    <IfModule mod_deflate.c>
        AddOutputFilterByType DEFLATE text/html text/plain text/css 
        AddOutputFilterByType DEFLATE application/javascript application/json
    </IfModule>
    
    # Кешування статики
    <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>

Чому не mod_php?

mod_php вбудовує інтерпретатор PHP в кожен процес Apache. Це означає:

• Кожен процес важить 50-100 МБ замість 5-10 МБ
• Навіть коли Apache віддає картинку — процес все одно тримає PHP в пам'яті
• При 100 одночасних з'єднаннях — 5-10 ГБ RAM тільки на Apache

З PHP-FPM процеси Apache легкі, а PHP виконується окремо — тільки коли потрібно.

HTTP/2, HTTP/3 та QUIC

HTTP/2: стандарт за замовчуванням

У 2026 році HTTP/2 — це baseline. Без нього сучасний веб неможливий. Що дає HTTP/2:

• Мультиплексування — кілька запитів через одне з'єднання
• Стиснення заголовків — HPACK алгоритм зменшує overhead
• Server Push — сервер може проактивно відправити ресурси
• Пріоритизація — важливіші ресурси завантажуються першими

Обидва сервери підтримують HTTP/2, але Nginx робить це ефективніше завдяки своїй архітектурі.

HTTP/3 (QUIC): майбутнє, яке вже тут

HTTP/3 базується на протоколі QUIC (UDP замість TCP). У 2026 році це вже стабільна технологія, а не експеримент.

Переваги HTTP/3:

• Швидше встановлення з'єднання — 0-RTT можливий при повторних візитах
• Краща робота при втратах пакетів — немає head-of-line blocking
• Вбудоване шифрування — TLS 1.3 інтегрований в протокол
• Міграція з'єднань — при зміні мережі (WiFi → LTE) з'єднання не розривається

У Nginx HTTP/3 підтримується через модуль ngx_http_v3_module і вже готовий для продакшену.

# Nginx з HTTP/3
server {
    # HTTP/3 на QUIC
    listen 443 quic reuseport;
    
    # Fallback на HTTP/2
    listen 443 ssl;
    http2 on;
    
    # Тільки TLS 1.3 для HTTP/3
    ssl_protocols TLSv1.2 TLSv1.3;
    
    # Оголошення підтримки HTTP/3
    add_header Alt-Svc 'h3=":443"; ma=86400';
    
    # ECDSA сертифікат (швидший за RSA)
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}

SSL/TLS рекомендації 2026

• TLS 1.3 — єдина рекомендована версія (TLS 1.2 для legacy)
• ECDSA сертифікати — швидші за RSA, використовуйте P-256
• OCSP Stapling — зменшує час handshake
• Session Tickets — для швидшого відновлення сесій

Безпека: типові вразливості та hardening

Типові помилки в конфігурації

Більшість зламів — не через вразливості в коді веб-сервера, а через неправильну конфігурацію. Ось що ми бачимо регулярно:

Apache:

• Options +Indexes — дозволяє бачити список файлів у директорії. Атакуючий може знайти backup-файли, конфіги, тимчасові файли
• Застарілі CGI-скрипти з відомими вразливостями
• Відкриті .env, .git, backup-файли (.sql, .bak)
• Застарілі модулі з CVE

Nginx:

• Неправильний location ~ \.php$ — може виконати PHP-код у завантаженому файлі (наприклад, image.php.jpg)
• Відсутня заборона доступу до прихованих файлів (.git, .env)
• Відкрита версія сервера (server_tokens on) — полегшує пошук CVE

Security Headers

Мінімальний набір заголовків безпеки для 2026 року:

# Nginx Security Headers
# Запобігає MIME-type sniffing
add_header X-Content-Type-Options "nosniff" always;
# Захист від clickjacking
add_header X-Frame-Options "SAMEORIGIN" always;
# HTTPS тільки (включіть після тестування!)
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
# XSS захист (для старих браузерів)
add_header X-XSS-Protection "1; mode=block" always;
# Referrer Policy
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
# Content Security Policy (налаштуйте під свій сайт!)
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline';" always;

Nginx Hardening

# Приховати версію сервера
server_tokens off;
# Заборона доступу до прихованих файлів
location ~ /\. {
    deny all;
    access_log off;
    log_not_found off;
}
# Заборона доступу до sensitive файлів
location ~* \.(env|git|sql|bak|old|backup|log|ini|conf)$ {
    deny all;
}
# Обмеження HTTP методів
location / {
    limit_except GET HEAD POST { 
        deny all; 
    }
}
# Захист від Slowloris
client_body_timeout 10s;
client_header_timeout 10s;
keepalive_timeout 65s;
send_timeout 10s;
# Обмеження розміру запитів
client_max_body_size 10m;
client_body_buffer_size 128k;

Rate Limiting

Для захисту від Layer 7 DDoS Nginx має вбудовані інструменти — і вони працюють набагато краще, ніж Apache mod_evasive.

# Визначення зон 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;
# Застосування до 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;
}
# Застосування до API
location /api/ {
    limit_req zone=api burst=50 nodelay;
    
    proxy_pass http://backend;
}

Apache: mod_evasive працює гірше — для серйозного захисту краще використовувати Cloudflare, Fail2Ban або iptables/ipset на базі аналізу логів.

Що обрати: Decision Matrix 2026

Замість абстрактних порад — конкретна таблиця вибору. Знайдіть свій сценарій:

Коли Nginx перед Apache має сенс?

Якщо вам потрібен .htaccess для розробників, але хочеться захистити сервер від повільних з'єднань (Slowloris атак) — ставте Nginx як Reverse Proxy перед Apache. Nginx буферизує повільних клієнтів і передає Apache тільки готові запити.

Ця конфігурація також дозволяє:

• Кешувати статику на Nginx (швидше)
• SSL-термінацію на Nginx (менше навантаження на Apache)
• Rate limiting на Nginx (ефективніше)
• Залишити .htaccess для специфічних правил

Типові помилки: що ми бачимо у клієнтів

Ці помилки зустрічаються регулярно на консалтингу — не повторюйте їх:

Моніторинг та діагностика

Налаштований веб-сервер — це половина справи. Потрібно ще бачити, що з ним відбувається.

Контейнери та Kubernetes

У 2026 році контейнеризація — це стандарт для production. Ось best practices для веб-серверів у контейнерах.

Часті запитання