DDoS-атака или парсеры? Как боты перегружали интернет-магазин на OT Box и увеличивали платные вызовы OTAPI

Реальный технический кейс: нагрузка центрального процессора доходила до 98–100%, число платных обращений к товарной платформе выросло в 6–7 раз, а основная часть проблемного трафика оказалась не классической сетевой DDoS-атакой, а автоматизированными запросами к веб-сайту.

С чего началась история

Владелец интернет-магазина обратился с типичной формулировкой: «Сайт, похоже, DDoS-ят. Боты приходят с разных IP-адресов и из разных стран, ходят по страницам, нагружают сервер и считывают информацию».

Проблема продолжалась почти три дня. По словам владельца, загрузка центрального процессора (CPU) временами доходила до 98–100%. Параллельно примерно в 6–7 раз выросло количество платных обращений сайта к внешней товарной платформе Taobao. То есть проблема была не только в производительности сервера: автоматизированный обход каталога начал увеличивать и прямые эксплуатационные расходы проекта в прямом смысле этого слова.

До обращения ко мне на в VPS сервере уже работал сторонний платный антибот модуль. Не буду называть название модуля, так как к своей профессиональной деятельности отношусь ответственно и отвечаю именно за свою работу, при этом не обливая грязью своих конкурентов. Несмотря на то что хозяин веб-проекта подключил и запустил антибот модуль на VPS сервере, негативная роботная активность продолжалась, а нагрузка не вернулась к нормальному уровню и продолала нахдоиться на аномально высоком уровне, автоматизированный негативный трафик не остановился. В отчаянных попытках найти выход владелец интернет-магазина даже ограничивал доступ к карточкам товаров для неавторизованных посетителей.

Частое явление в такой ситуации это назвать всё происходящее DDoS-атакой. Однако высокая загрузка CPU, множество динамических IP-адресов и запросы из разных стран сами по себе ещё не показывают, что именно происходит.

На чём работает сайт в данном кейсе: движок OT Commerce и платформа OTAPI

В этом проекте используется OT Commerce. Это специализированная платформа для интернет-магазинов, работающих с каталогами Taobao, Tmall, 1688, Alibaba, AliExpress и других торговых площадок. Готовое решение у разработчика называется «Коробка ОТ»: оно устанавливается на домен владельца магазина и содержит витрину, поиск, карточки товаров, личный кабинет, оформление заказов и другие функции интернет-магазина.

Это важное отличие от обычного магазина, где весь каталог товаров целиком хранится в локальной базе данных сайта. В OT Commerce значительная часть товарной информации связана с внешней платформой OpenTrade Commerce. Для обмена данными используется OTAPI. Он представляет собой интерфейс программирования приложений (Application Programming Interface, API) платформы OpenTrade Commerce.

Проще говоря, OTAPI — это программный посредник между интернет-магазином и товарными данными внешних площадок. Когда сайту нужно найти товары, получить карточку товара, описание, сведения о продавце, цену или другой внешний набор данных, сервер сайта может отправить запрос в OTAPI и получить структурированный ответ.

У самой OpenTrade Commerce схема описана близко по смыслу: клиенты обращаются к OTAPI, OTAPI работает с внутренним хранилищем данных, а отдельные сборщики платформы получают и обновляют данные у товарных провайдеров. Поэтому открытие страницы интернет-магазина может быть связано не только с локальной работой PHP и базы данных, но и с обращениями к внешней платформе.

Что такое платный вызов OTAPI

Платный вызов OTAPI — это не «соединение с сервером» и не просто любой HTTP-запрос. Это единица тарификации конкретных методов интерфейса OTAPI. По документации OpenTrade Commerce платными являются не все методы, а прежде всего операции, связанные с каталогом, товарами, поиском, продавцами и другой информацией от товарных провайдеров.

Например, платными отмечены методы SearchItemsFrame (глобальный поиск товаров), GetItemInfo (получение информации о товаре), GetItemDescription (получение описания), GetItemFullInfo (полная информация о товаре) и ряд массовых методов. Поэтому автоматизированный бот, который последовательно перебирает карточки товаров интернет-магазина, категории или поиск, может заставлять сайт выполнять именно те операции, за которые владелец платит платформе.

Один технический запрос к OTAPI не всегда равен одному платному вызову. В документации есть методы с динамической стоимостью. Например, для некоторых операций принудительного обновления товара параметр ForceUpdate для Taobao/Tmall, 1688, Alibaba, AliExpress, JD, Amazon и Ebay учитывается как пять вызовов. Для массовых методов стоимость может зависеть от количества реально полученных товаров. С точки зрения OTAPI учитываются успешные обращения к платным методам. В документации отдельно указано, что результат с кодом ErrorCode=Ok или ErrorCode=BatchError считается успешным. Даже если клиентская сторона по какой-то причине не дождалась ответа, но OTAPI успешно завершило обработку, такой вызов может быть учтён.

