Як увімкнути режим Cloudflare "Під атакою" під час DDoS-атак на сайт?

Режим Cloudflare "Під атакою" — це екстрений захист сайту під час DDoS-атаки, який показує відвідувачам коротку перевірку безпеки, щоб відфільтрувати бот-трафік. Активувавши цей режим у панелі Cloudflare, у розділі Security, ви за кілька хвилин зможете уповільнити інтенсивні запити на рівні HTTP/HTTPS, захистити справжніх користувачів від недоступності сайту та знизити навантаження на сервер. Втім, цей режим не є постійним рішенням — його слід використовувати разом із правильними налаштуваннями DNS-проксі, WAF-правилами, обмеженням частоти запитів, кешуванням та безпекою основного сервера.

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

Що таке режим Cloudflare "Під атакою"?

Режим "Під атакою" — це підвищений рівень безпеки від Cloudflare, який активується у разі загрози сайту. При увімкненні Cloudflare відображає відвідувачам коротке вікно перевірки браузера, що триває зазвичай кілька секунд. Це ускладнює автоматизованим ботам, простим HTTP flood-інструментам та шкідливим клієнтам без браузера безпосередньо навантажувати ваш сайт.

Головна мета цього режиму — пом’якшити атаки на рівні застосунку (Layer 7). Наприклад, якщо на головну сторінку надходить тисячі GET-запитів за секунду, або на сторінку входу WordPress — масивні POST-спроби, або ж на сторінку пошуку чи кошик надсилається фейковий трафік, режим "Під атакою" стане швидкою першою лінією оборони.

Варто пам’ятати: цей режим фільтрує веб-запити, але якщо безпосередньо атакують IP-адресу сервера, або ваші сервіси поза проксі Cloudflare відкриті, або атака на рівні мережевого рівня (Layer 3/4), потрібні додаткові заходи. Тому критично важливо, щоб DNS-записи були проксійовані через Cloudflare, IP сервера був захищений, а на стороні хостингу були налаштовані відповідні механізми безпеки. Для вибору надійної інфраструктури рекомендуємо ознайомитися з матеріалами Послуги безпечного веб-хостингу та встановлення сертифіката SSL.

Симптоми DDoS-атаки: що перевірити перед увімкненням режиму "Під атакою"?

Не кожне уповільнення роботи сайту — це DDoS. Іноді причина криється у некоректному плагіні, блокуванні бази даних, ресурсоємних cron-завданнях або неправильному кешуванні. Тому перед активацією режиму "Під атакою" корисно швидко з’ясувати причину проблем. Проте якщо сервер не відповідає, користувачі отримують помилки 502, 503, 504, а в логах спостерігається аномальний сплеск запитів — відкривати режим слід негайно.

Типові ознаки DDoS

• Різке збільшення трафіку у 5, 10 або 50 разів за короткий час.
• Сотні запитів за секунду на одну сторінку або endpoint.
• Трафік із різних країн зі схожими user-agent.
• Цільові атаки на важкі URL, як-от сторінки входу, пошуку, кошика в WordPress, WooCommerce, OpenCart чи власних рішеннях.
• Перевантаження CPU, RAM, PHP-FPM воркерів або лімітів підключень MySQL.
• Різке зростання 4xx і 5xx помилок у Cloudflare Analytics.
• Справжні користувачі заходять інтервально, а бот-трафік безперервно надсилає запити.

Наприклад, якщо інтернет-магазин, що зазвичай приймає 2000 запитів на хвилину, за 10 хвилин отримує 80 000, причому 70% із них спрямовані на сторінки кошика чи пошуку — це очевидна Layer 7 атака. У такому випадку режим "Під атакою" потрібно активувати протягом перших 5 хвилин, а після — додати спеціальні WAF-правила та обмеження частоти запитів.

Коли слід використовувати режим Cloudflare "Під атакою"?

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

Рекомендовані випадки застосування

• Виявлено аномально високий трафік HTTP/HTTPS.
• Ресурси сервера швидко вичерпуються, збільшується кількість помилок 502/503.
• Cloudflare WAF ще не налаштовано спеціальними правилами і потрібен швидкий захист.
• Бот-трафік значно перевищує реальний користувацький.
• Атака спрямована на веб-сторінки, форми, сторінки входу чи пошукові endpoints.

Коли слід бути обережним

• Якщо активно використовуються мобільні додатки, платіжні системи, webhook або API.
• Якщо у період сканування сайту критично важливі пошукові роботи.
• Якщо корпоративні користувачі заходять зі старих браузерів або обмежених мереж.
• Якщо у вас є піддомени поза проксі Cloudflare.

Для сайтів з API увімкнення режиму "Під атакою" на весь домен може порушити роботу інтеграцій. Тому для API піддоменів рекомендується застосовувати окремі WAF-правила, allowlist або інший рівень захисту. Детальніше про безпеку API можна дізнатися в Посібник з безпеки API та обмеження швидкості.

