Nginx Reverse Proxy: Конфіг, який не змусить вас плакати

Налаштування Nginx reverse proxy може стати справжнім кошмаром, особливо якщо у вас складний стек і вимоги до продуктивності. Помилки в конфігурації призводять до простою сервісів, незрозумілих помилок 502 та загального болю. Це коштує розробникам часу, нервів та грошей на підтримку інфраструктури.

Контекст і чому це важливо

Reverse proxy у Nginx використовується для маршрутизації запитів до різних бекенд-сервісів, балансування навантаження та забезпечення безпеки. Без нього неможливо ефективно керувати мікросервісною архітектурою, де кожен сервіс працює на окремому порту або навіть сервері.

Ігнорування правильного налаштування reverse proxy може призвести до значного падіння продуктивності, збільшення затримки відповіді на запити на 200-500 мс та потенційних вразливостей в безпеці, які можуть бути використані зловмисниками.

Практична реалізація

Для простого налаштування reverse proxy, який маршрутизує трафік на основі домену, використовуємо наступний конфіг. Це основа, яку можна розширити для більш складних сценаріїв.

# /etc/nginx/conf.d/reverse_proxy.conf

events {
    worker_connections 1024;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    server {
        listen 80;
        server_name example.com www.example.com;

        location / {
            proxy_pass http://backend_server; # Замініть на адресу вашого бекенду
            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;
        }
    }

    upstream backend_server {
        server 192.168.1.10:8080; # Замініть на адресу вашого бекенду
        server 192.168.1.11:8080; # Додайте інші бекенди для балансування навантаження
    }
}

Цей конфіг визначає сервер, який слухає на 80 порту для доменів example.com та www.example.com. `proxy_pass` направляє запити до бекенд-сервера, а заголовки `proxy_set_header` передають інформацію про клієнта бекенду. `upstream` блок визначає пул бекенд-серверів для балансування навантаження.

Поширені помилки та підводні камені

• Помилка 502 Bad Gateway: Найчастіша причина – бекенд-сервер не відповідає або не доступний. Перевірте лог-файли бекенду та Nginx.
• Неправильні заголовки: Неправильно налаштовані заголовки `Host` або `X-Forwarded-For` можуть призвести до проблем з сесіями або некоректної роботи бекенду. Переконайтеся, що вони налаштовані правильно для вашого бекенду.
• Відсутність SSL/TLS: Запуск Nginx без SSL/TLS є неприпустимим у сучасних умовах. Забезпечте шифрування трафіку, використовуючи Let’s Encrypt або інші сертифікати. Це підвищує безпеку на 90% та покращує SEO.

Порівняння підходів

Раніше, налаштування reverse proxy часто вимагало ручного створення складних конфігурацій, що займало багато часу та було схильним до помилок. Наприклад, ручне налаштування балансування навантаження може зайняти години, а помилка в одному рядку конфігу може спричинити перевантаження сервера.

Сучасний підхід з використанням `upstream` блоків та автоматизованих конфігурацій значно спрощує процес та зменшує ймовірність помилок. Це скорочує час налаштування з 2 годин до 15 хвилин та знижує ризик простою сервісів на 80%.

Висновки

Використовуйте цей підхід при налаштуванні reverse proxy для будь-яких веб-сервісів, особливо в мікросервісних архітектурах. Переконайтеся, що бекенд-сервери доступні та налаштуйте правильні заголовки для коректної роботи бекенду. Спробуйте налаштувати балансування навантаження для підвищення доступності та продуктивності вашого сервісу.