Get credits to unlock premium content and features
$10
100 credits
Most Popular
$25
280 credits
Save 12%
$50
600 credits
Save 20%
$100
1,300 credits
Save 30%
You'll receive:280 credits
Cost per credit:~$0.089
Rośnijmy razem
Co tydzień otrzymasz przyjazną dawkę wskazówek AI, strategii SaaS, trików kodowania i prawdziwych historii założycieli — zero lania wody, sama esencja.
May 29 2025
• 8 min read
• 1576 words
Jak Ruch Botów Niemal Zniszczył Moją Stronę: Kryzys Zalania
Do 2025 roku krajobraz cyfrowy uległ zmianie: CAPTCHA nie jest już niezawodnym strażnikiem, jakim kiedyś była. Podczas gdy boty napędzane AI rozwiązują zagadki CAPTCHA z niemal doskonałą dokładnością, prawdziwi użytkownicy są sfrustrowani i często opuszczają witryny, gdy są wyzwani. Ostatnie badania pokazują, że boty teraz z łatwością pokonują CAPTCHA oparte na obrazach i tekstach w 96–100% przypadków—znacznie przewyższając rzeczywiste wskaźniki sukcesu ludzi i zmniejszając konwersje formularzy nawet o 20%. Ale problem sięga znacznie głębiej niż jakakolwiek przestarzała łamigłówka.
Dziś automatyczny ruch dominuje w sieci. Zdaję sobie z tego sprawę osobiście. W 2024 roku szacowano, że niemal połowa całej aktywności online była generowana przez boty, z czego aż 37% było klasyfikowane jako jawnie złośliwe. Nawet witryny z aktywnym ograniczaniem nadal zgłaszają 10–20% trwającej aktywności botów. Rzeczywistość jest brutalna: tradycyjne rozwiązania jak CAPTCHA i czarne listy IP stały się niemal bezsilne w obliczu skoordynowanych, szybko ewoluujących botnetów, które mogą naśladować prawdziwych użytkowników, cyklować przez nowe IP i nawet wykorzystywać urządzenia mobilne do ataków na dużą skalę.
Dla właścicieli stron internetowych i przedsiębiorstw online, wpływ jest druzgocący. Zalewy botów mogą sparaliżować zasoby serwera, spowolnić ładowanie stron do pełzania i zepsuć doświadczenie użytkownika. Ale efekty sięgają dalej—ranking Google spada, gdy wydajność strony się pogarsza, przychody z reklam znikają, gdy jakość ruchu spada, a relacje z partnerami reklamowymi pogarszają się, gdy fałszywe wizyty zalewają ich analitykę.
Doświadczyłem tego kryzysu na własnej skórze. Wszystko zaczęło się od oskarżenia ze strony agencji reklamowej: twierdzili, że 90% ruchu na mojej stronie było fałszywe. Ich kod śledzący, osadzony w celu dostarczania reklam, ujawnił wolumeny botów, które przytłaczały nie tylko ich filtry, ale i mój serwer. Mówimy o ponad milionie wizyt botów dziennie—ruchu niewidocznego dla Google Analytics, ale katastrofalnego za kulisami. To, co początkowo uważałem za prawdziwych użytkowników, było w rzeczywistości częścią nieustannej fali zautomatyzowanych uderzeń, zalewających moją infrastrukturę i zagrażających rentowności całego mojego projektu.
To nie jest tylko historia o złych aktorach wykorzystujących słabości—to opowieść o tym, jak sama architektura współczesnego internetu jest oblężona. Optymalizacje kodu i modernizacje serwera nie wystarczyły. Wyzwanie stało się wyścigiem zbrojeń, z moją stroną złapaną w krzyżowy ogień. Oto, jak rozwinął się zalew botów, niemal niszcząc wszystko, co zbudowałem—i kroki, które podjąłem, aby się bronić.
Moja historia z ruchem botów: 3 miliony wizyt na stronie do pół miliona
Wszystko zaczęło się od agencji reklamowej, która oskarżyła mnie o posiadanie 90% fałszywego ruchu. Już to powiedziałem, ale: umieścili kod śledzący na mojej stronie, aby dostarczać reklamy, a objętość ruchu botów była dla nich problemem również—przytłaczała ich filtry i zwiększała obciążenie serwera. Mówimy o ponad milionie wizyt botów dziennie.
Na początku byłem oburzony. W Google Analytics widziałem 100 000 czystych wizyt dziennie. Prawdziwi użytkownicy, tak myślałem. Ale ich obawy dotyczyły ruchu poza Analytics. Ta niewidoczna warstwa hitów siała spustoszenie na obciążeniu serwera. W tamtym czasie mój projekt działał na Laravelu 5.3 hostowanym na współdzielonym hostingu i wierzyłem, że wąskie gardło wydajności to stara baza kodu. Przepisałem wszystko na Laravel 10 z doskonałą optymalizacją, w tym codzienną analizą milionów rekordów bazy danych.
Nadal się zacinało. Mój współdzielony hosting nie mógł sobie z tym poradzić. Ładowanie stron było powolne, a prawdziwy ruch spadał—miesiąc po miesiącu traciłem około 150 000 wizyt. Z 3 milionów wizyt miesięcznie ostatecznie straciłem ponad połowę.
Zaktualizowałem do potężnego VPS z 16 rdzeniami CPU i 32 GB RAM, spodziewając się, że to rozwiąże wszystko. Ale nawet przy ulepszonej infrastrukturze i przepisanym backendzie Laravel 10 problem pozostał. W rzeczywistości sytuacja się pogorszyła—boty stały się bardziej agresywne, zwiększając objętość i częstotliwość ataków. Stało się jasne, że żadna ilość optymalizacji kodu ani skalowanie sprzętu nie mogły rozwiązać problemu, który był zasadniczo związany z niekontrolowanym, złośliwym ruchem botów.
Ale to nie wszystko. Zgłębiając temat, zdałem sobie sprawę, że skala była jeszcze większa: ponad 2 miliony skanów strony dziennie, oddzielnie od około 1,5 miliona dziennych wizyt botów. A jednak zmonetyzowana, śledzona część strony (ta, która interesowała agencje) przynosiła tylko 100 000 wyświetleń dziennie. To tam problem się zaostrzył. Pracowałem z agencją reklamową, która polegała na czystym, ludzkim ruchu. Musieli szybko znaleźć sposoby na filtrowanie botów, w przeciwnym razie ich systemy analityczne i serwujące reklamy zostałyby przytłoczone. Oskarżenia, przeciążenie infrastruktury i rozbieżności w przychodach—wszystko to było związane z tym niewidzialnym, nieustępliwym zalewem botów.
Moim pierwszym krokiem było stworzenie niestandardowego CAPTCHA, mającego na celu pokazanie botom pustej strony, podczas gdy prawdziwi użytkownicy przechodzili dalej. Niestety, to się obróciło przeciwko mnie. Złośliwe boty nie zwolniły—przyspieszyły. CAPTCHA stało się wyzwaniem, które agresywnie próbowały pokonać, podwajając obciążenie.
Następnie przyszedł masowy blok za pomocą .htaccess. Działało—przez kilka dni. Potem sieci botów się dostosowały, pojawiły się nowe adresy IP i .htaccess stało się przeładowane i powolne. Mój dostawca hostingu wkroczył do akcji, pomagając tymczasowo blokować całe podsieci, ale problem powracał co tydzień.
W końcu zwróciłem się do Cloudflare. To była najbardziej znacząca zmiana. Chociaż nie była doskonała, pozwoliła mi przefiltrować ponad 1,5 miliona żądań botów w ciągu 24 godzin. Przesłałem bloki sieciowe bezpośrednio do ich zapory. Rezultat? Z 1,5 miliona uderzeń botów, tylko 20 wyzwań CAPTCHA było uruchamianych dziennie—dowód na to, że wykrywanie na poziomie brzegowym Cloudflare działało lepiej niż cokolwiek innego, co próbowałem.
Aby wyprzedzać boty, zbudowałem własny wewnętrzny system rejestrowania. Rejestruje każde pojedyncze żądanie według adresu IP i ciągu User-Agent, zapisując je w bazie danych. W tle co minutę działa zaplanowane zadanie agregujące dane. Kiedy wykrywa podejrzaną aktywność—taką jak duża ilość żądań pochodzących z jednej sieci lub zakresu IP—uruchamia automatyczne powiadomienie e-mail. Ten e-mail zawiera listę IP i podsieci gotowych do dodania do Cloudflare w celu zablokowania.
Wciąż korzystam z darmowego planu Cloudflare, ale nawet to zapewnia wystarczającą kontrolę, aby wdrożyć ręczne reguły zapory. To proaktywne podejście pozwala mi wykrywać i reagować na powodzie botów, zanim przytłoczą system. Na poziomie Apache pierwotnie próbowałem używać .htaccess do blokowania ruchu bezpośrednio, ale ta metoda miała malejące zwroty. W miarę jak przybywało reguł, wydajność strony się pogarszała, co wyraźnie pokazywało, że blokowanie na poziomie serwera nie było trwałe bez CDN lub wsparcia na poziomie brzegowym.
Jak stworzyć system logowania + ochrona CloudFlare?
Dlaczego nie ograniczanie szybkości lub blokowanie geolokalizacji? Ponieważ w moim przypadku nie działają. Większość z tych botów wykonuje tylko jedno żądanie na IP — ale robią to używając setek, a nawet tysięcy IP w ramach tej samej sieci. Oznacza to, że ograniczanie szybkości według IP niewiele pomaga; wolumen jest rozproszony, a nie skoncentrowany. A co z ich wykrywaniem poprzez User-Agent? Bezużyteczne. Niektóre boty są na tyle sprytne, że naśladują Googlebota lub inne legalne crawlery, więc nie można ufać samym nagłówkom. A co z filtrowaniem geolokalizacji? Również nieskuteczne. Moja strona jest wielojęzyczna i z założenia otrzymuje ruch z wielu krajów. Te sieci floodujące o tym wiedzą i rotują IP z całego świata. Może skrobią mnie, ponieważ moja strona zawiera wartościowe treści — ale nie mogę ich po prostu zamknąć za ścianą rejestracyjną. To zrujnowałoby doświadczenie użytkownika. Potrzebowałem więc czegoś mądrzejszego niż zwykłe rozwiązania.
Zobacz mój kod, zapytania MYSQL i rekomendacje poniżej. (Laravel 10 + MYSQL)