Сайт запустили — и он сразу оказался под DDoS: почему инфраструктуру нужно готовить до публичного старта проекта
Сайт готов. Рекламные кампании запущены, публикации вышли, первые пользователи переходят на проект. А через несколько часов страницы начинают открываться через раз, форма заказа не отвечает, часть посетителей получает ошибку.
Для бизнеса в этот момент неочевидно, что именно произошло. Реклама привела больше людей, чем ожидалось? Приложение не выдержало реальную нагрузку? Или сайт действительно атакуют?
Пользователь этой разницы не видит. Он нажимает на объявление и получает недоступную страницу.
Поэтому инфраструктуру стоит готовить не только к DDoS, но и к резкому росту легитимного трафика. Защиту, мониторинг, ресурсоемкие функции и порядок действий команды рациональнее проверять до публичного запуска — когда сбой еще не съедает рекламный бюджет и заявки.
Масштаб DDoS при этом продолжает расти. Cloudflare сообщает, что только за первое полугодие 2026 года ее сеть отразила 935 DDoS-атак сетевого уровня мощностью более 1 Тбит/с. Это статистика одной инфраструктуры, а не всего интернета, но она показывает характер современных атак. Akamai, в свою очередь, зафиксировала рост DDoS-атак уровня L7 на 104% за 2023–2025 годы.
Еще до запуска стоит выяснить, какая защита от DDoS-атак уже действует на стороне инфраструктуры и распространяется ли она на прикладной уровень. У AdminVPS защита L2–L4 заявлена по умолчанию для соответствующих услуг, а L7-защита для VPS и выделенных серверов подключается отдельно и предоставляется для российских серверов.
Почему запуск — особенно чувствительный момент
Публичный старт сам по себе не означает, что сайт обязательно станет целью атаки. Проблема в том, что именно в этот момент резко меняются условия его работы.
Запускается реклама, партнеры публикуют ссылки, выходит рассылка, пользователи начинают делиться страницами. Нагрузка, которая во время тестирования была относительно предсказуемой, становится динамичной.
При этом у команды еще может не быть достоверной картины работы проекта под реальной аудиторией. Сколько одновременных обращений выдерживает поиск? Как поведет себя база данных при росте запросов к каталогу? Где находится первое узкое место?
После запуска меняется и цена ошибки. На тестовом стенде десять минут недоступности — технический инцидент. Во время рекламной кампании компания продолжает оплачивать переходы, но часть пользователей уже не может выполнить целевое действие.
Как недоступность сайта отражается на маркетинге
DDoS и перегрузка инфраструктуры важны бизнесу прежде всего из-за влияния на воронку.
Пользователь нажимает на рекламу. Рекламная система фиксирует оплаченный переход. Но сайт отвечает слишком долго или возвращает ошибку — и заявка не создается.
Если страница не успела загрузить код веб-аналитики, часть таких посещений может вообще не попасть в привычный отчет. Получается разрыв: в рекламном кабинете клик есть, в CRM заявки нет, а аналитика сайта не обязательно показывает весь объем неудачных попыток.
Это влияет и на интерпретацию метрик. Если рекламные расходы продолжаются, а число заявок из-за недоступности падает, фактический CPL растет:
CPL = рекламные расходы / полученные заявки.
Для приблизительной оценки можно использовать нормальную конверсию проекта:
оценочные потерянные заявки = число неуспешных целевых сессий × обычный CR.
Это не расчет фактического финансового ущерба: конверсия зависит от источника, аудитории, времени и многих других факторов. Но такая оценка помогает понять порядок потерь и не списывать ухудшение показателей только на объявления или посадочную страницу.
Особенно чувствительны короткие кампании: запуск продукта, распродажа, спецпроект, публикация в крупном медиа. Потерянный пик интереса нельзя просто перенести на следующий день.
DDoS — это не обязательно огромный поток трафика
Оценивать устойчивость сайта только по мощности сервера — ошибка.
DDoS может воздействовать на разные части системы. Сетевые атаки перегружают канал и сетевую инфраструктуру. На прикладном уровне нагрузка направляется на веб-приложение и отдельные операции.
OWASP рекомендует анализировать инфраструктуру, приложение и сеть комплексно, искать ограниченные ресурсы и определять нормальный профиль трафика.
Для интернет-магазина ресурсоемкой операцией может оказаться поиск по большому каталогу, фильтрация, авторизация или запрос к API.
Например, главная страница продолжает открываться нормально, но каждый запрос к сложному фильтру создает тяжелое обращение к базе данных. Для мониторинга сайт формально «доступен», а покупатель уже не может подобрать товар и перейти к оформлению заказа.
Поэтому увеличение CPU и RAM решает не все сценарии. Если перегружен канал, мощность процессора не поможет. Если проблема находится в конкретной функции приложения, дополнительный ресурс лишь сдвинет предел.
Что чаще всего забывают проверить до запуска
Защиту планируют подключить уже во время атаки
Когда проблема уже началась, сайт может работать нестабильно, разработчики ищут причину, маркетинг решает, останавливать ли рекламу, а поддержка отвечает пользователям.
Кроме того, дополнительная защита не всегда подключается мгновенно. Например, для L7-защиты AdminVPS требуется перевод ресурса на защищенный IP; на странице услуги указано, что с учетом обновления доменных записей и настройки процесс может занимать до часа.
Такие изменения безопаснее провести заранее.
Для всех запросов устанавливают один жесткий лимит
Rate limiting помогает контролировать нагрузку, но универсального безопасного значения «N запросов в секунду» нет.
NGINX позволяет ограничивать скорость обработки запросов с помощью limit_req, включая допустимые кратковременные всплески. Конкретные значения должны соответствовать поведению приложения.
Слишком жесткое правило во время удачной рекламной кампании способно блокировать уже не атаку, а реальных клиентов. Особенно внимательно стоит относиться к поиску, авторизации, формам, API и сложным фильтрам.
Не знают нормальную нагрузку проекта
Без базовой картины сложно понять, что именно произошло.
До запуска полезно знать обычное время ответа приложения, использование CPU и памяти, активность базы данных и долю серверных ошибок при ожидаемой нагрузке.
Еще важнее протестировать реальные пользовательские сценарии. Для интернет-магазина недостаточно нагружать главную: покупатель проходит каталог, поиск, карточку товара, корзину и оформление заказа.
Нагрузочный тест не заменяет DDoS-защиту. Он показывает другое — где система начинает деградировать при росте легитимной аудитории.
Защитный слой можно обойти
Если перед сайтом используется CDN, reverse proxy или сервис фильтрации, стоит проверить, можно ли обратиться к origin-серверу напрямую.
Cloudflare рекомендует ограничивать прямой доступ к origin и контролировать DNS-записи, которые могут раскрывать его IP.
Конкретная реализация зависит от архитектуры, но принцип общий: если трафик должен проходить через защитный слой, прямой маршрут в обход него не должен оставаться открытым.
Мониторинг смотрит на сервер, а не на клиента
Сервер может отвечать, когда критичная функция уже не работает.
Главная открывается, но поиск возвращает ошибку. Каталог доступен, но корзина зависает. API отвечает слишком долго, хотя CPU еще находится в допустимом диапазоне.
Поэтому инфраструктурные метрики желательно дополнять контролем пользовательских сценариев.
У AdminVPS мониторинг сайта и сервера включает проверку доступности, а в зависимости от тарифа — контроль процессора, системной нагрузки, памяти и дисковой системы. Для бизнес-критичных проектов поверх этого имеет смысл проверять собственные функции приложения: нужный API, форму, авторизацию или другой ключевой сценарий.
7 вопросов перед стартом рекламной кампании
Не каждому проекту нужна сложная распределенная инфраструктура. Но перед тем, как направить на сайт значительный объем трафика, стоит получить ответы хотя бы на семь вопросов.
1. Какие действия пользователя критичны для бизнеса?Главная страница — не единственный ориентир. Важны поиск, авторизация, корзина, заявка, оформление заказа и API.
2. Какую нормальную нагрузку выдерживает система?Нужно понимать пределы пользовательских сценариев, а не только характеристики сервера.
3. Какая защита действует на уровнях L2–L4?Стоит заранее знать, что фильтруется на стороне инфраструктуры и какие действия потребуются при атаке.
4. Как защищен прикладной уровень?Для отдельных страниц и API могут понадобиться L7-фильтрация, WAF, кэширование или rate limiting.
5. Можно ли обратиться к origin в обход защиты?Проверьте прямой IP, DNS-записи и правила доступа к исходному серверу.
6. Что именно контролирует мониторинг?Важно видеть не только CPU и память, но и работоспособность ключевых функций сайта.
7. Кто и что делает при инциденте?Заранее определите, кто диагностирует проблему, кто взаимодействует с провайдером, при каких условиях останавливается реклама и кто сообщает о сбое клиентам.
Инфраструктура должна войти в план запуска вместе с маркетингом
К рекламной кампании заранее готовят медиаплан, креативы, аналитику, посадочные страницы и бюджет. Проверка инфраструктуры должна происходить в тот же период.
Не потому, что каждый проект обязательно столкнется с DDoS. А потому, что после публичного старта технический сбой перестает быть исключительно задачей IT-команды.
Реклама продолжает покупать переходы. Пользователи не выполняют целевые действия. Маркетологи видят ухудшение показателей и не всегда сразу понимают, связано оно с аудиторией, объявлениями или работой самого сайта.
Устойчивость при этом не сводится к более мощному серверу или одной услуге защиты. Нужны понимание пределов приложения, фильтрация трафика, контроль ресурсоемких функций, мониторинг и заранее определенный порядок действий.
Перед следующей крупной кампанией стоит задать команде простой вопрос:
можем ли мы за пять минут сказать, какую нагрузку выдерживает сайт, чем он защищен, какие функции контролируются и кто первым узнает о сбое?
Если нет, инфраструктурную проверку стоит добавить в план запуска наравне с аналитикой и рекламой.
День старта должен проверять маркетинговую гипотезу, а не впервые выяснять пределы сайта.