Розробник SaaS-рішення виявив, що увімкнення Cloudflare Bot Fight Mode для кожного домену у своєму обліковому записі зупинило API-трафік на цілий місяць, через що платні клієнти не могли користуватися основними функціями продукту.

Проблема виникла, коли розробник помітив раптове вирівнювання метрик використання. Нові реєстрації продовжували надходити, але кількість активних сесій перестала зростати. Після тижнів переписування коду та налагодження з'ясувалося, що причиною став один перемикач безпеки: Cloudflare Bot Fight Mode маркував власний AWS Lambda endpoint SaaS-рішення як шкідливого бота і блокував його.

Як одне налаштування зламало цілий сервіс

Стек розробника базувався на викликах server-to-server. Внутрішня функція Lambda регулярно надсилала дані назад на публічний домен SaaS — це поширений патерн у сучасних мікросервісних архітектурах. Bot Fight Mode перевіряє або блокує запити, які схожі на автоматизовані скрейпери, захищаючи контентні сайти від збору даних.

Коли цей режим було увімкнено для всіх зон, Cloudflare сприйняв вихідний запит Lambda як іншого автоматизованого клієнта. Запит так і не дійшов до додатка, і оскільки блокування відбулося на рівні edge, інструменти моніторингу SaaS не зафіксували помилки — трафік просто зник. Використання CPU у Cloudflare Workers різко зросло, що змусило розробника запідозрити зовнішній скрейпер, а не власний бекенд.

Лише після вивчення логів Cloudflare він побачив записи про блокування Bot Fight Mode, які відповідали діапазону IP-адрес Lambda. Він вимкнув цю функцію для відповідних зон, і API-трафік відновився, повернувши метрики використання до норми.

Чому ця помилка важлива для SaaS-операторів

  • API-орієнтовані продукти потребують відкритих каналів server-to-server. Bot Fight Mode передбачає, що основним трафіком є запити від людей через браузери для отримання HTML, зображень або статичних активів. SaaS-платформи, які надають API, вебхуки або внутрішні callback-и, можуть бути обмежені або заблоковані без появи видимого коду помилки на рівні додатка.
  • Глобальні налаштування безпеки рідко підходять для всіх типів навантаження. Застосування єдиної конфігурації Cloudflare до всіх доменів означає, що кожен сайт розглядається так, ніби він має однакову модель загроз. Контентні сайти, форуми та бекенди SaaS мають дуже різні вимоги до безпеки.
  • Тихі збої знижують дохід. Система сповіщень розробника не спрацювала, оскільки заблоковані запити ніколи не досягали додатка. Лише падіння метрик залученості користувачів натякнуло на проблему. Без проактивного перегляду логів на рівні edge подібні проблеми можуть залишатися непоміченими довгий час.

Що розробники можуть зробити, щоб уникнути такої ж долі

  1. Проведіть аудит профілю трафіку кожної зони. Перед увімкненням Bot Fight Mode перелічіть типи запитів, які очікує ваш домен: браузери користувачів, виклики API, вебхук-callback-и або виклики внутрішніх сервісів. Якщо будь-який із них є критично важливим для основної функціональності, вважайте зону «API-first» і мінімізуйте налаштування захисту від ботів.
  2. Тестуйте зміни в стейджинг-середовищі. Cloudflare дозволяє застосовувати налаштування до одного піддомену або стейджинг-зони. Переконайтеся, що легітимна автоматизація все ще працює, перш ніж впроваджувати зміни глобально.
  3. Моніторте логи на рівні edge як частину вашого стека спостережуваності (observability). Передавайте логи Cloudflare firewall та bot-mitigation у SIEM, Loki або будь-який сервіс агрегації. Корелюйте сплески заблокованих запитів із падінням метрик додатка, щоб вчасно виявляти «тихі» збої.
  4. Зробіть налаштування безпеки такими, що можна скасувати. Майте задокументований план відкату. Якщо нове правило спричиняє неочікувану поведінку, спочатку вимкніть його та підтвердьте зміни, перш ніж витрачати час на написання коду для обходу проблеми.
  5. Ставте правильні запитання. Замість того, щоб питати «як мені зупинити скрейпери?», запитайте «чи вирішує цей інструмент конкретну проблему, з якою я стикаюся?». Функція безпеки, яка блокує скрейпери, може бути невідповідною відповіддю для SaaS, якому потрібен відкритий доступ до API.

Ширша перспектива

Bot Fight Mode залишається корисним для сайтів, яким потрібно захистити статичний контент від агресивних краулерів. Його недоліком є нездатність розрізнити ворожий скрейпер і легітимного автоматизованого клієнта, який використовує ті самі HTTP-патерни.

Висновок

Коли ви керуєте кількома доменами в одному обліковому записі Cloudflare, ставтеся до кожного з них як до окремої зони безпеки. Увімкнюйте Bot Fight Mode лише там, де трафік є суто людським; для SaaS-навантажень з великою кількістю API тримайте цей параметр вимкненим або налаштуйте його за допомогою власних правил фаєрвола. Один клік може придушити легітимний трафік так само ефективно, як і зупинити скрейпер.