Почему боты могли одновременно нагружать CPU и увеличивать расходы на API

Для такого сайта опасен не только большой поток запросов. Опасен запрос, который лёгкий для бота, но тяжёлый для серверной части интернет-магазина.

Для бота это может быть один обычный запрос страницы. Для владельца магазина тот же запрос означает процессорное время, работу базы данных и, в некоторых случаях, платные обращения к внешней платформе. Именно поэтому небольшой по меркам DDoS поток автоматизированных запросов способен создавать непропорционально большую нагрузку.

В этом кейсе владелец одновременно наблюдал два симптома: CPU доходил до 98–100%, а количество платных вызовов выросло примерно в 6–7 раз. Само по себе совпадение ещё не доказывает, что каждый бот-запрос породил платный вызов, но оно хорошо согласуется с механикой магазина: автоматизированный обход страниц заставлял сервер выполнять дорогую прикладную работу.

Как запрос бота превращается в платный вызов OTAPI

Когда бот открывает страницу товара, категории или поиска на grandior.ru, сначала он обращается к самому сайту.

Дальше движок интернет-магазина OT Box может обратиться к внешней платформе OTAPI, чтобы получить нужные данные: информацию о товаре, цену, продавца, результаты поиска или другие сведения.

То есть происходит цепочка:

Бот → site-address.ru → движок OT Box → OTAPI → OT Box формирует страницу → ответ боту

Важно понимать: запрос бота к сайту и запрос сайта к OTAPI — это два разных HTTP-запроса.

Например, бот может открыть страницу магазина по HTTP/2, а сервер сайта обратиться к OTAPI по HTTP/1.1. Это не имеет значения для тарификации. OTAPI считает не версию HTTP и не количество соединений, а вызовы своих методов API.

Поэтому один автоматический запрос к странице магазина может вызвать один или несколько платных запросов к OTAPI. Если бот начинает массово обходить карточки товаров, категории и поиск, растёт не только нагрузка на сервер, но и количество платных обращений к OTAPI.

DDoS, L7 DDoS и автоматизированный бот-трафик — разные вещи

В моей практике самое частое и распространённое явление заключается в том, что ощутимая и немалая часть людей используя одну терминологию, на самом деле попадает в заблуждение. Распределённая атака отказа в обслуживании (Distributed Denial of Service, DDoS) — реальный класс атак. Атака на седьмом, прикладном уровне модели OSI (Layer 7, L7) тоже может быть DDoS. Но не всякая автоматизация на уровне HTTP является DDoS.

Поэтому «много IP-адресов из разных стран» ещё не означает DDoS. Парсеры и другие автоматические клиенты используют прокси, виртуальные частные сети (VPN), облачные узлы и большие пулы адресов. Они могут менять IP-адреса и строку идентификации клиента (User-Agent), а каждый отдельный запрос при этом будет выглядеть как обычный запрос браузера.

Ключевой вопрос — не сколько стран видно в статистике, а что делают запросы и какую нагрузку на веб-сервере они создают. Если бот последовательно обходит тяжёлые страницы и из-за этого сервер оказывается перегружен, падение сайта может быть побочным эффектом парсинга данных на сайте. Если множество источников намеренно создаёт поток запросов именно для исчерпания ресурсов и недоступности сайта, это уже L7 DDoS.

Что показала диагностика

Я не делал вывод по одному признаку. Для такого случая недостаточно посмотреть только на загрузку CPU, список IP-адресов или Яндекс Метрику. Нужно сопоставить характер запросов, серверную нагрузку и то, какие функции сайта они затрагивают.

1. Веб-аналитика показывала только часть роботной активности

В счётчике веб-аналитики были заметны роботные визиты, похожие на поведенческую автоматизацию. Но счётчик видит прежде всего тех клиентов, которые загружают страницу достаточно полно и выполняют клиентский JavaScript-код. Многие парсеры, сканеры и простые HTTP-клиенты могут нагружать сервер, вообще не формируя полноценный визит в веб-аналитике. Поэтому «сколько ботов видно в Метрике» и «сколько автоматизированных HTTP-запросов получает сервер» — это разные величины.

2. После переключения трафика через WAF стало видно реальное соотношение классов трафика

Ниже — агрегированные данные за частичный период 16–19 сентября 2026 года. Это не описание внутренних алгоритмов фильтрации, а только итоговые счётчики, достаточные для понимания масштаба. В статистических данных фильтрации трафика указано количество запросов к страницам. Количество запросов к статическим данным не входит в отчет, отображённый в таблице.

Исходя из данных статистики сетевых запросов к сайту виден большой разрыв по объёму между поведенческими ботами и остальным низкуровневым трафиком таким как парсеры, сканеры, взломщики, мусорный и вредоносный трафик. Поведенческие боты составляли около половины процента запросов к страницам, тогда как ранняя автоматизация — почти 42%. Если смотреть только на веб-аналитику, основная часть роботного HTTP-трафика не будет видна. Поисковых роботов нельзя блокировать вместе со всеми остальными ботами.

