Până în 2025, peisajul digital s-a schimbat: CAPTCHA nu mai este porțile de încredere de odinioară. În timp ce boții conduși de AI rezolvă puzzle-urile CAPTCHA cu o precizie aproape perfectă, utilizatorii reali sunt frustrați și adesea abandonează site-urile atunci când sunt provocați. Studii recente arată că boții trec acum prin CAPTCHA-uri bazate pe imagini și text cu o rată de 96–100% — depășind cu mult ratele de succes ale oamenilor reali și reducând conversiile formularelor cu până la 20%. Dar problema este mult mai profundă decât orice puzzle învechit.
Astăzi, traficul automatizat domină web-ul. Am realizat acest lucru personal. În 2024, s-a estimat că aproape jumătate din toată activitatea online era generată de boți, cu până la 37% clasificată ca fiind direct malițioasă. Chiar și site-urile cu măsuri active de atenuare raportează în continuare 10–20% activitate de boți. Realitatea este dură: soluțiile tradiționale precum CAPTCHA și listele negre de IP-uri au devenit aproape neputincioase în fața rețelelor de boți coordonate, în rapidă evoluție, care pot imita utilizatorii reali, pot roti IP-uri noi și chiar pot exploata dispozitivele mobile pentru atacuri la scară largă.
Pentru proprietarii de site-uri web și afacerile online, impactul este devastator. Inundațiile de boți pot paraliza resursele serverului, pot încetini încărcarea paginilor și pot distruge experiența utilizatorului. Dar efectele se propagă mai departe — clasamentele Google scad pe măsură ce performanța paginii se deteriorează, veniturile din reclame se evaporă pe măsură ce calitatea traficului scade, iar relațiile cu partenerii de publicitate se deteriorează atunci când vizitele false le inundă analiticile.
Am trăit această criză pe propria piele. Totul a început cu o acuzație din partea unei agenții de publicitate: au susținut că 90% din traficul site-ului meu era fals. Codul lor de urmărire, încorporat pentru livrarea reclamelor, a dezvăluit volume de boți care copleșeau nu doar filtrele lor, ci și serverul meu. Vorbim despre peste un milion de vizite de boți pe zi — trafic invizibil pentru Google Analytics, dar catastrofal în culise. Ceea ce credeam inițial că sunt utilizatori reali erau, în realitate, parte dintr-un val neîncetat de accesări automatizate, inundând infrastructura mea și amenințând viabilitatea întregului meu proiect.
Aceasta nu este doar o poveste despre actori rău-intenționați care exploatează vulnerabilități — este despre cum însăși arhitectura web-ului modern este asediată. Optimizările de cod și actualizările de server nu au fost suficiente. Provocarea a devenit o cursă a înarmărilor, cu site-ul meu prins la mijloc. Iată cum s-a desfășurat inundația de boți, aproape distrugând tot ce construisem — și pașii pe care i-am luat pentru a riposta.
Povestea mea cu traficul de boți: de la 3 milioane de vizite la o jumătate de milion
Totul a început cu o agenție de publicitate care m-a acuzat că am 90% trafic fals, am spus deja asta, dar: ei plasaseră un cod de urmărire pe site-ul meu pentru a livra reclame, iar volumul de boți era o problemă și pentru ei — le-a copleșit filtrele și a umflat încărcarea serverului. Vorbim despre peste un milion de vizite de boți pe zi.
La început, am fost indignat. În Google Analytics, vedeam 100.000 de vizite zilnice pure. Utilizatori reali, credeam. Dar preocuparea lor era despre traficul din afara Analytics. Acel strat invizibil de accesări provoca haos în încărcarea serverului. Pe atunci, proiectul meu rula pe Laravel 5.3 găzduit pe hosting partajat, și credeam că problema de performanță era codul vechi. Am rescris totul în Laravel 10 cu o optimizare superioară, inclusiv analiza zilnică a milioane de înregistrări din baza de date.
Totuși, era lent. Hostingul meu partajat nu putea face față. Încărcarea paginilor se târa, iar traficul real scădea — lună de lună, pierdeam aproximativ 150.000 de vizite. De la 3 milioane de vizite lunare, am pierdut în cele din urmă mai mult de jumătate.
Am făcut upgrade la un VPS puternic cu 16 nuclee CPU și 32GB de RAM, așteptându-mă ca aceasta să rezolve totul. Dar chiar și cu infrastructura îmbunătățită și backend-ul recodat în Laravel 10, problema persista. De fapt, lucrurile s-au înrăutățit — boții au devenit mai agresivi, crescând volumul și frecvența atacurilor. A devenit clar că nicio cantitate de optimizare a codului sau scalare hardware nu putea rezolva o problemă care era fundamental despre traficul de boți malițios necontrolat.
Dar asta nu era tot. Săpând mai adânc, am realizat că dimensiunea era și mai mare: peste 2 milioane de crawl-uri zilnice, separate de aproximativ 1,5 milioane de vizite zilnice de boți. Și totuși, partea monetizabilă și urmăribilă a site-ului (cea de care agențiile se preocupau) aducea doar 100.000 de impresii pe zi. Acolo s-a escaladat problema. Lucram cu o agenție de publicitate care se baza pe trafic curat, uman. Ei trebuiau să găsească modalități de a filtra boții rapid, altfel sistemele lor de analiză și servire a reclamelor ar fi fost copleșite. Acuzațiile, supraîncărcarea infrastructurii și discrepanțele de venituri — toate erau legate de această inundație invizibilă și neîncetată de boți.
Prima mea mișcare a fost să creez un CAPTCHA personalizat, cu scopul de a arăta boților o pagină goală, în timp ce utilizatorii reali treceau. Din păcate, asta a dat înapoi. Boții malițioși nu au încetinit — au accelerat. CAPTCHA a devenit o provocare pe care au încercat agresiv să o depășească, dublând încărcarea.
Apoi a urmat blocarea în masă prin .htaccess. A funcționat — câteva zile. Apoi rețelele de boți s-au ajustat, au apărut IP-uri noi, iar .htaccess a devenit umflat și lent. Furnizorul meu de hosting a intervenit, ajutând la blocarea temporară a unor subrețele întregi, dar problema revenea săptămânal.
În cele din urmă, m-am orientat către Cloudflare. Aceasta a fost schimbarea cu cel mai mare impact. Deși nu era perfectă, mi-a permis să filtrez peste 1,5 milioane de cereri de boți în 24 de ore. Am încărcat blocuri de rețele direct în firewall-ul lor. Rezultatul? Din 1,5 milioane de accesări de boți, doar 20 de provocări CAPTCHA erau declanșate zilnic — dovada că detectarea la nivel de margine a Cloudflare funcționa mai bine decât orice altceva încercasem.
Pentru a rămâne cu un pas înaintea boților, am construit propriul meu sistem intern de logare. Acesta înregistrează fiecare cerere individuală după adresa IP și User-Agent, stocându-le într-o bază de date. În culise, o sarcină programată rulează în fiecare minut pentru a agrega datele. Când detectează activitate suspectă — cum ar fi un volum mare de cereri provenind de la o singură rețea sau interval de IP-uri — declanșează o notificare automată prin email. Acel email include o listă de IP-uri și subrețele gata de a fi adăugate în Cloudflare pentru blocare.
Încă sunt pe planul gratuit al Cloudflare, dar chiar și acesta oferă suficient control pentru a implementa reguli manuale de firewall. Această abordare proactivă îmi permite să detectez și să răspund la inundațiile de boți înainte ca acestea să copleșească sistemul. La nivel Apache, inițial am încercat să folosesc .htaccess pentru a bloca traficul direct, dar această metodă avea randamente descrescătoare. Pe măsură ce regulile se acumulau, performanța site-ului se degrada, făcând evident că blocarea la nivel de server nu era sustenabilă fără suport CDN sau la nivel de margine.
Cum să faci un sistem de autentificare + protecție CloudFlare?
De ce nu limitarea ratei sau geo-blocarea? Pentru că nu funcționează în cazul meu. Majoritatea acestor boți fac doar o singură cerere per IP — dar o fac folosind sute sau chiar mii de IP-uri în aceeași rețea. Asta înseamnă că limitarea ratei per IP nu ajută prea mult; volumul este distribuit, nu concentrat. Cât despre detectarea lor prin User-Agent? Inutilă. Unii boți sunt suficient de inteligenți pentru a imita Googlebot sau alți crawleri legitimi, așa că nu poți avea încredere doar în headere. Ce zici de filtrarea geo-localizată? Nici aceasta nu este eficientă. Site-ul meu este multilingv și primește trafic din multe țări prin design. Aceste rețele de inundare știu asta și rotesc IP-uri din toată lumea. Poate mă scanează pentru că site-ul meu are conținut valoros — dar nu pot pur și simplu să-l ascund în spatele unui zid de înregistrare. Asta ar distruge experiența utilizatorului. Așa că aveam nevoie de ceva mai inteligent decât soluțiile obișnuite.
Privește codul meu, interogările MYSQL și recomandările de mai jos. (Laravel 10 + MYSQL)
