До основного вмісту

DDoS-захист Cloudflare: як працює і як налаштувати

Cloudflare · 19.04.2026 · 5 хв читання
Ілюстрація до статті «DDoS-захист Cloudflare: як працює і як налаштувати»

Cloudflare автоматично виявляє та блокує DDoS-атаки на рівнях L3, L4 і L7. Для активації достатньо підключити сайт до Cloudflare — базовий захист працює без налаштування.

Рівні DDoS-захисту за планами

ФункціяFreeProBusiness/Enterprise
L3/L4 DDoS✅✅✅
L7 HTTP DDoS✅ Базовий✅✅ Advanced
Managed Rules WAF❌✅✅
Advanced DDoS Analytics❌❌✅

Security Level

Security → Security Level керує тим, наскільки агресивно Cloudflare перевіряє відвідувачів:

РівеньДія
Essentially OffЛише явно заблоковані IP
LowБлокування відомих поганих IP
MediumСтандартний (за замовчуванням) ✅
HighАгресивна перевірка CAPTCHA
I'm Under Attack!5-секундний JavaScript challenge для всіх

I'm Under Attack Mode

Під час активної атаки увімкніть екстрений режим:

Security → Security Level → I'm Under Attack!

Кожен відвідувач побачить 5-секундну сторінку перевірки Cloudflare. Боти не пройдуть, реальні користувачі — пройдуть.

⚠️ I'm Under Attack Mode ламає API та автоматичні запити. Не залишайте його увімкненим постійно — лише під час реальної атаки.

Rate Limiting

Security → WAF → Rate Limiting Rules → Create. Обмежте кількість запитів з однієї IP:

# Приклад: не більше 100 запитів за 60 секунд
Matching rule: http.request.uri.path contains "/api/"
Rate: 100 requests per 60 seconds
Action: Block (або Challenge)
✅ Rate Limiting особливо корисний для захисту /wp-login.php, /xmlrpc.php, форм авторизації та API-ендпоінтів.

Managed Challenge, JS Challenge і CAPTCHA

Коли Cloudflare вирішує перевірити відвідувача, він показує один із типів challenge. Вони відрізняються навантаженням на користувача і стійкістю до ботів:

Тип перевіркиЩо бачить відвідувачСтійкість до ботів
Managed ChallengeНайчастіше нічого — перевірка у фоніВисока, адаптується під загрозу
JS ChallengeКоротка сторінка-редирект (~5 секунд)Середня, потребує виконання JS
Legacy CAPTCHAВізуальна головоломкаСередня, дратує користувачів
BlockСторінка відмови в доступіМаксимальна, але без права на помилку

Managed Challenge — рекомендований варіант майже завжди: Cloudflare сам обирає ступінь перевірки на основі репутації IP та поведінки браузера.

Розбір повідомлень про атаку

«This website is under a DDoS attack» на сторінці відвідувача

Це проміжна сторінка, яку Cloudflare показує автоматично при аномальному сплеску трафіку, навіть без ручного увімкнення I'm Under Attack Mode. Вона тримається від кількох хвилин до моменту, поки трафік не повернеться до звичайного рівня. Вимкнути її вручну не можна — вона частина автоматичного захисту рівня мережі.

Легітимні користувачі скаржаться на блокування

Часта причина — Security Level стоїть на High або I'm Under Attack Mode увімкнено довше, ніж потрібно, або правило Rate Limiting налаштовано занадто суворо для спільної NAT-адреси офісу чи мобільного оператора, через що багато реальних користувачів виглядають як одна IP-адреса з аномальною частотою запитів.

Перевірка що захист працює

# Перевірити заголовок, що показує тип пройденої перевірки
curl -I https://example.com/ | grep -i cf-mitigated

# Значення:
# cf-mitigated: challenge   — відвідувач пройшов challenge
# (заголовок відсутній)     — запит оброблено без додаткової перевірки

Коли вбудованого захисту недостатньо

  • Потрібен захист на рівні застосунку від повільних low-and-slow атак, які не створюють помітного сплеску трафіку — тут потрібен WAF із точними правилами, а не лише автоматичний DDoS-шар.
  • Атака йде не по HTTP, а напряму на IP сервера в обхід Cloudflare — proxied-режим від цього не захищає, потрібен Spectrum або зміна реальної IP-адреси із закриттям прямого доступу.
  • Потрібні SLA і гарантії часу реакції — базовий захист працює "best effort", формальні гарантії є лише в контрактах рівня Enterprise.

Security → Events показує не лише заблоковані, а й пропущені після перевірки запити — за стовпцем Action можна відфільтрувати саме ті, що потрапили під автоматичний DDoS-захист, і побачити, з яких країн чи ASN ішов основний трафік атаки.

Після увімкнення I'm Under Attack Mode тримайте його максимум кілька годин: challenge проходить кожен унікальний відвідувач, включно з пошуковими ботами, — тривале використання режиму може тимчасово знизити видимість сайту в пошуку через неможливість обходу challenge краулером.

Managed Challenge і автоматичний DDoS-захист працюють незалежно від Bot Fight Mode — увімкнення обох одночасно не конфліктує і зазвичай дає кращий результат, ніж будь-який з інструментів окремо.

Для перевірки відповідності поточного навантаження нормі порівнюйте графіки Analytics → Traffic за останні 24 години і за попередній тиждень — різке необґрунтоване зростання кількості запитів з одного ASN зазвичай перша ознака атаки, що почалася, ще до появи проміжної сторінки.

Часті питання

Чи вимикається I'm Under Attack Mode автоматично після завершення атаки, чи потрібно вимикати його вручну?

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

Чи працюватиме захист Cloudflare, якщо домен підключено в режимі лише DNS, без проксування?

Базовий захист від об'ємних атак на рівні мережі діє навіть без проксування, оскільки IP-адреса сервера однаково видна в DNS. Проте захист рівня застосунку — Security Level, Rate Limiting, Managed Challenge — стосується лише трафіку, який справді проходить через Cloudflare. Для повноцінного захисту від HTTP-атак домен повинен бути проксований, тобто «хмаринка» увімкнена.

Чи може агресивний захист заблокувати легітимні API-запити і вебхуки платіжних систем?

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

Чи потрібно додатково налаштовувати захист на самому сервері, якщо домен вже під Cloudflare?

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

Чи була стаття корисною?
← Назад до бази знань Поставити питання підтримці