Обмеження частоти запитів у nginx: де сервер ламається без лімітів
Сплеск запитів рідко приходить рівномірно. Найчастіше це один клієнт, зірваний скрипт обходу каталогу або зовнішній робот, який відкриває сотні паралельних з'єднань і не відпускає їх до закінчення часу очікування.
Сервер при цьому формально живий: процес запущений, порт слухає, але обробники зайняті одним джерелом.
Пул обробників — спільний і кінцевий ресурс. Коли всі доступні обробники чекають на відповідь від бази або зовнішнього сервісу на важких запитах, нові звернення стають у чергу на прийом.
Черга зростає швидше, ніж її встигають розбирати, а відгук для інших клієнтів зсувається з частки секунди до десятків секунд.
Далі вмикається каскад: користувачі не дочікуються й ідуть, а автоматичні повторні спроби додають навантаження. У логах це виглядає однаково — обрив з'єднань під піком при незмінному коді, зростання частки помилок і попереджень про нестачу вільних обробників. Причина не в залізі, а у вичерпанні пулу обробників і накопичених очікуваннях.
Зовнішній екран перед сервером цю картину не розрізняє: він ріже всіх підряд, включаючи повідомлення платіжної системи й обхід пошукових роботів.
Обмеження частоти запитів nginx працює ближче до застосунку — рахує частоту за ключем (адреса, сесія, токен доступу, шлях) і віддає зайвим коректну відповідь замість місця в черзі.
Перевантаження веб-сервера перестає бути загальною подією: обмеження отримує конкретне джерело, інші обслуговуються як звичайно. Розбираємо, як налаштовується такий захист від сплеску запитів і де проходить межа між ним і блокуванням своїх же користувачів.
Що дає обмеження частоти запитів на вході
Час відгуку перестає зростати під піком
Правило на вхідному проксі (nginx) працює раніше за застосунок: зайвий потік отримує коротку відмову й не займає робочі процеси. Черга не накопичується, тому стабільний час відгуку тримається й на піку — у годину розсилки або старту акції замість зростання в рази. Пороги виставляються за навантажувальним профілем, знятим на реальному трафіку, а не після аварії.
Відсікаються перебір паролів і масовий парсинг каталогу
Окреме правило на форму входу рахує не лише частоту, а й частку невдалих спроб з однієї адреси — серія з сотень помилок не перетворюється на підбір.
Для каталогу поріг м'якший: відсікання парсерів залишає людям повний доступ, а скрипту з однієї адреси — лише частину сторінок за хвилину. Пошукові роботи йдуть за окремим списком і працюють без обмежень.
Відмова одного клієнта не валить інших
Ізоляція клієнта потрібна там, де за однією адресою стоїть офіс або вивантаження партнера: без неї один сплеск займає всі робочі процеси й валить сервіс для всіх. З розділенням за адресою, ключем доступу та сесією впирається лише порушник, інші продовжують працювати. Так іде цілий клас відмов — не «сервер упав», а «конкретне джерело вичерпало свою квоту».
Обмеження частоти запитів у nginx: рівні захисту та їхні обмеження
Ліміти розміщують на кількох рівнях, і кожен закриває свій клас перевантаження. Чим ближче лічильник до клієнта, тим дешевша відмова: запит, зрізаний на зовнішньому проксі, не доходить ні до застосунку, ні до бази.
Де ставити ліміт
| Рівень | Коли підходить | Обмеження |
|---|---|---|
| Зовнішній проксі перед входом | Масові сплески, сканери, перебір за формами входу | Видно лише адресу клієнта: за офісною мережею квота ділиться на всіх, розподілений потік її обходить |
| Вхідний nginx: ліміт за частотою та за одночасними з'єднаннями | Робочий варіант для сайту й API | Зона та ключ обліку мають бути узгоджені; на кількох вузлах без спільного сховища лічильники незалежні, сумарний ліміт розмивається |
| Застосунок або шлюз | Ліміти за акаунтом, токеном, роллю, окремим маршрутом | Рахується після розбору запиту — дорожче; правила розходяться з конфігом балансувальника |
Ключ обліку — головний вибір: адреса клієнта, адреса з урахуванням реального джерела за проксі, сесія або токен. Чим точніший ключ, тим менше хибних спрацьовувань на спільних адресах.
Чого ліміти не вирішують
Ліміт частоти — це про чесне навантаження та грубі сплески, а не про захист загалом. Він не зупинить повільний перебір малою інтенсивністю з безлічі адрес і не врятує від дорогого запиту, який вкладається в квоту, але навантажує базу. Бота від клієнта він теж не відрізнить, якщо ключ — лише адреса.
Тому ліміти працюють у зв'язці з кешуванням, таймаутами, обмеженням розміру тіла запиту та розбором логів: кожне закриває свою ділянку, і окремо жодне з них не дає стійкості.
Етапи впровадження обмежень: від аудиту до регламентів
Починаємо з аудиту вхідного трафіку: розбираємо логи зворотного проксі, знаходимо маршрути та джерела з основним обсягом, пікові інтервали й частку службових запитів. З цього збираємо профіль навантаження — темп, який сервіс тримає із запасом, і точки, де починається деградація.
- Аудит вхідного трафіку — логи, маршрути, джерела, пікові інтервали.
- Профіль навантаження — який темп сервіс перетравлює, а який веде до зростання часу відповіді.
- Схема зон і порогів — де ставити ліміт: на вході в кластер, на окремому сервісі або на дорогому маршруті, з різними порогами для авторизованих і анонімних клієнтів.
- Налаштування правил — самі ліміти, коди відповіді, заголовки із залишком квоти, поведінка при перевищенні.
- Перевірка на тестовому контурі — правила проганяємо на копії оточення, щоб побачити, кого саме обмежує ліміт.
- Навантажувальний прогін і передача регламентів — тримаємо пік, звіряємо метрики з планом, віддаємо команді документ із порогами та порядком їх перегляду.
Як проходить перевірка під піком
Прогін повторює профіль навантаження з аудиту, включаючи короткі сплески від одного джерела. Перевіряємо, що ліміт спрацьовує раніше, ніж зростає час відповіді в інших, і що легітимний трафік під поріг не потрапляє — інакше обмеження б'є по своїх.
Що потрібно з вашого боку
Доступ до логів і метрик сервісу, вікно для перевірки на копії оточення та контакт чергового, який підтвердить пороги. Решта — наша робота: правила, прогін, регламент і розбір результатів.
Що залишається у вас: конфігурації, схеми зон і регламенти
Ми передаємо не «налаштований сервер», а робочий комплект: конфігурації обмеження частоти запитів у nginx, схему зон і порогів, перелік довірених адрес, інструкцію черговому та регламент реакції на інцидент.
Усе лежить у репозиторії замовника, зміни проходять рев'ю й розкочуються за звичайним процесом постачання.
Склад пакета документів
- Конфігурації з коментарями: за яким ключем рахується ліміт (адреса, токен, cookie) і які зони оголошені.
- Схема зон і порогів — таблиця «зона → ліміт → сплеск → код відповіді», щоб значення змінювалися усвідомлено, а не навмання.
- Перелік довірених адрес і підмереж: білі списки для моніторингу, платіжних колбеків, інтеграцій та офісних мереж.
- Інструкція черговому: як відрізнити легітимний сплеск від атаки та як увімкнути щадний режим.
- Регламент реакції: хто знімає ліміт, кого повідомляють, коли поріг підвищують, а коли ріжуть жорсткіше.
- Сценарії навантажувального прогону — на них підтверджується, що законні піки проходять, а грубий перебір отримує відмову.
- Журнал змін лімітів: дата, причина, хто погодив, — видно, звідки взялося поточне значення.
Як це підтримувати без нас
Пороги живуть в одному файлі та змінюються без переписування логіки. Інструкція й регламент оновлюються разом зі схемою, тому новий інженер входить у контур за вечір, а не за тиждень.
Кейс: як інтернет-магазин пройшов пік розпродажу
Піковий розпродаж — день, коли інфраструктура інтернет-магазину перевіряється по-справжньому: потік зростає в рази за хвилини, і все, що не витримало, видно одразу.
Нижче — цифри з вивантажень моніторингу до й після впровадження обмеження частоти запитів на вхідному вузлі на nginx.
Що було до
У момент старту акції вхідний вузол приймав весь потік без розбору: частка успішних запитів падала до 62%, час відгуку в піці сягав 9 секунд — покупець закривав каталог раніше, ніж отримував відповідь.
Частину трафіку становили боти: вони обходили каталог і набивали кошики, займаючи всі робочі процеси застосунку.
Серверних помилок стало в 40 разів більше, ніж у звичайний день, а розбиралися з цим уже після акції, за логами.
Що стало після
Ліміти розвели за рівнями: жорсткий поріг на адресу джерела для пошуку й оформлення замовлення, м'який — із чергою та затримкою для каталогу й картинок, окремий профіль для пошукових роботів.
Частка успішних запитів на піці зросла до 99,4%, час відгуку не виходив за 1,2 секунди, кількість серверних помилок скоротилася на порядок — за того ж потоку покупців.
Спрацьовування видно у вивантаженні моніторингу за іменем правила, тому хибне блокування знімають однією правкою, без перезапуску сервісу.
Пороги підбиралися за реальним профілем трафіку та переглядалися після кожної репетиції навантаження; конфігурація версіонується разом з рештою інфраструктури, і на наступному розпродажі результат відтворюється.
Чим загальний ліміт відрізняється від ліміту на конкретну адресу
Загальний ліміт задає одну стелю на весь сервіс: ключем обліку слугує константа, тому всі запити падають у спільний лічильник. Такий режим ловить рівномірний надлишковий потік та аварії, коли трафік виріс через збій у клієнта або помилку в інтеграції.
Зате він пропускає перекіс: якщо одна адреса забирає дев'ять десятих квоти, інші отримують відмови, хоча сумарний поріг формально не перевищено.
Ліміт за адресою клієнта рахує кожне джерело окремо, і перевищення одним не б'є по інших. Тут видно часті опитування, автоматичний збір даних, забутий тестовий контур із повторними запитами.
А от розподілений потік із сотень адрес такий режим пропускає: кожен вкладається у свою квоту, а сумарне навантаження на сервіс залишається руйнівним.
Вибір ключа обмеження залежить від того, що захищаємо: для зовнішнього інтерфейсу беруть адресу, для внутрішніх викликів — ідентифікатор клієнта або маршрут, для дорогих операцій — комбінацію ознак.
Поруч налаштовують режими обліку запитів: окремо середню швидкість і окремо допустимий сплеск. Інакше легітимний запуск застосунку, який одразу шле серію запитів, відкидається нарівні з атакою.
На практиці обидва режими тримають разом: загальний працює запобіжником на весь сервіс, ліміт за адресою — захистом від конкретного джерела.
Що пропускає ліміт, залежить і від того, що вважати одним запитом: якщо звернення до кешованих маршрутів у підрахунок не йдуть, поріг можна опустити без ризику для живих користувачів.
Технічні сумніви: ключ клієнта, сплески та білі списки
П'ять сумнівів, які виринають перед обмеженням частоти запитів — щодо кожного є відпрацьоване рішення.
Що брати ключем обліку: адресу, токен чи маршрут?
Базовий ключ — адреса клієнта, але за проксі він підмінюється, тому беремо реальну адресу із заголовка пересилання. Для API ключ будується за токеном, для важких маршрутів — за парою «адреса + маршрут»: сплеск у пошуку не валить вхід.
Як відрізнити хибне спрацьовування від справжнього навантаження?
Спочатку режим спостереження: правила рахують запити й пишуть у лог, але не відхиляють. За тиждень видно, якій частці клієнтів дістається відмова, і за якими маршрутами. Найчастіше це сторінки з підвантаженням ресурсів — ключ або сплеск правимо точково.
Чи не почнуть звичайні відвідувачі отримувати відмови?
Спокійний перегляд дає поодинокі запити за секунду, ліміт ставимо на порядок вище. Сплеск допускає коротку серію, тому сторінка з десятком файлів вантажиться повністю. Відмову отримує автоматика, а не людина.
Чи можна увімкнути на живому сервісі без простою?
Конфігурація застосовується перечитуванням, уже відкриті з'єднання не рвуться. Правило вводимо спочатку на одному маршруті або частині вузлів, дивимося на частку відмов і час відповіді, потім розкочуємо. Відкат — зняття правила тим самим перечитуванням.
Як бути з довіреними джерелами?
Моніторинг, службові перевірки та партнерські інтеграції виносимо в окремі зони з високими порогами, а не в повне виключення. Довірена адреса не стає дірою: за аномалії обмеження все одно спрацює. Список живе поруч із правилами та проходить рев'ю за кожної зміни.
Обговоримо ваше навантаження та повернемося з оцінкою й планом
Обговорення задачі щодо обмеження частоти запитів іде швидше, коли є факти про навантаження, а не лише опис симптомів.
Розбираємо їх разом із топологією контуру та домовляємося, на якому рівні ставити ліміти: на вході перед проксі, всередині нього за маршрутами чи в самому застосунку.
Корисно підготувати до розмови:
- профіль піків: добові та тижневі максимуми, сплески від розсилок, частка анонімного й службового трафіку;
- схема контуру: де стоїть балансувальник і проксі, скільки вузлів застосунків, чи є кеш і черга;
- перелік публічних точок входу й методів, які не можна обмежувати однаково;
- історія інцидентів: коли й на чому падало, які запити виглядали як перебір або масовий парсинг;
- очікуване зростання: заплановані запуски, сезонність, нові інтеграції та мобільні клієнти;
- доступ до тестового контуру, щоб перевіряти правила до викладки на робочий.
З цього розбору складається оцінка обсягу робіт і план впровадження за етапами. Починаємо з режиму спостереження: правила рахують перевищення, але не блокують, і видно, кого зачіпає.
Потім вмикаємо відмову зі зрозумілими кодами відповіді та заголовками, задаємо окремі пороги для критичних маршрутів. Наступні кроки — пілот на одному сервісі, замір частки відбитих запитів і часу відповіді, розкочування на решту вузлів.