Як увімкнути режим Cloudflare "Під атакою"? Покрокова інструкція

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

1. Увійдіть у свій обліковий запис Cloudflare

Спершу зайдіть у Cloudflare і виберіть домен, що під атакою. Якщо ви керуєте кількома доменами — переконайтеся, що обрали саме той, для якого плануєте ввімкнути режим "Під атакою". Помилка тут може коштувати часу і дозволити атаці продовжуватися.

2. Перевірте, що DNS-записи проксійовані

Для ефективної роботи режиму трафік має проходити через Cloudflare. Перевірте, що записи типу A, AAAA і CNAME у розділі DNS мають активований помаранчевий хмарний значок (proxied). Записи із сірим хмарним значком (DNS only) не захищаються і пропускають трафік напряму на сервер.

Якщо IP-адреса сервера видима в інтернеті, зловмисники можуть атакувати сервер напряму, оминаючи Cloudflare. Тому рекомендовано налаштувати на сервері firewall, який прийматиме HTTP/HTTPS трафік лише з IP-діапазонів Cloudflare. За потреби зверніться до хостинг-провайдера або перегляньте Як налаштувати DNS в Cloudflare.

3. Активуйте режим "Під атакою" у розділі Security

У панелі Cloudflare відкрийте вкладку Security або Overview і знайдіть опцію Under Attack Mode (іноді позначається як I am Under Attack). Активуйте цю опцію — відвідувачі побачать коротке вікно перевірки перед доступом до сайту.

Зміни зазвичай застосовуються миттєво. Слідкуйте за метриками у Cloudflare Analytics, Security Events і навантаженням сервера. Якщо CPU та кількість активних з’єднань зменшуються — режим працює. Якщо ні — додайте додаткові правила.

4. Перевірте досвід реальних користувачів

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

5. Визначте цільові URL атаки

Режим "Під атакою" — це загальний захист, але максимальний ефект дають спеціальні правила для найуразливіших URL. Перегляньте Security Events, веб-аналітику, логи доступу хостингу та додатка, щоб знайти сторінки з найбільшим навантаженням. Це можуть бути /wp-login.php, /xmlrpc.php, /search, /cart, /api/login, /checkout та інші.

Використовуйте WAF Custom Rules для блокування або складніших перевірок за країною, user-agent, методом запиту, URI або балом бота. Наприклад, IP-адресам, які перевищують допустиму кількість запитів на сторінку входу, можна застосувати managed challenge. Для сайтів WordPress корисно ознайомитися з Заходи безпеки WordPress.

Чим режим "Під атакою" відрізняється від інших опцій безпеки Cloudflare?

Інструменти захисту Cloudflare мають різні призначення. Режим "Під атакою" — це швидкий загальний фільтр для невідкладного захисту, WAF і Rate Limiting — більш таргетовані та збалансовані для постійного використання, що краще зберігають досвід користувачів.

Оптимальна стратегія: спочатку увімкнути режим "Під атакою" для швидкого зниження навантаження, далі проаналізувати патерни атаки, налаштувати WAF і Rate Limiting, та завершити оптимізацією кешування і firewall на сервері.

Рекомендації щодо додаткових налаштувань Cloudflare під час атаки

Хоча режим "Під атакою" можна активувати одним кліком, ефективність захисту залежить від допоміжних налаштувань. Нижче — найпоширеніші корисні практики.

Налаштуйте таргетовані WAF-правила

WAF Cloudflare дозволяє створювати складні умови для блокування або виклику challenge. Наприклад, можна застосувати challenge лише для POST-запитів на /wp-login.php із певних країн, не навантажуючи весь сайт.

• Обмежте доступ до адмін- і сторінок входу для конкретних країн або IP-діапазонів.
• Заблокуйте невикористовувані endpoints, наприклад XML-RPC.
• Застосовуйте managed challenge до підозрілих user-agent.
• Обмежуйте клієнтів, які надто часто звертаються до певних URI за допомогою rate limiting.

Правильно налаштуйте кешування

Під час DDoS сервер швидко виснажує ресурси, якщо кожен запит доходить до нього. Статичні файли, зображення, CSS, JavaScript та кешовані сторінки слід обслуговувати з edge-серверів Cloudflare. Для динамічних сайтів, як WordPress, корисно поєднувати плагіни кешування з правилами кешування Cloudflare і правильними HTTP-заголовками.

Наприклад, у новинних або блогових проектах сторінки для анонімних користувачів можна кешувати від 5 до 30 хвилин. Це знижує час першого байта (TTFB) і розвантажує хостинг навіть поза часом атаки. Детальніше про оптимізацію швидкості сайту дивіться в Посібник з прискорення веб-сайту.

