Налаштування зворотного проксі Nginx: балансування, SSL, WebSocket

Налаштування Nginx reverse proxy: де ламається відгук

Коли весь трафік застосунку йде через один вхідний вузол, зворотний проксі стає єдиною точкою входу і водночас точкою відмови: недоступний він — недоступні всі сервіси одразу, включно з адмінкою та моніторингом.

Найчастіше це не збій обладнання, а наслідок ручного редагування конфігурації: правку вносять прямо на вузлі, застосовують перезапуском замість плавного перезавантаження — і отримують обрив з’єднань на середині запиту. Найдовше цього не помічають там, де тримаються довгі сесії: вивантаження файлів, чати, стримінг.

Типова схема поломки виглядає так: у блоці upstream одна адреса, без резервних вузлів і без повтору запиту на сусідній сервер у разі помилки. Впав інстанс застосунку — весь трафік іде в помилки, бо перемикатися нікуди.

Поруч — редиректи, зібрані умовними блоками всередині location, продубльовані server-блоки, сертифікати, які продовжують вручну і одного разу не продовжують. У логах це один сплеск п’ятисотих відповідей на тлі падіння частки успішних.

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

Далі — кілька серверів застосунку за одним іменем upstream, повтор на інший вузол у разі помилки, окрема перевірка живучості, термінація TLS з автоматичним продовженням сертифікатів.

Довгі з’єднання та WebSocket ідуть окремим маршрутом: свої таймаути простою, вимкнене буферизування, проброс заголовка Upgrade. Без цього чат і потокові відповіді відвалюються через хвилину тиші, хоча звичайні сторінки при цьому відкриваються нормально.

Розбираємо, як це закривається: від схеми маршрутизації та обробки відмов вузла до автоматизації викату конфігурації.

Що дає керований вхід: швидкість і стійкість

Керований вхід — єдина точка, де вирішується, куди піде запит. Зворотний проксі на nginx розподіляє їх по пулу застосунків з урахуванням живучості вузлів: поки сервер відповідає в заданому порозі, він отримує свою частку, у разі деградації виводиться з ротації сам.

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

Падіння окремого вузла перестає бути подією. Перевірки стану з налаштовуваним інтервалом помічають того, хто не відповів, за секунди, недоступний екземпляр виключається, його запити йдуть на решту, а той, що повернувся, приймається в пул лише після підтвердження готовності. Клас відмов «одна машина з п’яти впала — половина сторінок не відкривається» зникає зовсім.

Шифрування трафіку закривається на вході: сертифікати продовжуються автоматично, застарілі протоколи вимикаються, внутрішні сервіси спілкуються всередині периметра без зайвих витрат на криптографію. Зникає ручна робота з випуску сертифікатів і типова аварія «прострочили — сайт недоступний».

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

Схеми балансування: варіанти, обмеження, нюанси

Один вхідний вузол із Nginx — найпростіша схема і водночас найкрихкіша: планове оновлення конфігурації або перезапуск процесу зупиняє весь зовнішній трафік, а разом із ним термінацію шифрування й відкриті сесії WebSocket. Поки вузол один, будь-яка правка вхідної конфігурації — це вікно недоступності.

Вибір між схемами визначається трьома питаннями: чи зберігає застосунок стан сесії, скільки вхідних точок готовий тримати контур і чи є на периметрі керований балансувальник.

Схему вибирають не за «правильністю», а за допустимим класом відмови. На кластерному контурі Nginx зазвичай залишають на рівні застосунку — маршрутизація, кеш, обмеження частоти, — а розподіл трафіку віддають зовнішньому рівню.

Порядок впровадження: від аудиту трафіку до передачі

Порядок робіт вибудований так, щоб кожний наступний щабель спирався на дані попереднього, а не на припущення. Ми ніколи не починаємо з правки конфігів: спочатку потрібно зрозуміти, який трафік піде через проксі і що саме ламається зараз.

Нижче — послідовність, за якою впровадження проходить передбачувано, зі збереженням можливості відкотитися на будь-якому кроці.

