Снижение нагрузки на сервер с помощью WAF: реальный кейс WordPress/WooCommerce

Практический кейс, основанный на данных мониторинга ресурсов Beget и внутренней аналитики облачного WAF

В данном кейсе я рассмотрю решение проблемы с повышенной нагрузкой shared-сервера на веб-проекте с применением индивидуальной WAF-фильтрации трафика. Перегрузка сайта, расположенного на shared-сервере, достигала более 1200% от допустимого лимита в рамках бюджетного тарифного плана. Нагрузка БД MySQL достигала в пиках до 200%, что значительно превышало лимиты shared-хостинга на бюджетном тарифном плане. На момент начала работ на сайте уже был подключен штатный антибот-фильтр Beget, который ранее по запросу клиента включила техническая поддержка shared-хостинга, однако ситуация с перегрузкой ресурсов после этого не улучшилась: перегрузка сохранялась. 11 сентября 2026 года этот фильтр был отключён через техподдержку хостинга уже по моему целенаправленному запросу, после чего перед тем же сайтом был включён и настроен внешний специализированный облачный WAF-сервис CronArmor. Важное условие кейса: внутри самого сайта в сравниваемый период ничего не оптимизировалось и не перенастраивалось. Код, CMS, тема, плагины, структура базы данных и логика WooCommerce не менялись. Поэтому ниже сравнивается один и тот же сайт при двух разных подходах к внешней фильтрации трафика.

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

Что представлял собой объект, на котором проводилась работа

Это интернет-магазин на CMS WordPress с WooCommerce. По диагностике в базе данных было 1319 опубликованных товаров и 506 вариаций, 22 опубликованные страницы, 4 записи и 1289 вложений. То есть это не гигантский каталог на десятки тысяч товаров, но и не простой лендинг: каждый запрос к каталогу проходит через полноценный WordPress/WooCommerce-стек.

Ключевой технической особенностью интернет-магазина является большое пространство фасетных URL. Комбинации категорий и товарных атрибутов могут создавать множество динамических адресов, хотя физически товаров всего 1 319. Для обычного посетителя это удобно, а для парсера, сканера или краулера — возможность обходить тысячи комбинаций. Такие запросы значительно тяжелее, чем обращения к статическим файлам: они могут запускать WordPress, WooCommerce и SQL-выборки по товарам и атрибутам. Фасетные URL — это страницы каталога, которые формируются из комбинаций фильтров: категории, бренда, характеристик, цены и других параметров. Чем больше таких параметров, тем больше возможных URL может автоматически перебирать парсер или сканер.

Поэтому сама по себе частота запросов ещё не показывает реальную нагрузку. Даже при относительно небольшом RPS (Requests Per Second) автоматизированный клиент может заметно нагружать сервер, если последовательно открывает динамические страницы каталога, фильтры, поиск и другие URL, для которых каждый раз требуется обработка PHP и запросы к базе данных. Именно трафик сканеров, парсеров и других автоматизированных клиентов, обращающихся к динамическим страницам, представлял наибольший интерес при подключении WAF.

Что было до замены антибот фильтра

По месячным графикам Beget было видно несколько выраженных всплесков. Наиболее показательный участок — 9 сентября: суточная нагрузка сайта достигала 1263,06 CP, а суммарная нагрузка базы данных — 5032 CP. В почасовом графике базы данных в 09:00 фиксировался пик 999 CP.

Сам по себе график Beget не позволяет точно определить природу нагрузки на веб-сервер. Программная конфигурация и особенности механики работы движка сайта делают его особенно чувствительным к автоматизированному обходу: запрос к категории, фильтру или другой динамической странице способен запустить PHP и серию SQL-операций. Поэтому даже парсер или сканер с невысокой частотой запросов может создавать непропорционально большой CP/MySQL-след. WAF подключался именно как внешний слой, который должен был остановить такой трафик до origin.

Многоуровневый облачный WAF как вынужденная мера

До начала работ антибот-фильтр Beget уже был включён технической поддержкой хостинга. Несмотря на это, нагрузка на shared-хостинг продолжала значительно превышать допустимые значения: 9 сентября суточная нагрузка сайта достигла 1263,06 CP, а нагрузка базы данных — 5032 CP.