Встановіть реалістичні пороги rate limiting

Обмеження частоти запитів особливо ефективне на дорогих endpoints, але неправильні налаштування можуть зашкодити користувачам. Наприклад, на сторінці пошуку нормальна кількість запитів — 5-15 за хвилину, а 100 — надмірно. Для сторінки входу понад 10 невдалих спроб за 5 хвилин — підозріло.

Приклад: для /wp-login.php IP, що робить понад 10 запитів за хвилину, отримує managed challenge, а при 50 запитах за 5 хвилин — тимчасову блокування. Для API бажано застосовувати більш тонкі ліміти за сесією, IP, токеном і методом.

Приховайте IP сервера і обмежте доступ firewall

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

Переконайтеся, що порти 80 і 443 приймають трафік лише з IP-пулів Cloudflare. Порти SSH, панелі керування, бази даних мають бути закриті ззовні, або обмежені за IP, із застосуванням складних паролів, двофакторної автентифікації та VPN. Для налаштування безпеки рекомендуємо Налаштування безпеки cPanel та конфігурація файрвола VPS.

Особливості для WordPress, WooCommerce та корпоративних сайтів

Різні типи сайтів мають свої специфічні вразливості. Блог, інтернет-магазин на WooCommerce та SaaS-панель по-різному реагують на режим "Під атакою", тому важливо визначити ключові шляхи для захисту.

WordPress сайти

Найчастіше атаковані файли — /wp-login.php і /xmlrpc.php. Якщо ви не використовуєте XML-RPC, його краще заблокувати. Для адмін-панелі можна встановити обмеження за країнами чи IP. Також варто стежити, щоб плагіни безпеки не конфліктували з Cloudflare — надмірна кількість challenge може призвести до нескінченного циклу перевірок.

Інтернет-магазини WooCommerce

Сторінки кошика, оформлення замовлення та особистого кабінету потребують обережності. Вони динамічні, тому агресивне кешування не рекомендується. Під час режиму "Під атакою" переконайтеся, що callback-адреси платіжних систем, webhook і API працюють коректно. При необхідності додайте IP платіжних провайдерів у allowlist або створіть спеціальні правила для цих endpoint.

Корпоративні сайти і API

Портали для корпоративних клієнтів, CRM та мобільні додатки можуть не підтримувати JavaScript challenge від Cloudflare. Тож краще не вмикати режим "Під атакою" на весь домен, а окремо захищати API-піддомени за допомогою токенів, rate limiting та allowlist. Наприклад, www.example.com під режимом "Під атакою", а api.example.com — з токен-бейз захистом.

Що відслідковувати після увімкнення режиму "Під атакою"?

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

• Cloudflare Security Events: скільки запитів було заблоковано або поставлено на challenge.
• HTTP-коди стану: зміни у 403, 429, 502, 503, 504.
• Використання CPU та RAM сервера: очікується зниження після увімкнення.
• Кількість підключень PHP-FPM і MySQL: відображає навантаження на застосунок.
• Обсяг трафіку і кількість запитів: співвідношення загального і фільтрованого трафіку.
• Конверсії реальних користувачів: перевіряйте надсилання форм, замовлення, логіни і платежі.

Наприклад, якщо загальна кількість запитів не змінилася, але на origin-сервер доходить на 60% менше, це означає, що Cloudflare успішно відфільтрував частину трафіку. Якщо ж навантаження на MySQL залишається високим, можливо, атака спровокувала ресурсоємний запит — варто проаналізувати логи.

Як безпечно вимкнути режим "Під атакою" після атаки?

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

Кроки для безпечного повернення до нормального режиму

• Дочекайтеся стабілізації трафіку протягом 30-60 хвилин.
• Перевірте, що кількість challenge і блокувань у Cloudflare Security Events зменшилася.
• Перед вимкненням режиму увімкніть таргетовані WAF-правила і обмеження частоти запитів.
• Встановіть рівень безпеки Cloudflare на High або Medium для збалансованого захисту.
• Перевірте сайт із різних пристроїв і мереж, слідкуйте за помилками 5xx.
• Моніторте логи протягом 24 годин, щоб вчасно виявити можливі повторні атаки.

Рекомендуємо після атаки створити звіт — з часом початку, цільовими URL, піковими навантаженнями, застосованими заходами та результатами. Це допоможе швидше реагувати при наступних інцидентах.

Типові помилки, яких варто уникати

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

• Очікувати захист від режиму "Під атакою" без проксінгу DNS-записів.
• Залишати відкритою IP-адресу origin без обмежень firewall.
• Застосовувати challenge на весь домен без тестування API та webhook.
• Писати надто жорсткі WAF-правила, що блокують реальних клієнтів.
• Кешувати динамічні сторінки кошика, оформлення замовлення або особистого кабінету.
• Залишати режим "Під атакою" увімкненим тижнями.
• Приймати рішення лише за даними Cloudflare без аналізу серверних логів.

