Тандем Nginx + Apache 🤝 Як поєднати швидкість та гнучкість

У світі веб-серверів часто говорять про протистояння Nginx vs Apache. Але що, якби я сказав вам, що їх можна не протиставляти, а змусити працювати разом, доповнюючи сильні сторони один одного? Саме така ідея лежить в основі популярної конфігурації, де Nginx виступає в ролі реверс-проксі перед Apache.

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

 

Навіщо ставити Nginx перед Apache? Основна ідея

Ідея проста: ми використовуємо Nginx для того, що він робить найкраще, а Apache — для його унікальних переваг.

• Nginx (Фронтенд): Він “зустрічає” всіх відвідувачів (слухає стандартні порти 80 та 443). Його завдання:
  • ⚡️ Блискавично віддавати статичний контент (картинки, CSS, JS), не турбуючи Apache.
  • 🛡️ Ефективно обробляти велику кількість одночасних з’єднань та повільних клієнтів.
  • 🔄 Передавати запити на динамічний контент (наприклад, PHP-скрипти) на Apache.
  • (Опціонально) Виконувати SSL-термінацію, кешування, балансування навантаження.
• Apache (Бекенд): Він працює “за спиною” Nginx, слухаючи на іншому, нестандартному порту (наприклад, 8080). Його завдання:
  • ⚙️ Виконувати динамічний контент (наприклад, PHP через mod_php).
  • 📝 Обробляти правила з файлів .htaccess, надаючи гнучкість налаштування для користувачів.
  • 🧩 Використовувати специфічні модулі Apache, яких немає в Nginx.

Таким чином, ми отримуємо краще з обох світів: швидкість Nginx для статики та з’єднань + гнучкість Apache для динаміки та конфігурації.

 

Переваги та недоліки такої зв’язки

 

Плюси 👍

• Прискорення сайту: Nginx значно швидше віддає статику, що зменшує час завантаження сторінки.
• Краща стійкість до навантажень: Nginx ефективніше обробляє велику кількість з’єднань, захищаючи повільніший Apache від перевантаження.
• Збереження гнучкості .htaccess: Користувачі (особливо на віртуальному хостингу) можуть продовжувати використовувати звичні .htaccess для редиректів, правил доступу тощо.
• Додаткові можливості: Nginx може взяти на себе кешування, SSL, базовий захист від DDoS, розвантаживши Apache.

 

Мінуси 👎

1. Складніша конфігурація: Потрібно налаштовувати два веб-сервери замість одного.
2. Більше споживання ресурсів: Запуск двох веб-серверів вимагає трохи більше пам’яті та CPU, ніж один Nginx + PHP-FPM.
3. Можливі проблеми з визначенням IP: Apache буде бачити всі запити як такі, що надходять від Nginx (з IP-адреси сервера). Потрібно додатково налаштовувати передачу реальної IP-адреси клієнта (заголовки X-Forwarded-For).

 

Практика: як налаштувати Nginx як реверс-проксі для Apache

Давайте я покажу базову конфігурацію. Припустимо, Apache вже налаштований і працює на порту 8080, а Nginx буде слухати порт 80.

 

Крок 1: налаштування Apache

Переконайтеся, що Apache слухає нестандартний порт. Відредагуйте файл конфігурації портів (зазвичай /etc/apache2/ports.conf):

# Listen 80
Listen 8080 
# Listen 443 https (якщо використовуєте SSL на Apache, що зазвичай не потрібно в цій схемі)

Також змініть порт у конфігурації вашого віртуального хоста (/etc/apache2/sites-available/my-site.conf):

# Замість <VirtualHost *:80>
<VirtualHost *:8080>
    # ... решта конфігурації ...
</VirtualHost>

Перезапустіть Apache: sudo systemctl restart apache2.

 

Крок 2: налаштування Nginx

Тепер налаштуємо Nginx, щоб він слухав порт 80, віддавав статику сам, а все інше проксіював на Apache.

Створіть або відредагуйте конфігурацію сайту в Nginx (наприклад, /etc/nginx/sites-available/my-site-proxy.conf):

server {
    listen 80;
    server_name example.com www.example.com;    
    # Коренева папка сайту (та сама, що й в Apache)
    root /var/www/my-site/public;
    index index.php index.html index.htm;
    # Спочатку намагаємося віддати статичний файл
    location / {
        try_files $uri $uri/ @apache; # Якщо файлу немає, передаємо на Apache
    }
    # Пряма віддача популярної статики (оптимізація)
    location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
        expires 7d; # Кешуємо статику
        # try_files $uri =404; # Можна додати, щоб не турбувати Apache, якщо файлу немає
    }
    # Блок для передачі запитів на Apache
    location @apache {
        proxy_pass http://127.0.0.1:8080; # Адреса та порт, де слухає Apache
        # Передача реальної 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;
    }
    # Забороняємо доступ до .htaccess (Nginx їх не використовує)
    location ~ /\.ht {
        deny all;
    }
}

Увімкніть конфігурацію та перезавантажте Nginx:

sudo ln -s /etc/nginx/sites-available/my-site-proxy.conf /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

 

Важливий момент про передачу IP-адреси

Щоб Apache бачив реальну IP-адресу відвідувача (а не IP вашого сервера), потрібно встановити та налаштувати модуль mod_remoteip (для Apache 2.4+) або mod_rpaf (для старих версій). Він буде читати заголовок X-Forwarded-For, який ми передаємо з Nginx.

 

Висновок: коли компроміс є найкращим рішенням?