Перед подключением нового WAF-контура антибот-фильтр трафика Beget был отключён через техподдержку. После этого изменения производились только на внешнем контуре обработки HTTP-трафика. В WordPress, WooCommerce, теме, плагинах, PHP-коде и базе данных ничего не менялось. Поэтому нельзя сказать, что на динамику изменения нагрузки на веб-сервер повлияло что-то ещё.

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

После замены подхода к защите сайта фильтрация трафика стала опираться не на волшебную однокнопочную проверку всех клиентов, а на классификацию запросов: доверенный трафик и валидированные поисковые роботы, нужные SEO-сервисы и технические процессы пропускались, часть автоматизированных запросов отправлялась на дополнительную проверку, а явно нежелательные обращения останавливались до WordPress/WooCommerce.

Таблица важна ещё по одной причине: это не сравнение старой версии сайта с новой. Сайт, движок, его программная конфигурация оставались теми же; менялся только внешний способ допуска HTTP-запросов к origin.

Что было видно в запросах, доходивших до backend-сервера

Диагностика access-логов до подключения WAF показала не только высокий CP, но и характерный рисунок внешнего трафика. Если не учитывать служебные запросы самого хостинга, за сутки до backend-сервера дошло около 23,5 тыс. внешних запросов примерно с 19,2 тыс. уникальных IP-адресов. То есть большинство источников делали всего один или несколько запросов. 

Такая картина трафика не похожа на классический объёмный DDoS с несколькими источниками атаки, которые непрерывно «молотят» сайт. Она гораздо ближе к распределённому автоматизированному обходу: большой пул адресов, низкая частота с каждого IP и запросы к дорогим динамическим страницам. Именно поэтому простая оценка RPS здесь вводит в заблуждение — один фасетный URL может грузить origin заметно сильнее десятков обращений к статике.

В логах встречались длинные комбинации товарных атрибутов в адресах вида «/product-category/<категория>/<атрибут>-<значение1>-or-<значение2>/». Для парсера или сканера это практически неограниченное пространство обхода. Для WooCommerce — динамическая обработка и обращения к базе.

Что изменилось после подключения WAF

• Сначала через техническую поддержку был отключён ранее действовавший антибот-фильтр Beget. Затем перед сайтом включён внешний облачный WAF-контур, который классифицирует и фильтрует запросы до передачи на origin.

• Внутри сайта в этот момент ничего не менялось: не проводилась оптимизация WordPress/WooCommerce, не менялись код, тема, плагины, структура БД или настройки приложения. Таким образом, достигнутый эффект нельзя объяснить внутренним тюнингом сайта: изменился только внешний механизм фильтрации трафика.

• Для подозрительного трафика используются несколько уровней проверки: низкоуровневая фильтрация, дополнительная проверка и браузерная проверка поведенческих ботов.

• Валидированные поисковые краулеры и нужные проекту SEO-сервисы и технические процессы пропускаются отдельно. Это обеспечивает качественную стабильную индексацию сайта и работу всего функционала проекта.

Что произошло с нагрузкой после замены фильтра

К 12 сентября уже были доступны полные суточные данные по базе данных, а на 13 сентября — актуальное значение нагрузки сайта. Внутри WordPress/WooCommerce за это время ничего не менялось. Основным изменением стала только замена штатного фильтра хостинга на внешний WAF с селективной фильтрацией трафика.

Особенно показательно поведение MySQL: полный суточный показатель после подключения защиты составил 128 CP против 5 032 CP на пике несколькими днями ранее. Это снижение примерно на 97,5%. Почасовой максимум в сравниваемых точках снизился с 999 до 15 CP — примерно в 66 раз.

Это наблюдение «до/после», а не лабораторный A/B-тест: входной интернет-трафик невозможно воспроизвести дважды абсолютно одинаково. При этом внутри сайта параллельных изменений не было, прежний фильтр не устранял перегрузку, а новый WAF одновременно фиксировал и останавливал парсерный, сканирующий, поведенческий и другой автоматизированный трафик.

Обновлённые месячные графики на 14 сентября уже показывают несколько точек после подключения WAF. При этом крайняя точка за 14 сентября относится к неполным суткам, поэтому она не используется для количественного сравнения. Расчёты снижения нагрузки в таблице выше основаны на ранее зафиксированных значениях за 12–13 сентября.

Что происходило с трафиком: данные WAF

Ниже я привожу агрегированные значения. По ним видно, какие категории запросов реально отсеивались и какие оставались разрешёнными.

Сводка за частичный период 11–13 сентября

