До 2025 г. цифровият пейзаж се е променил: CAPTCHA вече не е надежден пазител, какъвто беше някога. Докато ботовете, управлявани от изкуствен интелект, решават CAPTCHA пъзели с почти перфектна точност, истинските потребители остават разочаровани и често изоставят сайтовете, когато бъдат предизвикани. Последните изследвания показват, че ботовете вече минават през базирани на изображения и текстови CAPTCHA с 96–100% успех—далеч надминавайки реалните човешки успехи и намалявайки конверсиите на формуляри с до 20%. Но проблемът отива много по-дълбоко от всяка остаряла пъзелна игра.
Днес, автоматизираният трафик доминира в мрежата. Разбрах това лично. През 2024 г. се оценява, че почти половината от цялата онлайн активност е генерирана от ботове, като до 37% са класифицирани като откровено злонамерени. Дори сайтове с активни мерки за смекчаване все още съобщават за 10–20% текуща бот активност. Реалността е жестока: традиционните решения като CAPTCHA и IP черни списъци са станали почти безсилни пред координирани, бързо развиващи се ботнети, които могат да имитират реални потребители, да преминават през нови IP адреси и дори да експлоатират мобилни устройства за мащабни атаки.
За собствениците на уебсайтове и онлайн бизнесите, въздействието е опустошително. Бот наводненията могат да осакатят сървърните ресурси, да забавят зареждането на страниците до пълзене и да развалят потребителското изживяване. Но ефектите се разпространяват по-далеч—класирането в Google пада, когато производителността на страниците се влошава, приходите от реклами изчезват, когато качеството на трафика спада, и отношенията с рекламни партньори се влошават, когато фалшивите посещения заливат техните анализи.
Изпитах тази криза от първа ръка. Всичко започна с обвинение от рекламна агенция: те твърдяха, че 90% от трафика на моя сайт е фалшив. Техният проследяващ код, вграден за доставката на реклами, разкри обеми на бот трафик, които не само надминаваха техните филтри, но и моят сървър. Говорим за над милион бот посещения на ден—трафик, невидим за Google Analytics, но катастрофален зад кулисите. Това, което първоначално смятах за истински потребители, всъщност беше част от безмилостна вълна от автоматизирани удари, които наводниха моята инфраструктура и застрашиха жизнеспособността на целия ми проект.
Това не е просто история за лоши актьори, които експлоатират слабости—става въпрос за това как самата архитектура на съвременната мрежа е под обсада. Оптимизациите на кода и обновленията на сървъра не бяха достатъчни. Предизвикателството се превърна в надпревара във въоръжаването, като моят сайт беше хванат в кръстосания огън. Ето как се разгърна бот наводнението, почти унищожавайки всичко, което бях изградил—и стъпките, които предприех, за да се боря обратно.
Моята история с бот трафик: от 3 милиона посещения на сайт до половин милион
Всичко започна с рекламна агенция, която ме обвини в 90% фалшив трафик, вече го казах, но: те бяха поставили код за проследяване на моя сайт, за да доставят реклами, а обемът на ботите беше проблем и за тях – той претоварваше техните филтри и увеличаваше натоварването на сървъра. Говорим за над милион посещения от ботове на ден.
В началото бях възмутен. В Google Analytics виждах 100,000 чисти дневни посещения. Истински потребители, мислех си. Но техният проблем беше с трафик извън Analytics. Този невидим слой от посещения създаваше хаос в натоварването на сървъра. Тогава, моят проект работеше на Laravel 5.3, хостван на споделен хостинг, и вярвах, че проблемът с производителността е в старата кодова база. Пренаписах всичко в Laravel 10 с отлична оптимизация, включително ежедневен анализ на милиони записи в базата данни.
Все пак, изоставаше. Моят споделен хостинг не можеше да го понесе. Зареждането на страниците се забавяше, а реалният трафик спадаше – месец след месец губех около 150,000 посещения. От 3 милиона месечни посещения, в крайна сметка загубих повече от половината.
Бях се обновил на мощен VPS с 16 ядра на процесора и 32GB RAM, очаквайки това да реши всичко. Но дори с подобрената инфраструктура и пренаписания Laravel 10 бекенд, проблемът оставаше. Всъщност, нещата се влошиха – ботовете станаха по-агресивни, увеличавайки обема и честотата на атаките си. Стана ясно, че никаква оптимизация на кода или мащабиране на хардуера не може да реши проблем, който е фундаментално свързан с неконтролиран, злонамерен бот трафик.
Но това не беше всичко. При по-дълбоко вникване, осъзнах, че мащабът е дори по-голям: над 2 милиона обхождания на сайта на ден, отделно от около 1.5 милиона дневни посещения от ботове. И все пак, монетизируемата, проследима част от сайта (тази, която агенциите се интересуваха) носеше само 100,000 импресии на ден. Там проблемът ескалира. Работех с рекламна агенция, която разчиташе на чист, човешки трафик. Те трябваше бързо да намерят начини да филтрират ботовете, иначе техните аналитични и рекламни системи щяха да бъдат претоварени. Обвиненията, претоварването на инфраструктурата и разминаванията в приходите – всички те бяха свързани с този невидим, безмилостен поток от ботове.
Първото ми действие беше да създам персонализиран CAPTCHA, целящ да покаже на ботовете празна страница, докато реалните потребители преминават. За съжаление, това се обърка. Злонамерените ботове не се забавиха – те увеличиха скоростта си. CAPTCHA стана предизвикателство, което те агресивно се опитваха да преодолеят, удвоявайки натоварването.
След това дойде масово блокиране чрез .htaccess. Работи – за няколко дни. След това бот мрежите се адаптираха, появиха се нови IP адреси и .htaccess стана претрупан и бавен. Моят хостинг доставчик се намеси, помагайки да блокираме цели подсети временно, но проблемът се връщаше всяка седмица.
Накрая се обърнах към Cloudflare. Това беше най-въздействащата промяна. Макар че не е съвършено, ми позволи да филтрирам над 1.5 милиона заявки от ботове в рамките на 24 часа. Качих мрежови блокове директно в тяхната защитна стена. Резултатът? От 1.5 милиона ботове, само 20 CAPTCHA предизвикателства се задействаха ежедневно – доказателство, че откриването на Cloudflare работи по-добре от всичко друго, което съм опитвал.
За да остана напред пред ботовете, изградих собствена вътрешна система за регистрация. Тя записва всяка заявка по IP адрес и User-Agent низ, съхранявайки ги в база данни. Зад кулисите планирана задача се изпълнява всяка минута, за да обобщи данните. Когато засече подозрителна активност – като голям обем запитвания от една мрежа или обхват от IP адреси – задейства автоматично уведомяване по имейл. Този имейл включва списък с IP адреси и подсети, готови за добавяне към Cloudflare за блокиране.
Все още съм на безплатния план на Cloudflare, но дори той предоставя достатъчен контрол за прилагане на ръчни правила за защитна стена. Този проактивен подход ми позволява да откривам и отговарям на бот наводнения, преди да претоварят системата. На ниво Apache, първоначално опитах да използвам .htaccess за директно блокиране на трафика, но този метод имаше намаляваща възвръщаемост. С нарастването на правилата, производителността на сайта се влошаваше, което ясно показваше, че блокирането на ниво сървър не е устойчиво без CDN или поддръжка на ниво край.
Как да направим система за вход + защита от CloudFlare?
Защо не ограничение на скоростта или гео-блокиране? Защото те не работят в моя случай. Повечето от тези ботове правят само едно заявяване на IP – но го правят, използвайки стотици или дори хиляди IP адреси в рамките на една и съща мрежа. Това означава, че ограничението на скоростта по IP не помага много; обемът е разпределен, а не концентриран. А какво ще кажете за откриването им по User-Agent? Безполезно. Някои ботове са достатъчно умни, за да имитират Googlebot или други легитимни обхождачи, така че не можете да се доверите само на хедърите. А какво ще кажете за филтриране по гео-локация? Също не е ефективно. Моят сайт е многоезичен и получава трафик от много страни по дизайн. Тези мрежи за наводнения знаят това и въртят IP адреси от цял свят. Може би ме обхождат, защото сайтът ми има ценно съдържание – но не мога просто да го заключа зад стена за регистрация. Това би развалило потребителското изживяване. Затова ми трябваше нещо по-интелигентно от обичайните решения.
Вижте моя код, MYSQL заявки и препоръки по-долу. (Laravel 10 + MYSQL)
