Nginx як Проксі-сервер

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

Вступ

Nginx (Engine-X) — це веб-сервер з відкритим вихідним кодом, який також може працювати як зворотний проксі, кеш HTTP та балансувальник навантаження. Його подієво-орієнтована архітектура дозволяє ефективно обробляти велику кількість одночасних з'єднань, що робить його придатним для середовищ з високим трафіком. Як проксі, Nginx знаходиться між клієнтами та бекенд-серверами, опосередковуючи трафік та додаючи шари функціональності.

Навіщо використовувати Nginx як проксі?

Розгортання Nginx як проксі-сервера пропонує кілька експлуатаційних переваг:

• Балансування навантаження: Розподіляє вхідний мережевий трафік між кількома бекенд-серверами для покращення швидкості реагування та надійності програми.
• Термінація SSL/TLS: Обробляє зашифровані з'єднання від клієнтів, розшифровуючи трафік перед пересиланням його до бекенд-серверів, які потім можуть працювати з незашифрованим HTTP. Це розвантажує криптографічну обробку з серверів додатків.
• Кешування: Зберігає часто доступний вміст, зменшуючи навантаження на бекенд-сервери та скорочуючи час відповіді для клієнтів.
• Безпека: Діє як буфер, захищаючи бекенд-сервери від прямого доступу клієнтів та потенційних атак. Він може фільтрувати запити та застосовувати політики доступу.
• Висока доступність: У поєднанні з балансуванням навантаження Nginx може перенаправляти трафік від несправних бекенд-серверів, забезпечуючи безперервне обслуговування.
• Управління трафіком: Дозволяє перезаписувати URL-адреси, фільтрувати запити та маніпулювати вмістом.

Типи проксі Nginx

Nginx переважно працює у двох режимах проксі: зворотний проксі та прямий проксі.

Зворотний проксі

Зворотний проксі отримує ресурси від імені клієнта з одного або кількох серверів. Потім ці ресурси повертаються клієнту, виглядаючи так, ніби вони походять від самого проксі-сервера. Клієнти не знають про бекенд-архітектуру.

Прямий проксі

Прямий проксі отримує ресурси з широкого спектру серверів від імені клієнта. Він діє як посередник для клієнтів, які запитують ресурси із зовнішніх серверів. Клієнти явно налаштовані на використання прямого проксі.

Базова конфігурація зворотного проксі

Налаштування Nginx як зворотного проксі передбачає визначення блоку server, який прослуховує вхідні запити, а потім використовує директиву proxy_pass для пересилання їх до вихідного сервера.

Передумови

• Встановлений екземпляр Nginx.
• Доступ до файлів конфігурації Nginx (зазвичай /etc/nginx/nginx.conf або файлів у /etc/nginx/sites-available/).
• Бекенд-сервер (наприклад, сервер додатків, інший веб-сервер), що працює та доступний для сервера Nginx.

Основні директиви конфігурації

• proxy_pass: Фундаментальна директива для пересилання запитів. Вказує протокол, адресу та необов'язковий порт проксі-сервера.
• proxy_set_header: Змінює заголовки запитів, які Nginx надсилає проксі-серверу. Важливо для передачі IP-адреси клієнта, хоста та інформації про протокол.
• proxy_buffering: Контролює, чи буферизує Nginx відповіді від проксі-сервера. Буферизація може покращити продуктивність, дозволяючи Nginx отримати всю відповідь перед відправленням її клієнту.
• proxy_cache: Вмикає кешування відповідей від проксі-серверів.

# /etc/nginx/sites-available/my_reverse_proxy.conf

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

    location / {
        # Цільовий бекенд-сервер
        proxy_pass http://backend_app_server:8080;

        # Передача оригінального хоста та 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_buffering on; 
    }

    # Необов'язково: Обслуговувати статичні файли безпосередньо з Nginx
    location /static/ {
        root /var/www/my_app;
        expires 30d;
    }
}

Після створення цього файлу увімкніть його, створивши символічне посилання на sites-enabled:
sudo ln -s /etc/nginx/sites-available/my_reverse_proxy.conf /etc/nginx/sites-enabled/
Потім протестуйте конфігурацію Nginx та перезавантажте:
sudo nginx -t
sudo systemctl reload nginx

Розширена конфігурація зворотного проксі

Балансування навантаження

Nginx може розподіляти запити між кількома бекенд-серверами, використовуючи різні алгоритми балансування навантаження. Блок upstream визначає групу серверів.

# У nginx.conf або окремому файлі, включеному блоком http