1. Аудит трафіку. Знімаємо карту: домени й субдомени, частки запитів за типами, тривалість з’єднань, обсяг тривалих WebSocket-сесій, пікові вікна. Окремо фіксуємо, де зараз термінується TLS і куди вказує DNS — це визначає схему перемикання.
2. Проєктування схеми. Визначаємо точки термінації сертифікатів, набори серверів upstream, політику балансування, таймаути для довгих з’єднань, порядок обробки заголовків. Узгоджуємо схему з вашою командою до першої правки конфігурації.
3. Налаштування в тестовому контурі. Збираємо конфігурацію за блоками й перевіряємо синтаксис до застосування. Піднімаємо копію схеми на окремому стенді, щоб зловити помилки без впливу на робочі запити.
4. Перевірка під навантаженням. Подаємо профіль, близький до бойового, включно з WebSocket і повільними відповідями застосунку. Дивимося, як зростає затримка, чи тримаються з’єднання під час відмови одного сервера, скільки часу займає перемикання.
5. Перемикання без простою. Переносимо трафік поступово: спочатку частину запитів, потім повний обсяг. Стара схема залишається робочою й готовою до повернення, поки нові метрики не підтвердять стабільність.
6. Передача в експлуатацію. Віддаємо конфігурації в репозиторії, схему зв’язків, політики оновлення сертифікатів, дашборди й правила алертів, інструкцію з відкату. Проводимо розбір із черговою командою, щоб типові збої закривалися без нас.

Конфігурації, схеми маршрутизації та політики доступу

Налаштування зворотного проксі не закінчується робочим конфігом на бойовому вузлі.

Ми передаємо команді замовника набір артефактів, за якими інфраструктуру можна відтворити, розвивати й передати іншому інженеру — без розбору «магії» прямо на сервері й без читання історії листування.

• Конфігурації в системі контролю версій — розбиті за змістом: глобальні параметри, описи апстримів, окремий блок на кожен домен. Зміни проходять рев’ю і спочатку викочуються на стенд.
• Схема маршрутизації — шлях запиту від точки входу до конкретного сервісу: які домени й шляхи куди проксуються, де термінується TLS, за яких умов трафік іде на резервний апстрим.
• Політики доступу — обмеження за адресами й підмережами для адміністративних зон, правила автентифікації, явний поділ публічних і внутрішніх маршрутів.
• Ліміти підключень і таймаутів — гранична кількість одночасних з’єднань на вузол і на клієнта, розміри буферів, час очікування відповіді апстриму, пороги захисту від сплесків трафіку.
• Правила для WebSocket і тривалих з’єднань — коректні заголовки перемикання протоколу, окремий апстрим без буферизації, збільшені таймаути для таких маршрутів.
• Регламент обслуговування — порядок продовження сертифікатів, ротації логів, перезавантаження конфігурації без розриву активних з’єднань і відкату на попередню версію.
• Карта моніторингу — які метрики знімаються з проксі, які значення вважаються аварійними, куди йдуть оповіщення і хто їх розбирає.

Кожен пункт перевіряється на стенді до переведення трафіку, тому після запуску в команди залишається не налаштований сервер, а керована схема з зрозумілими точками зміни.

Кейс: як прибрали простій під час викочування релізів

До перебудови реліз викладали перезапуском єдиного вузла: кожне викочування давало 4–6 хвилин повної недоступності, і вікно під нього вибирали вночі, щоб укластися в мінімум трафіку.

Відмова вузла означала простій до приходу чергового — відновлення займало десятки хвилин і тримало на зв’язку всю команду.

Застосунок і точку входу розвели: перед сервісом з’явився шар зворотного проксі на Nginx з групою з трьох вузлів.

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

Метрики до і після

Перевірку доступності перенесли в проксі: вузол не відповідає два цикли — трафік іде на живі, а той, що повернувся, знову приймає навантаження. Правила й сертифікати оновлюємо м’яким перезавантаженням, тому правки не обривають активні з’єднання.

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

