Модуль 11

Reverse proxy: основи

Ось урок, згенерований у стилі CS50, спеціально для тебе. Уяви, що ми зараз в аудиторії Sanders Theatre, я ходжу сценою, жестикулюю, а за мною — величезний екран із кодом. Поїхали!

🎓 CS50: Reverse Proxy (Зворотний проксі)

Привіт, світе! 👋

Сьогодні ми зазирнемо під капот сучасної веб-архітектури. Ми часто пишемо код: створюємо сервери на Python, Node.js або Go. Але коли ви заходите на Google, Facebook чи Netflix, ви ніколи не спілкуєтесь із цими серверами напряму.

Між вами та "серцем" програми стоїть посередник. Невидимий герой.

Тема сьогоднішнього уроку — Reverse Proxy (Зворотний проксі).

1. 🔥 Вступ: проблема та мотивація

Уявіть, що ви — генеральний директор величезної корпорації. У вас у кабінеті зберігаються найважливіші документи (ваша база даних і логіка програми).

Питання до вас: Чи дозволите ви будь-якому клієнту з вулиці заходити просто у ваш кабінет, сідати на стіл і вимагати підписати папери?

Звісно, ні! Це: 1. Небезпечно (хтось може щось вкрасти або зламати). 2. Неефективно (якщо прийде 1000 людей одночасно, ви просто луснете від напруги). 3. Хаотично (ви маєте займатися стратегією, а не відповідати на дзвінки "де туалет?").

Що ви робите? Ви наймаєте професійного секретаря на рецепцію.

Клієнти приходять на рецепцію (публічна адреса). Секретар (Reverse Proxy): * Перевіряє, чи є у них перепустка (Security). * Вирішує, до якого відділу їх направити (Routing). * Якщо ви зайняті, просить почекати або направляє до вашого заступника (Load Balancing).

Без Reverse Proxy ваш маленький сервер на Node.js, який ви запустили на порту 3000, "голий" перед усім інтернетом. Він змушений сам шифрувати трафік (HTTPS), сам відбивати атаки й сам обробляти тисячі картинок. Він швидко впаде.

Нам потрібен цей секретар. Нам потрібен Nginx, HAProxy або Traefik.

2. 🧠 Теоретична база (без сухої академічності)

Давайте розберемося з термінологією, щоб не плутатися.

Forward vs Reverse Proxy

Багато хто чул про "проксі", щоб обійти блокування сайтів. * Forward Proxy (Прямий проксі): Захищає клієнта. Ви (клієнт) ховаєтесь за проксі, щоб сервер не знав, хто ви. (Аналогія: Ви надсилаєте листа анонімно через друга). * Reverse Proxy (Зворотний проксі): Захищає сервер. Сервер ховається за проксі, щоб клієнт не знав, де саме і скільки серверів обробляють запит. (Аналогія: Ви дзвоните в банк, але не знаєте, який саме оператор підніме слухавку).

Що робить Reverse Proxy "під капотом"?

  1. Термінація SSL/TLS: Розшифровує захищений трафік (HTTPS) і передає "чистий" запит вашому додатку. Ваш код не витрачає ресурси на криптографію.
  2. Балансування навантаження (Load Balancing): Якщо у вас 3 сервери, проксі роздає завдання по черзі: ти — першому, ти — другому, ти — третьому.
  3. Кешування: Якщо 100 людей просять одну й ту ж картинку, проксі віддає її зі своєї пам'яті, навіть не турбуючи основний сервер.
  4. Безпека: Приховує реальну IP-адресу вашого бекенду.

❗️ Запам'ятайте головне: Клієнт думає, що спілкується з Reverse Proxy. Він навіть не здогадується, що за ним стоїть ціла армія мікросервісів.

3. 🧪 Приклади (на базі Nginx)

Давайте подивимось на конфігурацію найпопулярнішого у світі веб-сервера — Nginx.

Приклад 1: Найпростіший "Тунель"

Уявіть, що ваш додаток працює локально на порту 3000. Ми хочемо, щоб світ бачив його на порту 80 (стандартний HTTP).

server {
    listen 80;
    server_name my-cool-app.com;

    location / {
        proxy_pass http://localhost:3000;
    }
}

Питання до студента: Що станеться, якщо я напишу в браузері my-cool-app.com/users? Відповідь: Nginx отримає запит, побачить location /, і перешле його на http://localhost:3000/users. Ваш додаток відповість, Nginx забере відповідь і віддасть браузеру.