Внутренняя аналитика показывает, как трафик проходит проверки, а не только считает отдельные запросы. Поэтому один запрос может попасть сразу в несколько счётчиков. Для оценки фактической нагрузки на сервер мы смотрим прежде всего на CP Beget.

Последние сутки: низкоуровневые автоматизированные запросы

За последние сутки WAF-система классифицировала 694 низкоуровневых автоматизированных запроса. Из них 375 (54,0%) были остановлены, 319 (46,0%) — разрешены. В эту категорию попадают сканеры, парсеры, сервисные роботы и другие клиенты, которые не следует автоматически считать одинаково вредоносными: задача WAF — отделить нежелательный обход от легитимной автоматизации.

Показательный контроль качества фильтрации: 314 служебных WordPress-запросов в этой выборке не были «срезаны вместе со всеми роботами» и все они были разрешены. Это важно для интерпретации результата: падение нагрузки достигалось не тотальным запретом автоматизированного трафика, а выборочной фильтрацией нежелательных запросов.

Одновременно в TOP User-Agent присутствовали серии автоматизированных обращений из зарубежных облачных ASN к страницам каталога и нетипичным служебным путям. Такие серии в основной массе останавливались. В статье я намеренно не публикую IP-адреса, fingerprints и подробную логику правил.

Для WooCommerce особенно опасен не объём сам по себе, а направление обхода. Если автоматизированный клиент идёт по категориям, фильтрам и сочетаниям товарных атрибутов, каждый запрос может быть динамическим и тяжёлым для PHP/MySQL. Поэтому фильтрация парсеров и сканеров на внешнем WAF снимает нагрузку раньше, чем запрос успевает инициировать тяжёлую работу CMS.

Последние сутки: поведенческие боты

В отдельной поведенческой выборке за сутки было классифицировано 209 ботов, связанных со 188 уникальными IP, а система остановила 291 нежелательный запрос. Источники распределялись по 15 странам и 34 автономным системам. Это показывает, что нагрузка не была следствием одного-единственного адреса или простого «залёта» одного сканера.

Ноль в строке «живые люди, прошедшие проверку поведенческих ботов» относится только к выбранной поведенческой выборке, а не к сайту в целом. Это не означает отсутствие реальных посетителей.

Откуда приходили запросы

Наибольший объём в этой классификации приходился на прямые запросы. При этом большая часть прямого трафика не прошла напрямую до сайта: 4 907 запросов были остановлены, ещё 5 316 отправлены на проверку.

GEO, ASN и поисковые краулеры

Большая доля US-трафика сама по себе не доказывает атаку: в американских ASN находятся крупные платформы, краулеры и облачная инфраструктура. Поэтому GEO и ASN используются только как дополнительные признаки, а не как самостоятельная причина блокировки.

Это важная часть кейса: на фоне агрессивной фильтрации валидированные запросы Яндекса и Google не были заблокированы. Значит, разгрузка origin не достигалась ценой отключения поисковой индексации.

Почему несколько сотен запросов могут заметно влиять на MySQL

Количество запросов и потребление CP не связаны линейно. Для этого магазина это особенно важно: при 1319 товарах, 506 вариациях, тысячах терминов и более чем 13 тысяч записей в product-attribute lookup автоматизированный обход фасетных URL способен создавать тяжёлые динамические обращения. Один запрос к фильтру каталога может грузить сервер намного сильнее, чем десятки запросов к статике. Поэтому сотни запросов парсеров и сканеров способны давать непропорционально большую нагрузку на shared-хостинге.

В этом кейсе это особенно заметно по базе данных: после того как часть автоматизированных обращений перестала доходить до WordPress/WooCommerce, суточный CP MySQL снизился с 5032 до 128, а сравниваемый почасовой пик — с 999 до 15. При этом внутри сайта ничего не оптимизировалось, поэтому такое изменение нельзя объяснить чисткой БД, изменением кода или настройкой CMS.

Что изменилось в Яндекс Метрике

Дополнительное изменение состава трафика видно в Яндекс Метрике. Для сравнения использовался встроенный сегмент «Поведение → Роботность → Только роботы». За период 7–13 сентября Метрика учла в этом сегменте 105 визитов. До подключения внешнего WAF роботные визиты фиксировались ежедневно и держались примерно на уровне 16–26 визитов в сутки. После подключения защиты 11 сентября график резко снизился: 12 сентября в сегменте остался единичный роботный визит, а 13 сентября роботные визиты не фиксировались.