upstream backend_servers {
    # Циклічний (за замовчуванням)
    server backend_server1.example.com:8080;
    server backend_server2.example.com:8080;
    server 192.168.1.100:8080; # Можна використовувати IP-адреси

    # Циклічний з вагами
    # server backend_server1.example.com:8080 weight=3;
    # server backend_server2.example.com:8080 weight=1;

    # Найменша кількість з'єднань
    # least_conn;

    # IP-хеш (липкі сесії на основі IP клієнта)
    # ip_hash;

    # Перевірки стану (потребує Nginx Plus або специфічних модулів)
    # server backend_server1.example.com:8080 max_fails=3 fail_timeout=30s;
}

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

    location / {
        proxy_pass http://backend_servers; # Посилання на блок upstream
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Термінація SSL/TLS

Nginx може термінувати SSL/TLS-з'єднання, розвантажуючи процес шифрування/розшифрування з бекенд-серверів. Для цього потрібні SSL-сертифікати та ключі.

server {
    listen 443 ssl;
    server_name secure.example.com;

    ssl_certificate /etc/nginx/ssl/secure.example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/secure.example.com.key;

    # Рекомендовані налаштування SSL для безпеки та продуктивності
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers 'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384';
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1h;
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;

    location / {
        proxy_pass http://backend_app_server:8080; # Бекенд може бути HTTP
        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 https; # Інформувати бекенд про оригінальний протокол
    }
}

# Необов'язково: Перенаправлення HTTP на HTTPS
server {
    listen 80;
    server_name secure.example.com;
    return 301 https://$host$request_uri;
}

Кешування

Nginx може кешувати відповіді від проксі-серверів, значно зменшуючи затримку та навантаження на бекенд для статичного або рідко змінюваного вмісту.

# У блоці http (поза будь-яким блоком server)
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m inactive=60m max_size=1g;
proxy_cache_key "$scheme$request_method$host$request_uri";

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

    location / {
        proxy_pass http://backend_app_server:8080;
        proxy_set_header Host $host;

        proxy_cache my_cache; # Увімкнути кешування для цього розташування
        proxy_cache_valid 200 302 10m; # Кешувати відповіді 200/302 протягом 10 хвилин
        proxy_cache_valid 404 1m;    # Кешувати відповіді 404 протягом 1 хвилини
        proxy_cache_bypass $http_pragma $http_authorization; # Не кешувати, якщо присутні ці заголовки
        proxy_no_cache $http_pragma $http_authorization; # Не використовувати кеш, якщо присутні ці заголовки

        add_header X-Proxy-Cache $upstream_cache_status; # Додати заголовок для перегляду статусу кешу
    }
}

Проксіювання WebSockets

Проксіювання WebSockets вимагає специфічної маніпуляції заголовками для обробки заголовків Upgrade та Connection для перемикання протоколу.

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

    location /ws/ {
        proxy_pass http://backend_websocket_server:8081;

        # Заголовки, специфічні для WebSocket
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_read_timeout 86400s; # Налаштувати за потреби для довготривалих з'єднань
    }
}

Базова конфігурація прямого проксі

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

Директиви конфігурації

• resolver: Вказує DNS-сервери, які Nginx повинен використовувати для розв'язання імен хостів.
• proxy_pass: Використовується в блоці location, але зі змінною для цільового URL.

# У блоці http (поза будь-яким блоком server)
resolver 8.8.8.8 8.8.4.4 valid=300s; # Google Public DNS, налаштувати за потреби

server {
    listen 3128; # Загальний порт для проксі-серверів
    listen [::]:3128;

    # Обмежити доступ для авторизованих клієнтів (наприклад, внутрішня мережа)
    allow 192.168.1.0/24;
    deny all;

    location / {
        proxy_pass $scheme://$host$request_uri;
        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_no_cache 1;
        proxy_cache_bypass 1;
    }
}

Клієнти потім налаштовують свої браузери або програми на використання nginx_ip_address:3128 як проксі.

Моніторинг та усунення несправностей

Ефективна робота Nginx як проксі вимагає можливостей моніторингу та усунення несправностей.

• Тестування конфігурації: Завжди перевіряйте файли конфігурації перед перезавантаженням Nginx.
  sudo nginx -t
• Стан служби: Перевірте стан служби Nginx.
  sudo systemctl status nginx
• Журнали доступу: Nginx записує кожен оброблений запит у журнал доступу, який зазвичай знаходиться за адресою /var/log/nginx/access.log. Ці журнали містять такі деталі, як IP-адреса клієнта, метод запиту, URL, код стану та розмір відповіді.
• Журнали помилок: Критичні помилки, попередження та інформація для налагодження записуються в журнал помилок, зазвичай за адресою /var/log/nginx/error.log. Відстежуйте цей файл на наявність проблем з конфігурацією, підключенням до бекенду або обмеженнями ресурсів.
• Стан бекенду: Переконайтеся, що бекенд-сервери працюють і доступні з сервера Nginx. Використовуйте такі інструменти, як curl або ping з машини Nginx для перевірки підключення.
• Мережеве з'єднання: Перевірте мережеві шляхи між клієнтами, Nginx та бекенд-серверами.
• Використання ресурсів: Моніторте ЦП, пам'ять та ввід/вивід диска на сервері Nginx для виявлення вузьких місць.