Для интернет-магазина поисковая индексация критична. Поэтому задача не сводилась к правилу «заблокировать всех ботов». Для индексации сайта с помощью специальных правил сделан пропуск для поисковых краулеров и необходимых для сайта сервисов.

Почему установленный на VPS сервере сторонний антибот модуль не решил именно эту проблему

У защитных продуктов разные задачи и разные модели обнаружения. На сервере антибот модуль уже был установлен и включен, но владелец продолжал фиксировать нежелательных ботов и высокую нагрузку. Поддержка хостинга отдельно поясняла, что продукт не является специализированным средством против парсинга и не гарантирует решение именно такой задачи.

Перед переключением трафика на WAF сервис CRONARMOR, другой сторонний антибот модуль я  отключил, чтобы две независимые системы фильтрации не влияли друг на друга.

Целевая задача была такой: нежелательный HTTP-запрос должен завершиться до того, как попадёт на исходный веб-сервер сайта (origin-сервер) и заставит приложение выполнять PHP-код, обращаться к базе данных или делать внешние вызовы OTAPI. Поисковые роботы и необходимые сервисы при этом должны продолжать работать.

Такой WAF-контур нельзя выдавать за универсальную замену сетевой DDoS-защите. Если забит канал связи, идёт SYN flood, UDP flood или другая крупная объёмная атака, проблема должна решаться выше по сети — у провайдера или специализированной anti-DDoS-инфраструктуры. В этом кейсе узким местом оказался именно прикладной HTTP-трафик и работа веб-приложения.

Что произошло с нагрузкой после переключения

Переключение трафика через отдельный WAF-контур произошло вечером 16 сентября. На недельном графике панели управления сервером непосредственно перед переключением CPU поднимался примерно до 80–100%. После переключения линия резко ушла вниз и дальше оставалась на низком уровне.

Следующие сутки дали более полезную контрольную картину: CPU большую часть времени находился от единиц процентов примерно до 9%. В таблице на первых видимых точках были значения 9%, 2%, 5%, 6%, 3% и далее того же порядка.

После подключения специализированного WAF сервиса CRONARMOR сразу стало видно корреляцию. Сразу резко упала нагрузка CPU VPS сервера, прекратился аномальный рост платных вызовов, снижение роботности в метрике.

Как разбирать похожую ситуацию без терминологической путаницы

• Сначала определить, на каком уровне заканчиваются ресурсы: канал связи, сетевые соединения, CPU, база данных или внешний API.

• Отделить сетевую DDoS-атаку от нагрузки на веб-сайт. Если проблема возникает уже на уровне HTTP и тяжёлых функций сайта, одной сетевой фильтрации может быть недостаточно.

• Смотреть не только на количество IP-адресов, но и на то, какие страницы и функции вызываются. Карточка товара, поиск, калькулятор, авторизация и внешнее API могут иметь очень разную степень нагрузки для сервера.

• Не считать Яндекс Метрику полным источником данных о ботах. Запросы, которые не выполняют JavaScript, могут сильно нагружать сервер и не фиксироваться в Яндекс метрике.

• Не доверять одному User-Agent поискового робота. Легитимные поисковые системы нужно подтверждать отдельно.

• Если сайт использует тарифицируемое внешнее API, учитывать не только CPU, но и стоимость прикладных операций. Для OTAPI один входящий запрос пользователя не равен одному платному вызову.

Что в этом кейсе оказалось важнее самого слова «DDoS»

Для владельца проекта главной задачей было не правильно назвать атаку, а вернуть сервер в нормальный режим нагрузки и прекратить лишние расходы. Тем не менее техническая классификация важна, потому что от неё зависит выбор защиты.

Если бы проблема была в крупной объёмной DDoS-атаке, WAF на HTTP-уровне не решил бы забитый канал. Если бы просто заблокировали всех ботов, пострадала бы поисковая индексация. Если бы смотрели только на веб-аналитику, большая часть автоматизированных запросов осталась бы невидимой.

В этом случае сработало другое: нежелательные HTTP-запросы начали останавливаться до исходного сервера, а легитимный трафик и поисковые краулеры сохранили доступ. После этого загрузка CPU упала с пиковых 80–100% до считанных единиц процентов, а владелец перестал сообщать о продолжающемся росте платных обращений к товарной платформе.

Главный практический вывод: высокая загрузка CPU, тысячи IP-адресов и трафик из десятков стран — это ещё не диагноз DDoS. Сначала нужно понять, какую работу выполняет веб-сайт в ответ на запрос. Иногда реальная проблема заключается не в количестве пакетов, а в том, что каждый автоматизированный запрос запускает тяжёлую серверную логику и внешние платные API-операции.