Отдельно показателен отчёт по отказам в том же роботном сегменте. В выбранном периоде Метрика зафиксировала 103 визита с нулевым временем на сайте, которые учитывались как отказы. По графику все эти роботные отказы пришлись на период до 12 сентября. После подключения WAF 12 и 13 сентября визиты с нулевым временем в сегменте «Только роботы» не фиксировались.

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

Что показал этот кейс

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

• Очистка трафика от паразитного, мусорного, вредоносного трафика может давать ощутимый результат в виде значительного снижения нагрузки как на PHP так и на БД MySQL

• Низкий RPS сам по себе не означает низкую нагрузку. Несколько сотен запросов к динамическим страницам каталога, фасетным фильтрам и другим тяжёлым URL могут создавать большую нагрузку на WordPress/WooCommerce.

• Штатный антибот-фильтр Beget показал свою неэффективность для решения данной конкретной задачи, связанной с перегрузкой сервера и избыточным веб-трафиком.

• Эффективная фильтрация не должна означать топорную примитивную блокировку по Java Script, Cookie. Валидированные поисковые краулеры, служебные запросы WordPress и необходимые проекту сервисы нужно пропускать на сайт отдельно с помощью индивидуальных правил фильтрации трафика, одновременно останавливая нежелательную автоматизацию.

• Облачный WAF-сервис CronArmor с многоуровневой фильтрацией особенно эффективен для WordPress/WooCommerce-проектов с большим количеством динамических и фасетных URL, где автоматизированный обход может создавать непропорционально высокую нагрузку на PHP/MySQL.

• Показатели нагрузки на бюджетных тарифных планах на shared хостинге Beget это не маркетинг и не принуждение к переходу на более дорогие тарифные планы, а объективная нагрузка, которую нельзя увидеть без специализированных инструментов.

Почему WAF не всегда позволяет существенно снизить нагрузку

Не всегда удаётся получить существенное снижение нагрузки только за счёт одного подключения многоуровневого WAF c индивидуальной фильтрацией трафика. Есть ряд других объективных причин, которые могут создавать критичные проблемы с нагрузкой на ресурсы сервера. Поэтому перед подключением защиты сайта нужно понимать, что существует множество различных факторов нагрузки и они разные для разных веб-сайтов.

Итог

Кейс начался с обычной жалобы на перегрузку shared-хостинга, и сотрудники проекта были уверены в том, что чрезмерно высокая нагрузка создаётся автоматизированным трафиком. У меня такой уверенности не было, и я сам не знал, какой будет итоговый результат после подключения и настройки защиты сайта от ботов, парсеров, сканеров, поведенческих ботов. Диагностика показала, что интернет-магазин работает на WordPress/WooCommerce с 1319 товарами, 506 вариациями и большим пространством динамических фасетных URL, которые сами по себе вполне могут создавать высокую нагрузку на сервер. Также краулеры поисковых систем тоже способны создавать очень высокую нагрузку на сервер, и блокировать их нельзя в любом случае. После подключения специализированного WAF-контура и настройки фильтрации трафика появилась возможность остановить парсерный, сканирующий и другой мусорный трафик до origin, сохранив при этом индексацию сайта поисковыми системами и доступ к сайту всех необходимых проекту сервисов. По проведённым измерениям после подключения специализированного WAF сервиса суточная нагрузка сайта снизилась примерно в 45 раз, суточная нагрузка базы данных — примерно в 39 раз, а сравниваемый почасовой пик MySQL — примерно в 67 раз.

Ключевое условие кейса — внутри сайта в этот период ничего не менялось. До работ на стороне хостинга уже действовал антибот-фильтр Beget, но перегрузка сохранялась. 11 сентября этот фильтр был отключён и заменён селективным внешним WAF. Кеширование сайта уже было внутри CMS на уровне специальных плагинов WordPress. Оптимизация CMS или базы не проводилась, код сайта и другие части движка не менялись. При этом новая фильтрация не работала по принципу тотальной блокировки: служебные запросы WordPress в контрольной низкоуровневой выборке в основном пропускались, а валидированные поисковые роботы Яндекса и Google и необходимые проекту сервисы пропускались на сайт с помощью специальных правил. Достигнутый практический результат: уменьшение работы, которую приходилось выполнять PHP/MySQL, за счёт отсечения ненужных запросов до сайта.