Do roku 2025 se digitální krajina změnila: CAPTCHA již není spolehlivým strážcem, kterým bývala. Zatímco boti řízení umělou inteligencí řeší CAPTCHA hádanky s téměř dokonalou přesností, skuteční uživatelé jsou frustrováni a často opouštějí stránky, když jsou vyzváni k ověření. Nedávné studie ukazují, že boti nyní bez problémů zvládají obrazové a textové CAPTCHA v 96–100 % případů—výrazně překonávají úspěšnost skutečných uživatelů a snižují konverze formulářů až o 20 %. Ale problém sahá mnohem hlouběji než jakákoli zastaralá hádanka.
Dnes automatizovaný provoz dominuje webu. Osobně si to uvědomuji. V roce 2024 se odhadovalo, že téměř polovina všech online aktivit byla generována boty, přičemž až 37 % bylo klasifikováno jako vyloženě škodlivé. I weby s aktivními opatřeními stále hlásí 10–20% probíhající botovou aktivitu. Realita je tvrdá: tradiční řešení jako CAPTCHA a blacklisty IP se staly téměř bezmocnými tváří v tvář koordinovaným, rychle se vyvíjejícím botnetům, které mohou napodobovat skutečné uživatele, cyklovat čerstvé IP adresy a dokonce zneužívat mobilní zařízení pro velké útoky.
Pro vlastníky webů a online podniky jsou dopady devastující. Botové záplavy mohou ochromit serverové zdroje, zpomalit načítání stránek na minimum a zničit uživatelskou zkušenost. Ale účinky sahají dál—Google hodnocení klesá, když se výkon stránek zhoršuje, příjmy z reklam mizí, když kvalita provozu klesá, a vztahy s reklamními partnery se zhoršují, když falešné návštěvy zaplavují jejich analytiku.
Tuto krizi jsem zažil na vlastní kůži. Vše začalo obviněním od reklamní agentury: tvrdili, že 90 % návštěvnosti mého webu je falešných. Jejich sledovací kód, vložený pro doručování reklam, odhalil objemy botů, které zahlcují nejen jejich filtry, ale i můj server. Mluvíme o více než milionu botových návštěv denně—provoz neviditelný pro Google Analytics, ale katastrofální v zákulisí. Co jsem původně považoval za skutečné uživatele, bylo ve skutečnosti součástí neúprosné vlny automatizovaných zásahů, zaplavujících mou infrastrukturu a ohrožujících životaschopnost celého mého projektu.
To není jen příběh o špatných hercích využívajících slabin—jde o to, jak je samotná architektura moderního webu pod útokem. Optimalizace kódu a upgrady serverů nestačily. Výzva se stala závodem ve zbrojení, s mým webem chyceným v křížové palbě. Zde je, jak se botová záplava rozvinula, téměř zničila vše, co jsem vybudoval—a kroky, které jsem podnikl, abych se bránil.
Můj příběh o provozu botů: Z 3 miliónů návštěv na půl miliónu
Všechno to začalo reklamní agenturou, která mě obvinila z 90% falešného provozu, už jsem to řekl, ale: umístili sledovací kód na mé stránky pro doručování reklam a objem botů byl problém i pro ně – zahltil jejich filtry a zvýšil zátěž serveru. Hovoříme o více než miliónu návštěv botů denně.
Nejprve jsem byl rozhořčen. V Google Analytics jsem viděl 100 000 čistých denních návštěv. Skuteční uživatelé, myslel jsem si. Ale jejich starost byla o provoz mimo Analytics. Ta neviditelná vrstva hitů pustošila zátěž serveru. Tehdy můj projekt běžel na Laravelu 5.3 hostovaném na sdíleném hostingu a věřil jsem, že úzkým hrdlem výkonu je stará kódová základna. Přepsal jsem všechno do Laravelu 10 s vynikající optimalizací, včetně denní analýzy miliónů záznamů v databázi.
A přesto to zaostávalo. Můj sdílený hosting to nezvládal. Načítání stránek se plazilo a skutečný provoz klesal – měsíc co měsíc jsem ztrácel asi 150 000 návštěv. Z 3 miliónů měsíčních návštěv jsem nakonec ztratil více než polovinu.
Upgradoval jsem na výkonné VPS s 16 jádry CPU a 32GB RAM, očekávajíc, že to všechno vyřeší. Ale i přes vylepšenou infrastrukturu a zrekódované backend Laravelu 10 problém přetrvával. Ve skutečnosti se věci zhoršily – boti se stali agresivnějšími, zvyšovali objem a frekvenci útoků. Bylo jasné, že žádná optimalizace kódu nebo škálování hardwaru nemohou vyřešit problém, který byl v zásadě o nekontrolovaném, škodlivém provozu botů.
Ale to nebylo všechno. Hlouběji jsem zjistil, že rozsah byl ještě větší: více než 2 milióny procházení webu denně, odděleně od asi 1,5 miliónu denních návštěv botů. A přesto, monetizovatelná, sledovatelná část webu (ta, na které agentury záleželo) přinášela pouze 100 000 zobrazení denně. Tam se problém vyhrotil. Pracoval jsem s reklamní agenturou, která závisela na čistém, lidském provozu. Museli najít způsoby, jak rychle filtrovat boty, jinak by jejich systémy analýzy a doručování reklam byly zahlceny. Obvinění, přetížení infrastruktury a nesrovnalosti v příjmech – všechno to bylo spojeno s tímto neviditelným, neúprosným přívalem botů.
Mým prvním krokem bylo vytvořit vlastní CAPTCHA, která měla botům ukázat prázdnou stránku, zatímco skuteční uživatelé prošli. Bohužel to mělo opačný efekt. Škodliví boti nezpomalili – zesílili. CAPTCHA se pro ně stala výzvou, kterou se agresivně snažili překonat, čímž zdvojnásobili zátěž.
Dalším krokem bylo hromadné blokování přes .htaccess. Fungovalo to – na pár dní. Pak se botnety přizpůsobily, objevily se nové IP adresy a .htaccess se stal nafouknutým a pomalým. Můj poskytovatel hostingu zasáhl a pomohl dočasně blokovat celé podsítě, ale problém se vracel každý týden.
Nakonec jsem se obrátil na Cloudflare. To byla nejvýznamnější změna. I když nebyla dokonalá, umožnila mi filtrovat přes 1,5 miliónu požadavků botů během 24 hodin. Nahrál jsem bloky sítě přímo do jejich firewallu. Výsledek? Z 1,5 miliónu zásahů botů bylo denně spuštěno pouze 20 výzev CAPTCHA — důkaz, že detekce na hraně Cloudflare fungovala lépe než cokoli jiného, co jsem zkusil.
Abych zůstal před boty napřed, postavil jsem si vlastní interní systém pro záznam. Zaznamenává každou jednotlivou žádost podle IP adresy a řetězce User-Agent, ukládá je do databáze. Na pozadí běží naplánovaný úkol každou minutu, aby agregoval data. Když detekuje podezřelou aktivitu – jako je velký objem žádostí přicházejících z jedné sítě nebo rozsahu IP – spustí automatizované e-mailové oznámení. Ten e-mail obsahuje seznam IP adres a podsítí připravených k přidání do Cloudflare pro blokování.
Stále jsem na bezplatném plánu Cloudflare, ale i to poskytuje dostatek kontroly k implementaci manuálních pravidel firewallu. Tento proaktivní přístup mi umožňuje detekovat a reagovat na přívaly botů dříve, než přetíží systém. Na úrovni Apache jsem původně zkoušel používat .htaccess k přímému blokování provozu, ale tato metoda měla snižující se návratnost. Jak se hromadily další pravidla, výkon webu se zhoršoval, což jasně ukázalo, že blokování na úrovni serveru nebylo udržitelné bez CDN nebo podpory na vrstvě hrany.
Jak vytvořit systém přihlášení + ochranu CloudFlare?
Proč neomezování rychlosti nebo blokování podle geografické polohy? Protože v mém případě nefungují. Většina těchto botů dělá jen jednu žádost na IP—ale používají k tomu stovky nebo dokonce tisíce IP adres v rámci stejné sítě. To znamená, že omezení rychlosti podle IP příliš nepomáhá; objem je rozložený, ne koncentrovaný. A co detekce podle User-Agent? Zbytečné. Někteří boti jsou dost chytří na to, aby se vydávali za Googlebot nebo jiné legitimní prohledávače, takže se nemůžete spoléhat pouze na hlavičky. Co takhle filtrování podle geografické polohy? Také neefektivní. Můj web je vícejazyčný a přijímá návštěvnost z mnoha zemí podle návrhu. Tyto záplavové sítě to vědí a rotují IP adresy z celého světa. Možná mě škrábou, protože můj web má hodnotný obsah—ale nemohu jej prostě zamknout za registrační zeď. To by zničilo uživatelský zážitek. Takže jsem potřeboval něco chytřejšího než obvyklá řešení.
Podívejte se na můj kód, dotazy MYSQL a doporučení níže. (Laravel 10 + MYSQL)
