Що таке Nginx: чому він швидший за Apache? 🚀 | Інструкція + Конфіги

Коли мова заходить про веб-сервери, два імені завжди на слуху: Apache та Nginx. Apache — це ветеран, надійний та перевірений часом, який довгі роки був стандартом де-факто. Nginx (читається як “Енджінкс“) — це молодший, але зухваліший гравець, який стрімко завоював популярність завдяки своїй неймовірній швидкості та ефективності.

Я працював з обома системами і можу сказати впевнено: для більшості сучасних завдань Nginx є кращим вибором. У цій статті я хочу пояснити, що робить його таким особливим, у чому його ключові переваги перед Apache, і як ви можете використовувати його потужність на своєму сайті.

Nginx vs Apache: ключова відмінність в архітектурі

Щоб зрозуміти, чому Nginx швидший, потрібно зазирнути “під капот”. Головна відмінність криється у способі обробки запитів:

• Apache (процесно-орієнтований): За замовчуванням Apache створює окремий процес (або потік) для кожного нового з’єднання. Це просто та надійно, але дуже ресурсоємно. Уявіть, що для кожного відвідувача ресторану ви наймаєте окремого офіціанта. При великому напливі людей у вас просто не вистачить персоналу (пам’яті та CPU).
• Nginx (подієво-орієнтований, асинхронний): Nginx працює інакше. Він використовує невелику кількість робочих процесів, і кожен з них може одночасно обробляти тисячі з’єднань завдяки асинхронній моделі, керованій подіями. Це як один дуже спритний офіціант, який може одночасно приймати замовлення, розносити страви та прибирати столи, не блокуючись на одному завданні.

Ця асинхронна архітектура робить Nginx неймовірно ефективним, особливо при роботі з великою кількістю одночасних з’єднань (так звана проблема C10k) та при віддачі статичного контенту.

Головні ролі Nginx: більше, ніж просто веб-сервер

Хоча Nginx чудово справляється з роллю основного веб-сервера, його справжня сила розкривається в інших амплуа:

1. 🚀 Блискавична віддача статики

Nginx надзвичайно ефективний у віддачі статичних файлів: зображень, CSS, JavaScript. Він робить це набагато швидше та з меншим споживанням ресурсів, ніж Apache. Багато високопродуктивних конфігурацій використовують Nginx саме як “фасад”, який віддає статику, а динамічні запити передає на бекенд (наприклад, Apache або PHP-FPM).

2. 🔄 Реверс-проксі (Reverse Proxy)

Це одна з найпопулярніших ролей Nginx. Він виступає як посередник між клієнтом та вашими бекенд-серверами (веб-сервером, сервером додатків). Клієнт звертається до Nginx, а вже Nginx вирішує, куди перенаправити запит. Це дає багато переваг:

• Балансування навантаження: Розподіляє запити між кількома бекенд-серверами.
• Кешування: Зберігає відповіді бекенду і швидко віддає їх повторно.
• SSL-термінація: Розшифровує HTTPS-трафік, знімаючи це навантаження з бекенду.
• Безпека: Приховує реальну архітектуру вашої системи.

3. ⚖️ Балансувальник навантаження (Load Balancer)

Як я вже згадав, Nginx може ефективно розподіляти вхідні запити між групою серверів. Це дозволяє горизонтально масштабувати ваш додаток та забезпечує високу доступність: якщо один сервер вийде з ладу, Nginx автоматично перенаправить трафік на робочі.

http {
    upstream myapp_backend {
        server backend1.example.com;
        server backend2.example.com;
        server backend3.example.com;
    }
    server {
        listen 80;
        server_name example.com;
        location / {
            proxy_pass http://myapp_backend;
        }
    }
}

4. 🔗 Проксі для PHP-FPM та інших додатків

Це сучасний стандарт для роботи з PHP. Nginx приймає запит, і якщо це запит до .php файлу, він передає його на обробку окремому процесу PHP-FPM через FastCGI. Про цю зв’язку я детально розповідав у статті про FastCGI та PHP-FPM.

Практика: базова конфігурація Nginx для сайту на PHP

Давайте я покажу мінімально необхідну конфігурацію для простого сайту на PHP (наприклад, WordPress), яка демонструє основні принципи.

Зазвичай конфігураційні файли сайтів лежать у /etc/nginx/sites-available/, а потім створюються символічні посилання на них у /etc/nginx/sites-enabled/.

Створимо файл /etc/nginx/sites-available/my-site.conf:

server {
    # Слухаємо порт 80 для HTTP
    listen 80;
    # Слухаємо порт 443 для HTTPS
    listen 443 ssl http2; # Увімкнемо HTTP/2 для кращої продуктивності
    # Ім'я нашого сайту
    server_name example.com www.example.com;    
    # Коренева папка сайту
    root /var/www/my-site/public;    
    # Файли індексів
    index index.php index.html index.htm;
    # Налаштування SSL (шляхи до сертифікатів)
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    # Тут ще можуть бути інші налаштування SSL/TLS
    # Загальна обробка запитів
    location / {
        # Намагаємося знайти файл, потім папку, інакше передаємо на index.php
        try_files $uri $uri/ /index.php?$query_string;
    }
    # Обробка PHP-файлів
    location ~ \.php$ {
        include snippets/fastcgi-php.conf; # Стандартні налаштування FastCGI        
        # Передаємо запит на сокет PHP-FPM (шлях може відрізнятися!)
        fastcgi_pass unix:/var/run/php/php8.3-fpm.sock;         
        # Додаткові параметри FastCGI
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }
    # Забороняємо доступ до прихованих файлів (наприклад, .htaccess)
    location ~ /\. {
        deny all;
    }    
    # Налаштування кешування для статики (опціонально)
    location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
        expires 7d; # Кешувати на 7 днів
    }
}
# (Опціонально, але рекомендовано) Редирект з HTTP на HTTPS
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Після створення або редагування конфігурації не забудьте перевірити її на помилки (nginx -t) та перезавантажити Nginx (sudo systemctl reload nginx).

Висновок: Nginx — це швидкість, гнучкість та ефективність