Особливо у e-commerce випадках блокування callback платіжних систем може призвести до значних фінансових втрат. Тому рекомендуємо тестувати правила спочатку через логування або managed challenge, і лише після підтвердження ефективності переходити до жорсткішого блокування.

Як побудувати більш стійкий захист на базі Hostragons?

Cloudflare — потужний фронтенд-захист, але успішна оборона від DDoS не закінчується на CDN. Важливо комплексно підходити до хостингу, оптимізації ПЗ, налаштування SSL, управління DNS і резервного копіювання. На Hostragons базовий принцип: Cloudflare фільтрує трафік, хостинг приймає лише чисті запити, а застосунок оптимізований для мінімального навантаження на базу.

Перед запуском проекту слід забезпечити правильне управління DNS, бездоганну установку SSL-сертифіката і вибір веб-сервера, що відповідає профілю трафіку. Для цього корисні матеріали Перевірка домену та реєстрація домену, Пакети веб-хостингу, рішення для корпоративного хостингу та Безкоштовний SSL сертифікат.

Для проектів з високим трафіком або ризиком атак рекомендуємо розглянути VPS або керовані сервери замість спільного хостингу. Це забезпечує гнучке налаштування firewall, веб-сервера, PHP-FPM, Redis, object cache і бази даних. Але незалежно від інфраструктури, режим "Під атакою" має залишатися тимчасовим інструментом, а постійний захист будувати на WAF, аналізі логів і регулярних оновленнях.

Чекліст для першої чверті години під час DDoS-атаки

Під час атаки час — найцінніший ресурс. Ось короткий перелік дій для технічної команди або власника сайту на перші 15 хвилин.

• Увійдіть у панель Cloudflare і виберіть правильний домен.
• Переконайтеся, що DNS-записи проксійовані (помаранчевий хмарний значок).
• Активуйте режим "Під атакою".
• Перевірте основні сторінки: головну, вхід, кошик, оплату та API endpoints.
• Визначте цільові URL через Security Events Cloudflare.
• Додайте спеціальні WAF та rate limiting правила для найнавантаженіших шляхів.
• Перевірте стан CPU, RAM, PHP-FPM і MySQL на сервері.
• Переконайтеся, що origin IP недоступний напряму.
• Перевірте allowlist для платіжних систем, webhook і важливих інтеграцій.
• Фіксуйте всі дії з часовими позначками.

Регулярне відпрацювання цього плану допоможе знизити паніку і підвищити якість реагування під час реальних атак. Для великих проєктів рекомендується документувати цей процес як частину плану реагування на інциденти.

Поширені запитання

Чи захищає режим "Під атакою" сайт повністю?

Ні. Режим "Під атакою" ефективний проти ботів і flood-атак на рівні HTTP/HTTPS, але не є абсолютним захистом. Для комплексної безпеки необхідно, щоб DNS-записи були проксійовані, IP origin прихований, а також використовувалися WAF-правила, обмеження частоти запитів, кешування і firewall на сервері.

Чи шкодить режим SEO?

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

Скільки тримати режим "Під атакою" увімкненим?

Режим слід тримати активним, доки інтенсивність атаки не знизиться, а потім ще 30-60 хвилин для стабілізації. Після цього поступово вимикайте режим, переконавшись, що WAF і rate limiting працюють коректно.

Чи впливає режим на API або платіжні системи?

Так, може. Деякі API-клієнти, webhook і callback платіжних систем не проходять браузерну перевірку Cloudflare. Тому критичні endpoint слід тестувати і налаштовувати allowlist або спеціальні правила.

Чи потрібно додатково захищати сервер при використанні Cloudflare?

Так. Cloudflare забезпечує потужний фронтенд-захист, але IP origin потрібно приховати, firewall налаштувати на пропуск лише дозволеного трафіку, програмне забезпечення оновлювати, а кешування — правильно налаштовувати. Безпечна хостинг-інфраструктура — ключова частина стійкості проти DDoS.

Висновок

Режим Cloudflare "Під атакою" — це ефективний інструмент першої допомоги під час DDoS-атаки. При правильному налаштуванні він знижує бот-трафік, зменшує навантаження на сервер і підвищує шанси справжніх користувачів потрапити на сайт. Для найкращого результату цей режим слід використовувати разом із WAF-правилами, обмеженням частоти запитів, оптимізацією кешування та firewall на сервері.

Щоб ваш сайт був більш стійким до атак, регулярно перевіряйте інфраструктуру, DNS-налаштування та SSL-сертифікати. Ознайомтеся з рішеннями Hostragons у сфері хостингу, доменів і SSL, щоб забезпечити надійну і довготривалу безпеку вашого проєкту.