166 000 посещения за един ден и нито една продажба

Високият трафик към един онлайн магазин обикновено е добра новина. Но когато сайтът започне да се бави точно в момента, в който статистиката показва рязък скок в посещенията, картината може да се окаже съвсем различна.

Наскоро попаднах точно на такъв случай при WooCommerce магазин на наш клиент. Сайтът ту се зареждаше нормално, ту започваше да се бави, а в статистиките се виждаха над 166 000 посещения само за един ден – необичайно много за иначе сравнително спокоен онлайн магазин.

На пръв поглед изглежда като страхотен ден за магазина. Само че зад тези посещения не стояха потенциални клиенти, а ботове, които обхождаха продуктовите филтри и генерираха огромен брой заявки към сървъра.

В тази статия ще покажа как открихме откъде идва натоварването, какво общо имаха WooCommerce филтрите с него и как едно Cloudflare правило промени ситуацията.

Какво всъщност се случваше

Ако имаш WooCommerce магазин (в случая с тема WoodMart), филтрите за цвят, размер, цена, наличност и подредба генерират URL адреси с query параметри, като това:

/shop/?filter_color=black
/shop/?filter_size=large&query_type_size=or
/shop/?min_price=50&max_price=100&orderby=price
/shop/?filter_category=lighting&stock_status=instock

За човек това са няколко клика. За ботовете е като детска площадка. Комбинираш няколко цвята, два размера, ценови диапазон и подредба, и изведнъж имаш десетки хиляди уникални адреса. Всеки от тях изглежда като нова страница.

Тези адреси почти не се кешират. Кеш плъгинът пази нормалните страници, но всяка нова комбинация филтри е „студена“ заявка. След първо зареждане, тя се кешира, но почти няма втора заявка с тази комбинация. Google описва точно този проблем под името faceted navigation и е добре известен казус.

Накратко – изглеждаше като трафик. А всъщност беше атака, само че възпитана, в по-учтивата си версия.

Как изглежда това от гледна точка на сървъра

Нека да погледнем и графиките на натоварването. Времето на скриптовете и базата достигаше от около 5000 до 6000 минути на ден. Това не е CPU процент, а чисто време, в което процесорите са заети с обработка на заявките.

Няма грешки в логовете, няма проблемен плъгин. CPU-то е на 100%, паметта е на максимум, а причината са заявките с ?filter_ в адреса.

Решението с Cloudflare правило

Наскоро попаднах на статия в блога на WoodMart, в която екипа споделят за казуса и дават обяснение. Тествах я с реален казус и си свърши работата, затова я разказвам от първо лице.

В Cloudflare отиваш на Security → Security rules → Create rule → Custom rules и пускаш Managed Challenge за заявки, които съдържат филтърните параметри:

(http.request.uri.query contains "filter_") or
(http.request.uri.query contains "per_page=") or
(http.request.uri.query contains "per_row=") or
(http.request.uri.query contains "shop_view=") or
(http.request.uri.query contains "stock_status=") or (http.request.uri.query contains "min_price=") or
(http.request.uri.query contains "max_price=") or
(http.request.uri.query contains "orderby=")

Какво прави това? Когато има заявка с филтър в адреса, Cloudflare показва Managed Challenge, преди тя изобщо да стигне до сървъра. Истинският посетител минава през него веднъж и продължава към сайта. Ботовете не преминават тази проверка.

Резултатът – от над 184 хиляди заявки, над 179 хиляди бяха блокирани. Пиковете на потребление на процесорите, които виждах преди, просто изчезнаха. И най-важното – сайтът спря да се бави.

Бъди внимателен, когато го прилагаш

Преди да копираш правилото едно към едно, прочети нататък. Има няколко особености.

Managed Challenge и AJAX не са най-добри приятели. WoodMart филтрите работят през AJAX, а challenge страниците на Cloudflare не се разбират идеално с XHR заявки. На практика първата филтърна заявка се отваря като нормална страница с challenge, минаваш го, и оттам нататък AJAX филтрирането работи нормално. Точно затова го тествай – провери първия филтър, после още няколко, на десктоп и на телефон. Ако се покаже challenge съдържание, не пускай правилото в този вид.

„filter_“ е широко обхватно, и то нарочно. Хваща filter_color, filter_size, filter_category и всичко друго, което започва с filter_. Удобно е, но ако някъде другаде в сайта се използва същият текст, може да се филтрира и легитимен трафик. След като пуснеш правилото, гледай Security Events в Cloudflare няколко дни и пренареди при нужда.

Правилото пази магазина, но не мисли вместо теб за SEO. То спира натоварването, не управлява индексирането. Затова са robots.txt, canonical адресите и SEO настройките на магазина. Пример за robots.txt:

User-agent: *
Disallow: /*?*filter_
Disallow: /*?*min_price=
Disallow: /*?*max_price=
Disallow: /*?*orderby=

И понеже злонамерените ботове весело пренебрегват robots.txt, той не замества Cloudflare правилото, а върви заедно с него.

Googlebot е отделен разговор. Cloudflare може да разпознава верифицирани ботове (cf.client.bot). Можеш да пуснеш Googlebot да минава без challenge, за да не пипаш обхождането, но тогава пращаш повече заявки към сървъра. Или го ограничаваш и пестиш ресурс, но внимаваш какво става с индексирането. Зависи от SEO стратегията на конкретния магазин, универсален отговор няма.

И така

Не всеки скок в статистиките е добра новина. Понякога 166 000 „посещения“ означават натоварен сървър и нула продажби. Хубавото е, че за този конкретен сценарий, WooCommerce и WoodMart филтри, обхождани от ботове, решението е сравнително просто с Cloudflare.

Оригиналната статия на екипа на WoodMart, върху която стъпих: https://xtemos.com/blog/how-to-stop-bot-traffic-to-woodmart-product-filters-with-cloudflare/