Чим відрізняється зворотний проксі від балансувальника?

Строго кажучи, це не два різних інструменти, а дві ролі одного вузла на вході. Зворотний проксі — точка входу: він єдиний приймає з’єднання від клієнта й перенаправляє його на застосунок.

Балансувальник — окремий випадок тієї самої ролі, коли застосунків більше одного і потрібно вибрати, кому віддати конкретний запит.

Зворотний проксі відповідає за все, що відбувається до маршрутизації: термінує TLS і продовжує сертифікати, підставляє заголовки Host і X-Forwarded-*, обмежує розмір тіла й частоту запитів, стискає відповіді, кешує статику, пропускає через себе Upgrade для WebSocket. Це керування входом, а не розподіл.

Балансування починається там, де в конфігурації з’являється upstream з кількома серверами: алгоритм вибору (по колу, за кількістю активних з’єднань, прив’язка за IP), перевірки доступності, виведення вузла, що впав, з ротації, повтор запиту на сусідній сервер, утримання сесії. Без цього списку слово «балансування» нічого не означає — залишається одне ім’я хоста.

У Nginx обидві ролі живуть в одному конфігу: блок upstream підключається до server, і той самий вузол, що термінував TLS, починає розподіляти трафік. Тому питання стоїть не «проксі чи балансувальник», а скільки у вас екземплярів застосунку і чи потрібна їм спільна точка входу.

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

Сертифікати, тривалі з’єднання та ліміти: сумніви

Перед запуском замовники ставлять одні й ті самі запитання: що буде, коли спливе строк дії сертифіката, чи витримає проксі тривалі з’єднання і чи не виявиться службовий інтерфейс відкритим назовні. Нижче — короткі відповіді, а деталі закриваємо на етапі проєктування конфігурації.

Як поводитимуться веб-сокети за зворотним проксі?

Тривале з’єднання потребує явних заголовків перемикання протоколу й збільшеного часу очікування — інакше канал обривається на мовчанні. Виносимо веб-сокети в окремий блок маршрутизації й підбираємо таймаути під реальний профіль трафіку.

Що з обмеженнями за кількістю одночасних підключень?

Рахуємо ліміти за кількістю одночасних клієнтів і запасом на сплеск, а не «на око», й обмежуємо частоту запитів з однієї адреси. За пікового навантаження черга не зростає, а штатні користувачі не бачать відмов.

Чи залишаються відкритими службові порти й панелі керування?

Ні. Панель і метрики слухають лише на локальній адресі, назовні дивиться єдиний вхід. Адміністративні розділи закриті списком дозволених адрес і окремою автентифікацією, решту відсікає міжмережевий екран.

Обговоримо вашу схему і повернемося з оцінкою

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

• Список доменів і субдоменів, які підуть через проксі, і де зараз термінується TLS: на самому nginx, на балансувальнику вище або всередині застосунку.
• Пул бекендів: адреси й порти сервісів, їхня кількість і бажаний спосіб розподілу навантаження — по колу, за кількістю активних з’єднань, з прив’язкою клієнта до сервера.
• Вимоги до довгих з’єднань: чи потрібні WebSocket, стримінг відповіді, події, і який розрив зв’язку вважається неприпустимим.
• Схема відмовостійкості: один вузол, пара з плаваючою адресою або кілька за зовнішнім балансувальником; чи потрібен плавний перезапуск конфігурації без обриву активних запитів.
• Сертифікати й порядок їхнього випуску: зовнішній чи внутрішній центр, автооновлення, один спільний або окремий на кожен домен.
• Спостережуваність: куди пишуться логи доступу й помилок, які метрики знімаються, чи є збирач логів і на які пороги налаштовані оповіщення.
• Обмеження й доступи: дозволені мережі, обмеження частоти запитів, захист від сплесків, хто видає доступи до серверів і змінює конфігурацію.

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

Підтримка після запуску йде окремим пунктом — оновлення сертифікатів, ротація конфігурацій, чергування за інцидентами.

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