Приклад 2: Маршрутизація (Секретар сортує пошту)

У нас є два різні додатки: 1. Frontend (React) на порту 3000. 2. Backend API (Python) на порту 5000.

Як об'єднати їх на одному домені, щоб не було проблем з CORS?

server {
    listen 80;
    server_name my-shop.com;

    # Весь звичайний трафік — на фронтенд
    location / {
        proxy_pass http://localhost:3000;
    }

    # Все, що починається з /api — на бекенд
    location /api/ {
        proxy_pass http://localhost:5000;
    }
}

Чому результат саме такий? Nginx дивиться на URL. Якщо бачить /api/v1/users, він знає: "Ага! Це для Python-сервера". Якщо бачить /about, віддає React. Для користувача це виглядає як один цілісний сайт.

Приклад 3: Балансування (Робота в команді)

У вас "Чорна п'ятниця". Один сервер не витримує. Ви запустили три копії бекенду.

upstream my_backend {
    server localhost:5001;
    server localhost:5002;
    server localhost:5003;
}

server {
    listen 80;

    location / {
        proxy_pass http://my_backend;
    }
}

Тут ми створили групу upstream. Nginx автоматично буде використовувати алгоритм Round Robin (по колу), розподіляючи запити рівномірно.

4. 🛠 Практична частина

А тепер ваша черга! Уявіть, що ви DevOps-інженер.

Завдання 1: Setup У вас запущено Python-сервер на порту 8000. Напишіть блок server для Nginx, який приймає запити на порту 80 і пересилає їх на 8000.

Завдання 2: "Тільки для своїх" Змініть конфігурацію так, щоб доступ до адмінки (/admin) був дозволений тільки з однієї конкретної IP-адреси (наприклад, 192.168.1.50), а для всіх інших — помилка 403 Forbidden. (Підказка: погугліть ngx_http_access_module або allow/deny).

Завдання 3: Виправити помилку Студент написав конфіг, але скаржиться, що бекенд не бачить реальну IP-адресу користувача (всі запити нібито від 127.0.0.1). Який заголовок (header) треба додати в location /, щоб передати IP клієнта далі? (Це класична проблема!)

Завдання 4: Міні-кейс "Переїзд" Ваш старий блог був на /blog, а новий лежить на окремому сервері new-blog-engine:4000. Але ви не хочете втрачати старі посилання. Налаштуйте Nginx так, щоб він не просто пересилав трафік, а робив Redirect (301) зі старої адреси на нову, якщо користувач заходить на корінь старого блогу.

5. 💡 Мислення як у розробника

Як думає досвідчений архітектор, налаштовуючи Reverse Proxy?

  1. "Ніколи не довіряй вхідним даним". Новачки часто просто пересилають усе підряд. Профі налаштує ліміти (Rate Limiting). Наприклад, "не більше 10 запитів на секунду з однієї IP". Це захистить від DDoS-атак початкового рівня.

  2. Заголовки — це важливо. Коли проксі пересилає запит, інформація губиться. Профі завжди додає:

    • Proxy_set_header Host $host; (щоб бекенд знав, на який домен прийшли)
    • Proxy_set_header X-Real-IP $remote_addr; (щоб знати, хто прийшов)

  3. Статика — окремо, логіка — окремо. Не змушуйте Node.js чи Django віддавати картинки та CSS. Це повільно! Налаштуйте Nginx так, щоб він віддавав файли з папки /var/www/static напряму, а до бекенду звертався тільки за даними. Це пришвидшить сайт у рази.

6. 🧩 Підсумок

Отже, що ми сьогодні зробили? Ми взяли ваш вразливий, одинокий сервер і поставили перед ним потужного охоронця та адміністратора — Reverse Proxy.

Тепер ви вмієте: * ✅ Ховати внутрішню архітектуру від зовнішнього світу. * ✅ Об'єднувати різні сервіси (API + Frontend) на одному домені. * ✅ Розумієте принцип балансування навантаження.

Навіщо це було потрібно? Тому що в реальному production-середовищі "голий" додаток не виживає. Reverse Proxy — це стандарт індустрії.

🔜 У наступній серії: Ми розберемося, як цей "секретар" може не просто пересилати листи, а й читати їх і кешувати відповіді, щоб ваш сервер міг піти у відпустку, поки сайт продовжує працювати. Готуйтеся до теми Caching & CDN!

Це був CS50. До зустрічі! 🖐️

← До списку уроків Наступний урок →