Снижение нагрузки на сервер с помощью WAF: практический кейс WordPress и WooCommerce
Перегрузка интернет-магазина на WordPress и WooCommerce не всегда связана с ошибками в коде, неоптимальной темой или недостаточной мощностью тарифа. Иногда основная причина находится перед сайтом - в потоке автоматизированных запросов, которые последовательно запускают PHP, WordPress, WooCommerce и обращения к базе данных.
В рассматриваемом случае нагрузка на shared-сервер превышала допустимый лимит более чем на 1200%. Пиковое потребление MySQL достигало 200%, что существенно выходило за рамки бюджетного тарифного плана. При этом на сайте уже работал штатный антибот-фильтр хостинга, но заметного улучшения он не дал.
Характеристики проекта
Объектом анализа был интернет-магазин на WordPress с установленным WooCommerce. Это не огромный маркетплейс, однако и не простой сайт-визитка. На момент проведения работ в базе находились:
- 1319 опубликованных товаров;
- 506 вариаций товаров;
- 22 опубликованные страницы;
- 4 записи;
- 1289 медиафайлов;
- около 71 тысячи строк в таблице `postmeta`;
- более 13 тысяч записей в таблице атрибутов товаров;
- 3604 таксономии.
Такой объём сам по себе не объясняет многократное превышение лимитов процессора. Главную роль играла структура каталога и большое количество динамических адресов, формируемых фильтрами.
Посетитель может открыть товары по категории, бренду, характеристике, диапазону цены и другим параметрам. Каждая комбинация создаёт отдельный URL. Для пользователя это удобный инструмент навигации, а для бота - возможность автоматически перебирать тысячи страниц.
В отличие от изображений, CSS и JavaScript, подобные страницы обычно не отдаются напрямую веб-сервером. Запрос передаётся в PHP, запускает WordPress и WooCommerce, а затем инициирует один или несколько SQL-запросов. Даже несколько сотен обращений в минуту способны создать значительную нагрузку.
Что происходило до подключения внешнего WAF
До начала эксперимента перед сайтом работал штатный антибот-механизм хостинга. Его подключили ранее по обращению владельца проекта, однако перегрузка продолжалась. Это означало, что фильтр либо пропускал значительную часть нежелательного трафика, либо срабатывал уже после того, как запрос успевал создать нагрузку на сервер.
11 сентября 2026 года штатный фильтр отключили через техническую поддержку. После этого перед сайтом настроили внешний облачный WAF CronArmor с индивидуальными правилами обработки трафика.
Ключевое условие сравнения - внутри самого сайта ничего не менялось. Не обновлялись CMS и плагины, не корректировались тема, база данных, структура каталога или логика WooCommerce. Сравнивался один и тот же проект при разных способах фильтрации входящих запросов.
Аналитика была обезличена. В таблицах использовались агрегированные значения без данных, позволяющих идентифицировать сайт или его посетителей. При этом статистика WAF учитывала только обращения к страницам и не включала статические ресурсы. Поэтому её нельзя напрямую сопоставлять с общим количеством запросов или показателями нагрузки, зафиксированными хостингом.
Почему несколько сотен запросов оказываются критичными
Само количество обращений не всегда показывает реальную опасность трафика. Запрос к файлу изображения может обслуживаться значительно дешевле, чем открытие страницы каталога с несколькими фильтрами.
Динамический URL способен вызвать:
1. запуск PHP;
2. загрузку ядра WordPress;
3. инициализацию WooCommerce;
4. обработку таксономий и атрибутов;
5. несколько запросов к `postmeta`;
6. выборку товаров и вариаций;
7. формирование HTML-страницы;
8. запись или чтение данных из кэша.
Если бот последовательно меняет параметры фильтра, сервер выполняет множество похожих, но формально разных операций. Кэш при этом может не помогать: каждый новый набор параметров воспринимается как отдельная страница.
Особенно тяжёлыми становятся запросы с большим количеством условий, неизвестными параметрами, сортировкой и пагинацией. В некоторых случаях бот не просто посещает каталог, а целенаправленно создаёт комбинации URL, которые редко открывают реальные покупатели.
Как работал облачный WAF
Внешний WAF принимает запрос до того, как он достигает backend-сервера. На этом уровне можно оценить IP-адрес, частоту обращений, заголовки, поведение клиента, географию, автономную систему и характер URL.
Подозрительные запросы блокируются или ограничиваются на периферии. В результате они не доходят до PHP и MySQL, а значит, не потребляют ресурсы shared-хостинга.
Для магазина применялись несколько уровней защиты:
- ограничение частоты обращений;
- выявление повторяющихся шаблонов запросов;
- анализ подозрительных фасетных URL;
- поведенческая проверка клиентов;
- фильтрация низкоуровневых автоматизированных запросов;
- блокировка источников с аномальной активностью;
- отдельная обработка краулеров и сканеров.
Такой подход отличается от простого запрета по IP. Один адрес может использоваться несколькими пользователями, а бот способен менять IP. Поэтому важна совокупность признаков: скорость запросов, последовательность переходов, набор URL и характер заголовков.
Результаты после замены фильтра
После включения внешнего WAF нагрузка на сервер заметно снизилась. При этом код сайта и база данных оставались без изменений. Следовательно, основным фактором улучшения стала не внутренняя оптимизация, а сокращение числа тяжёлых запросов, доходящих до backend.
Наиболее важным результатом стало снижение количества обращений, которые запускали WordPress и WooCommerce. WAF отсекал значительную часть автоматизированной активности ещё до передачи запроса приложению.
При анализе трафика выделялись две основные группы:
- низкоуровневые автоматизированные запросы;
- поведенческие боты, имитирующие действия обычного пользователя.
Первая категория обычно выявляется по высокой скорости, однообразным URL и отсутствию признаков полноценного браузера. Вторая сложнее: такие клиенты могут загружать JavaScript, менять страницы и делать паузы между запросами. Для них нужны поведенческие правила и накопление статистики, а не только проверка User-Agent.
Источники запросов и поисковые роботы
Отдельное внимание уделялось географии, ASN и заявленным поисковым краулерам. Само наличие запроса из определённой страны не является доказательством вредоносной активности. Равно как и принадлежность к дата-центру не означает автоматически, что клиент нужно блокировать.
Однако сочетание факторов может указывать на автоматизацию: большое число запросов с одного диапазона, отсутствие нормальной навигации, перебор фильтров и обращение к страницам, не представляющим интереса для обычного пользователя.
Поисковых роботов также нельзя блокировать без разбора. Легитимные краулеры могут быть полезны для индексации, но под видом поискового бота иногда работают скрипты, которые просто меняют User-Agent. Поэтому проверка должна учитывать не только название робота, но и фактическое поведение, частоту обращений и подтверждение источника.
Влияние на показатели аналитики
После фильтрации изменилась и картина в системах веб-аналитики. Сократилось число визитов, сформированных автоматизированными клиентами, которые ранее могли частично имитировать реальные посещения.
Это важно учитывать при интерпретации статистики. После подключения WAF падение количества сеансов не обязательно означает ухудшение маркетинговых результатов. Иногда оно говорит о том, что из отчётов исчез шум: сканеры, парсеры и боты перестали учитываться как посетители.
При этом оценивать эффект нужно не по одной метрике. Следует сопоставлять:
- число реальных заказов;
- конверсию;
- долю отказов;
- скорость ответа сайта;
- ошибки PHP и MySQL;
- нагрузку на CPU;
- количество обращений к динамическим страницам;
- время генерации каталога.
Почему WAF не заменяет оптимизацию
Облачный WAF не устраняет проблемы самого сайта. Если WooCommerce выполняет неоптимальные запросы, отсутствуют индексы или некорректно настроено кэширование, фильтр не исправит архитектурные недостатки.
WAF особенно полезен как первый защитный слой, когда сервер перегружается из-за внешнего трафика. Но при постоянном росте аудитории потребуются и другие меры:
- полноразмерное кэширование страниц;
- оптимизация запросов к `postmeta`;
- проверка индексов базы данных;
- настройка object cache;
- ограничение перебора фильтров;
- каноникализация фасетных URL;
- запрет индексации технических комбинаций;
- перенос тяжёлых задач в фоновые процессы;
- переход на VPS или выделенные ресурсы.
Важно разделять две проблемы: вредный трафик и нормальную нагрузку от покупателей. WAF помогает с первой, но не должен блокировать пользователей, поисковиков и API WooCommerce без проверки.
Практические рекомендации
Перед внедрением защиты полезно собрать базовую статистику хотя бы за несколько дней. Нужно определить часы пиков, самые дорогие URL, источники запросов и долю обращений к фильтрам.
Правила лучше вводить поэтапно. Сначала можно включить наблюдение, затем ограничение частоты и только после анализа - жёсткую блокировку. Это снижает риск случайно перекрыть доступ реальным клиентам.
Для интернет-магазина особенно важно предусмотреть исключения для корзины, оформления заказа, личного кабинета и платёжных интеграций. Эти разделы нельзя защищать теми же правилами, что и каталог.
Также следует регулярно пересматривать настройки. Поведение ботов меняется, источники автоматизированного трафика мигрируют, а новые фильтры или посадочные страницы могут создать неожиданный рост числа динамических URL.
Итог
Рассмотренный кейс показывает, что значительное снижение нагрузки возможно без изменения CMS, темы и базы данных, если основной источник проблемы - автоматизированные обращения к тяжёлым страницам.
На бюджетном shared-тарифе даже несколько сотен запросов к каталогу могут привести к перегрузке MySQL и PHP. Внешний WAF снижает давление на сервер за счёт обработки подозрительного трафика до его попадания в приложение.
Однако это не универсальная замена технической оптимизации. Лучший результат даёт комплексный подход: фильтрация ботов, кэширование, контроль фасетных URL, оптимизация базы данных и мониторинг реальной пользовательской нагрузки.