Владельцы интернет-магазинов на WooCommerce рано или поздно сталкиваются с аномалиями: трафик в веб-аналитике резко взлетает, процент отказов стремится к 100%, время на сайте падает до считанных секунд, а сервер начинает задыхаться от нагрузки на базу данных.
В этой статье разберу реальный кейс атаки на мой интернет-магазин, покажу, как распознать таких роботов по серверным логам и как отрезать паразитный трафик до того, как он положит хостинг или испортит поведенческие факторы сайта.
Симптомы проблемы: что видно в аналитике
Первый тревожный звоночек обычно появляется в Яндекс.Метрике или Google Analytics:
Локализация: аномальный наплыв визитов идет ровно на один раздел каталога (например, /product-category/…).
Поведенческие метрики: время на странице — 4–5 секунд, глубина просмотра — строго 1.01–1.02 страницы, показатель отказов — свыше 99%.
Срабатывание счетчика: поскольку визиты фиксируются в Метрике, боты работают не простыми консольными скриптами (curl), а через полноценные безголовые браузеры (Headless Chrome / Puppeteer / Playwright) с выполнением JavaScript.
Нагрузка на сервер: процессор и MySQL упираются в полку из-за тяжелых выборок в каталоге.
Анализ access.log: анатомия атаки
Если заглянуть в журналы доступа веб-сервера (access.log), картина становится предельно ясной:
Фрагмент кода
x.x.x.x - - [04/Sep/2026:00:00:20 +0300] "GET /product-category/catalog?filter_brend=brand1,brand2,brand3,brand4,brand5&query_type_brend=or HTTP/1.1" 301 - "https://example.com/..." "Mozilla/5.0 ... Chrome/120.0.0.0" x.x.x.x - - [04/Sep/2026:00:00:24 +0300] "GET /product-category/catalog/?filter_brend=brand1,brand2,brand3,brand4,brand5&query_type_brend=or HTTP/1.1" 200 355407 "https://example.com/..." "Mozilla/5.0 ... Chrome/120.0.0.0" x.x.x.x - - [04/Sep/2026:00:00:29 +0300] "POST /?wc-ajax=get_refreshed_fragments HTTP/1.1" 200 476 "https://example.com/..." "Mozilla/5.0 ... Chrome/120.0.0.0"
Что здесь происходит?
- Перебор комбинаций фасетных фильтров WooCommerce:
Робот генерирует случайные связки брендов (filter_brend=brand1,brand2,brand3…). Каждый такой запрос вынуждает WordPress формировать уникальный SQL-запрос WHERE brand IN (…) и отдавать огромную страницу (по 300–400 КБ). Кэш страниц здесь бессилен — комбинации параметров уникальны. - Фокус на маркерах:
В атакующих запросах часто присутствует общий маркер — скрипт обязательно подмешивает один и тот же целевой бренд во все запросы. - Имитация поведения человека:
Бот запрашивает страницу, загружает JS, а затем отправляет фоновый запрос WooCommerce на обновление корзины (POST /?wc-ajax=get_refreshed_fragments). Именно поэтому счетчики аналитики успевают зарегистрировать визит. - Распределенная сеть (DDoS/Scraping):
Каждый запрос идет с нового IP-адреса (резидентные прокси, дата-центры AWS, Hetzner, мобильные пулы). User-Agent рандомизируется под современные версии десктопных браузеров. Забанить один IP или одну подсеть невозможно.
Решение: как заблокировать паразитный трафик
Задача — перехватить запрос на уровне веб-сервера со статусом 403 Forbidden еще до запуска PHP, инициализации ядра WordPress и рендеринга страницы.
Вариант 1. Блокировка по сигнатуре в .htaccess (Apache / OpenLiteSpeed)
Если в атаке выявлен повторяющийся якорь (например, обязательное присутствие одного параметра или скомпрометированного значения фильтра), закрываем его в корневом файле .htaccess строго перед блоком # BEGIN WordPress:
RewriteEngine On
# Блокируем запросы каталога, содержащие навязчивый маркер атакующего скрипта
RewriteCond %{QUERY_STRING} bot_marker_value [NC]
RewriteRule ^product-category/ - [F,L] Вариант 2. Ограничение жадных мультифильтров
Боты генерируют нереалистичные списки, выбирая по 5–8 брендов одновременно через запятую. Живой покупатель редко выбирает больше 2–3 марок разом. Можно превентивно ограничить глубину перебора фильтров:
RewriteEngine On
# Блокируем запросы с 4 и более значениями в filter_brend
RewriteCond %{QUERY_STRING} filter_brend=[^&]*,[^&]*,[^&]*, [NC]
RewriteRule ^product-category/ - [F,L] Запрос с 1–2 брендами откроется штатно, а спам-запрос с простыней значений сразу получит моментальный 403 отбой.
Вариант 3. Блокировка в конфигурации Nginx
Для сайтов, работающих под управлением чистого Nginx:
location /product-category/ {
if ($args ~* "bot_marker_value") {
return 403;
}
# Либо ограничение по числу значений через запятую
if ($args ~* "filter_brend=[^&]*,[^&]*,[^&]*,") {
return 403;
}
try_files $uri $uri/ /index.php?$args;
} Вариант 4. Защита на уровне Cloudflare WAF (самый надежный способ)
Если сайт проксируется через Cloudflare, трафик лучше отсечь на границе сети, не нагружая процессор хостинга вовсе.
Перейдите в Security → WAF → Custom rules → Create rule.
Укажите условия:
- URI Path contains /product-category/
- AND URI Query String contains filter_brend=
- AND Verified Bot equals Off (важно: это исключит Яндекс и Google из проверок)
Выберите действие: Managed Challenge (фоновая JS-проверка).
Обычные посетители пройдут интерактивную проверку за долю секунды, а скрипты автоматизации и боты споткнутся о JS-капчу и не попадут на сервер.
4. Результат
После внедрения правил:
- Нагрузка на сервер снизилась на 70–80%: запросы ботов больше не поднимают тяжелый движок WooCommerce и базу данных.
- Показатели Метрики нормализовались: паразитные визиты с 99% отказов исчезли из отчетов.
- Реальные покупатели не пострадали: стандартная навигация и фильтрация по каталогу продолжают работать быстро и стабильно.
Я воспользовался 1 и 2 вариантом и трафик с ботами пропал.
