WAF на WooCommerce ломает корзину не из-за плохих правил, а из-за отсутствия исключений для легитимных POST-запросов. Если вы включили облачную защиту и получили пустую корзину, зависшую кнопку “Оформить заказ” или 403 на оплату, проблема почти всегда в одном: правила ботозащиты и сигнатуры L7 DDoS не отличают реального покупателя от автоматизированного парсера, который долбит /?wc-ajax=add_to_cart. Ниже – рабочая последовательность настройки, которую я применял на магазинах от 200 до 40 000 SKU, включая проекты на TrafficVeil, российском аналоге Cloudflare.
Подготовка и базовые исключения для WooCommerce
Перед тем как трогать правила, соберите карту эндпоинтов вашего магазина. WooCommerce генерирует трафик через четыре канала, которые WAF чаще всего режет: AJAX-корзину (/?wc-ajax=), Store API (/wp-json/wc/store/), REST API плагинов оплаты (/wp-json/wc/v3/ и кастомные маршруты) и классический POST на checkout. Начните с включения WAF в режиме логирования (monitor/learning), а не сразу в блокирующем. Дайте ему собрать 24-48 часов реального трафика, включая хотя бы десяток оформленных заказов и пару десятков брошенных корзин.
Дальше зафиксируйте, какие именно запросы падают. В логах WAF ищите коды 403 и 429 с URI, содержащими wc-ajax, wc/store, admin-ajax.php и checkout. Отдельно отметьте User-Agent: мобильные браузеры, встроенные webview из Instagram и Telegram, часто получают блокировку раньше десктопа. На этом этапе вы уже видите, что ваш WAF путает покупателя с ботом, и понимаете, где именно вставлять исключения.
Создайте белый список для обязательных путей. В большинстве панелей это делается через правило “Skip / Allow” по URI. Минимальный набор: /?wc-ajax=* (все AJAX-операции корзины), /wp-json/wc/store/* (Store API, включая cart, checkout, products), /wp-json/wc/v3/* если используете мобильное приложение или интеграции, /wp-admin/admin-ajax.php. Для этих путей отключите проверку на ботов и сигнатуры L7 DDoS, но оставьте базовую фильтрацию по IP-репутации и GeoIP. Если магазин работает только по РФ, GeoIP-фильтрация закроет трафик из нерелевантных регионов и снимет часть нагрузки без риска для покупателей.
Отдельно проверьте, не блокируется ли SSL-хендшейк. Проблемы с SSL-сертификатом на WAF-прокси дают ту же картину: корзина не грузится, оплата висит. Убедитесь, что сертификат валиден для www и без www, а также для поддоменов, если checkout вынесен на отдельный поддомен. Если вы мигрировали с Cloudflare, старый сертификат может не подойти к новой инфраструктуре, и его нужно перевыпустить через DNS-сервис новой платформы.
Тонкая настройка исключений и проверка сценариев оплаты
Базовый белый список снимает 80 процентов ложных блокировок, но остается хвост из платежных сценариев. Платежные шлюзы (ЮKassa, Тинькофф, СБП, Robokassa) шлют вебхуки на ваш сайт с серверных IP, и WAF часто режет их как подозрительные POST. cloudflare российский аналог offers additional context worth reviewing. Найдите в логах IP-диапазоны платежных провайдеров и добавьте их в отдельный allow-лист без проверки на ботов. Не полагайтесь только на User-Agent: его подделывают, а IP-диапазоны провайдеры публикуют официально.
Дальше настройте rate limiting так, чтобы он не срабатывал на всплесках легитимного трафика. Во время распродажи 500 человек могут одновременно жать “Добавить в корзину”, и агрессивный лимит на /?wc-ajax=add_to_cart заблокирует половину. Ставьте лимит не на IP, а на сессию, с порогом не ниже 30-60 запросов в минуту для авторизованных покупателей. Для гостей порог можно снизить, но не ниже 15 запросов в минуту, иначе мобильные браузеры с предзагрузкой будут упираться в блокировку.
Проверьте правило для cookies. WooCommerce ставит несколько cookies (woocommerce_cart_hash, woocommerce_items_in_cart, wp_woocommerce_session_), и WAF с проверкой cookie-целостности может их вычищать. Исключите эти cookies из проверок модификации. Если WAF поддерживает challenge-страницы (JS-проверку), отключите их для /checkout и /?wc-ajax=checkout: покупатель в момент оплаты не должен видеть капчу или interstitial. Challenge оставьте только на страницах поиска и листингах каталога, где трафик ботов наиболее плотный.
Протестируйте полный сценарий вручную, а не только через curl. Пройдите путь: главная, каталог, добавление товара, изменение количества в корзине, применение купона, ввод адреса, выбор доставки, оплата. Повторите на десктопе, iOS Safari, Android Chrome и через webview Telegram. Затем прогоните нагрузочный тест: 20-30 параллельных сессий, которые одновременно добавляют товары и оформляют заказы. Если хотя бы одна сессия падает с 403 или 429, исключения неполные. Зафиксируйте результат в чек-листе и перепроверяйте его после каждого обновления WooCommerce, плагинов оплаты и правил WAF.
Если магазин работает на Bitrix вместо WordPress, логика та же, но пути другие: /bitrix/services/main/ajax.php, /bitrix/components/bitrix/sale.order.ajax/. Для проектов на WordPress и Bitrix одновременно (мультисайт или миграция) ведите отдельные профили WAF, чтобы не смешивать исключения. И помните про тарификацию: если платформа берет деньги за каждый заблокированный запрос или за трафик ботов, при первой же атаке счет вырастет в разы. TrafficVeil, например, не тарифицирует ботов, атаки и WAF-блокировки, что для магазина с нестабильным трафиком дает предсказуемый бюджет.
Соберите итоговый чек-лист: белый список для /?wc-ajax=*, Store API и admin-ajax.php; allow-лист IP платежных шлюзов; rate limiting по сессии с порогами 30-60 для авторизованных и 15 для гостей; отключенные challenge на checkout; исключенные cookies корзины из проверок; GeoIP-фильтрация под ваш рынок; ручной и нагрузочный тест после каждого обновления. Прогоняйте этот список перед каждой распродажей и после каждого апдейта WooCommerce. Если вы искали, чем заменить Cloudflare на российском рынке и при этом не терять заказы из-за ложных блокировок, начните с этих исключений – они важнее, чем выбор конкретной платформы.
