Почему WAF не спасает от DDoS, если политики собраны без приоритета и исключений
DDoS и WAF решают разные задачи. Первый бьёт по доступности, второй — по содержимому запросов. Ошибка начинается, когда одна настройка пытается закрыть обе проблемы: включают агрессивные правила, а потом удивляются ложным срабатываниям и росту задержек.
Для защиты от объёмных атак важны базовые механизмы: rate limiting, чёткие правила по ASN/географии, контроль на уровне edge и возможность быстро перевести часть трафика в challenge. Но если политика слишком общая, она режет легитимных клиентов так же уверенно, как и шумный ботнет.
WAF-политики нужно строить по слоям:
— сначала блокируем очевидный мусор и сканеры;
— затем задаём исключения для API, платёжных и авторизованных путей;
— после этого добавляем точечные правила на параметры, заголовки и аномальные методы;
— отдельным слоем держим мониторинг false positive и ручную ревизию исключений ⚠️
Не пытайтесь лечить DDoS «умным» WAF-правилом. Если атака давит канал или соединения, нужен механизм защиты от перегруза, а не ещё один regex. Стабильность инфраструктуры — залог масштабируемости.
DDoS и WAF решают разные задачи. Первый бьёт по доступности, второй — по содержимому запросов. Ошибка начинается, когда одна настройка пытается закрыть обе проблемы: включают агрессивные правила, а потом удивляются ложным срабатываниям и росту задержек.
Для защиты от объёмных атак важны базовые механизмы: rate limiting, чёткие правила по ASN/географии, контроль на уровне edge и возможность быстро перевести часть трафика в challenge. Но если политика слишком общая, она режет легитимных клиентов так же уверенно, как и шумный ботнет.
WAF-политики нужно строить по слоям:
— сначала блокируем очевидный мусор и сканеры;
— затем задаём исключения для API, платёжных и авторизованных путей;
— после этого добавляем точечные правила на параметры, заголовки и аномальные методы;
— отдельным слоем держим мониторинг false positive и ручную ревизию исключений ⚠️
Не пытайтесь лечить DDoS «умным» WAF-правилом. Если атака давит канал или соединения, нужен механизм защиты от перегруза, а не ещё один regex. Стабильность инфраструктуры — залог масштабируемости.
TTFB и задержки: как не перепутать проблему CDN с медленным origin
TTFB — это не просто “медленно отвечает сайт”. Это сумма сетевой задержки, очереди на edge, времени до origin и обработки ответа. Если смотреть только на средний TTFB, можно пропустить деградацию по отдельным регионам, ASN или типам запросов.
Что мониторить в первую очередь:
— p50, p95 и p99 по TTFB, а не только среднее;
— раздельно edge TTFB и origin TTFB, если метрики доступны;
— время DNS, TLS, connect и first byte в waterfall;
— рост 5xx и 4xx вместе с задержкой: часто это один инцидент, а не два.
Полезная практика — строить алерты не по абсолютному значению, а по отклонению от базовой линии для конкретного пула трафика. Для API и HTML пороги должны быть разными: у кэша и динамики разные профили, и одинаковые правила здесь только шумят.
Если TTFB растёт, сначала исключайте origin: очереди в приложении, медленные SQL-запросы, лимиты по соединениям, проблемы с keepalive. Затем проверяйте edge: cache hit ratio, правила кэша, geo-routing и наличие лишних редиректов. Безопасность и скорость: находим баланс в каждой конфигурации.
Стабильная система видна в метриках до того, как её замечают пользователи. Разбираем логи, оптимизируем кэширование, минимизируем задержки.
—
Чтобы быть в курсе рынка — подпишись на @vk_mutual_promo_ww
TTFB — это не просто “медленно отвечает сайт”. Это сумма сетевой задержки, очереди на edge, времени до origin и обработки ответа. Если смотреть только на средний TTFB, можно пропустить деградацию по отдельным регионам, ASN или типам запросов.
Что мониторить в первую очередь:
— p50, p95 и p99 по TTFB, а не только среднее;
— раздельно edge TTFB и origin TTFB, если метрики доступны;
— время DNS, TLS, connect и first byte в waterfall;
— рост 5xx и 4xx вместе с задержкой: часто это один инцидент, а не два.
Полезная практика — строить алерты не по абсолютному значению, а по отклонению от базовой линии для конкретного пула трафика. Для API и HTML пороги должны быть разными: у кэша и динамики разные профили, и одинаковые правила здесь только шумят.
Если TTFB растёт, сначала исключайте origin: очереди в приложении, медленные SQL-запросы, лимиты по соединениям, проблемы с keepalive. Затем проверяйте edge: cache hit ratio, правила кэша, geo-routing и наличие лишних редиректов. Безопасность и скорость: находим баланс в каждой конфигурации.
Стабильная система видна в метриках до того, как её замечают пользователи. Разбираем логи, оптимизируем кэширование, минимизируем задержки.
—
Чтобы быть в курсе рынка — подпишись на @vk_mutual_promo_ww
Cloudflare Workers и serverless-логика: где экономия задержки, а где скрытая сложность
Workers полезны, когда нужно обработать запрос на краю сети: переписать URL, выбрать origin, поставить заголовки, собрать A/B-логику без лишнего RTT. Для таких задач они быстрее и проще, чем тащить всё в центральный бэкенд. Но переносить туда бизнес-логику целиком — рискованно: цена ошибки растёт, а отладка становится менее прозрачной.
Проверяйте три вещи до выноса кода:
• идемпотентность — повторный запрос не должен ломать состояние;
• зависимость от хранилища — Workers не заменяют полноценную транзакционную БД;
• границы кэша — если логика меняет ответ, кэширование должно быть предсказуемым, иначе получите трудноуловимые расхождения.
Отдельная ловушка — работа с секретами и внешними API. Не кладите в Worker то, что требует долгих соединений, тяжёлых библиотек или частых обновлений состояния. Для интеграций лучше держать тонкий слой оркестрации: валидировать вход, нормализовать запрос, передать дальше и вернуть контролируемый ответ. Это снижает blast radius при сбоях и упрощает разбор инцидентов.
Ещё один практический критерий: если правило можно описать в 20–30 строках и оно не зависит от сложной доменной модели, Worker оправдан. Если же код начинает имитировать полноценный сервис, лучше остановиться и вынести логику в отдельный backend. Стабильность инфраструктуры — залог масштабируемости.
Workers полезны, когда нужно обработать запрос на краю сети: переписать URL, выбрать origin, поставить заголовки, собрать A/B-логику без лишнего RTT. Для таких задач они быстрее и проще, чем тащить всё в центральный бэкенд. Но переносить туда бизнес-логику целиком — рискованно: цена ошибки растёт, а отладка становится менее прозрачной.
Проверяйте три вещи до выноса кода:
• идемпотентность — повторный запрос не должен ломать состояние;
• зависимость от хранилища — Workers не заменяют полноценную транзакционную БД;
• границы кэша — если логика меняет ответ, кэширование должно быть предсказуемым, иначе получите трудноуловимые расхождения.
Отдельная ловушка — работа с секретами и внешними API. Не кладите в Worker то, что требует долгих соединений, тяжёлых библиотек или частых обновлений состояния. Для интеграций лучше держать тонкий слой оркестрации: валидировать вход, нормализовать запрос, передать дальше и вернуть контролируемый ответ. Это снижает blast radius при сбоях и упрощает разбор инцидентов.
Ещё один практический критерий: если правило можно описать в 20–30 строках и оно не зависит от сложной доменной модели, Worker оправдан. Если же код начинает имитировать полноценный сервис, лучше остановиться и вынести логику в отдельный backend. Стабильность инфраструктуры — залог масштабируемости.
Brotli и Minify дают прирост только там, где не ломают кэш и CPU
В Cloudflare эти настройки часто включают «на всякий случай», а потом удивляются росту задержек на динамике. Brotli сжимает ответ эффективнее gzip, но ценой дополнительной работы на edge. Minification сокращает размер CSS, JS и HTML, однако почти не помогает, если контент уже тяжело генерируется на origin.
Проверьте три вещи:
• Для статических ассетов Brotli обычно оправдан, для CPU-sensitive страниц — только после замеров.
• Minify не трогает уже минифицированные файлы, но может усложнить отладку и сломать inline-скрипты.
• Если у вас есть сильный cache hit ratio, выигрыш от сжатия заметен меньше, чем от нормальной политики кэша ⚙️
Главная ошибка — включать Brotli и Minify без раздельного анализа HTML, CSS и JS. HTML часто выигрывает сразу, а вот тяжелые bundle-файлы нужно проверять на совместимость с source maps, SRI и сборкой фронтенда. Иначе «оптимизация» превращается в цепочку мелких инцидентов.
Сначала измеряйте TTFB, CPU time и размер ответа по типам контента, потом включайте сжатие точечно. Безопасность и скорость: находим баланс в каждой конфигурации.
В Cloudflare эти настройки часто включают «на всякий случай», а потом удивляются росту задержек на динамике. Brotli сжимает ответ эффективнее gzip, но ценой дополнительной работы на edge. Minification сокращает размер CSS, JS и HTML, однако почти не помогает, если контент уже тяжело генерируется на origin.
Проверьте три вещи:
• Для статических ассетов Brotli обычно оправдан, для CPU-sensitive страниц — только после замеров.
• Minify не трогает уже минифицированные файлы, но может усложнить отладку и сломать inline-скрипты.
• Если у вас есть сильный cache hit ratio, выигрыш от сжатия заметен меньше, чем от нормальной политики кэша ⚙️
Главная ошибка — включать Brotli и Minify без раздельного анализа HTML, CSS и JS. HTML часто выигрывает сразу, а вот тяжелые bundle-файлы нужно проверять на совместимость с source maps, SRI и сборкой фронтенда. Иначе «оптимизация» превращается в цепочку мелких инцидентов.
Сначала измеряйте TTFB, CPU time и размер ответа по типам контента, потом включайте сжатие точечно. Безопасность и скорость: находим баланс в каждой конфигурации.