Wczoraj Cloudflare wdrożył wykrywanie botów na poziomie sesji
13 lipca 2026 roku Cloudflare uruchomił Precursor, ciągły silnik behawioralnego wykrywania botów, który obserwuje całą sesję, a nie tylko moment wejścia odwiedzającego. Ich obecne wyzwanie Turnstile jest uruchamiane około 3 miliardy razy dziennie podczas logowania, rejestracji i finalizacji transakcji. Precursor rozszerza tę samą widoczność po stronie klienta na każdą stronę pomiędzy.
Kontekst ma znaczenie. Turnstile zadawał jedno pytanie w jednym momencie: czy ten odwiedzający to człowiek? Precursor zadaje to samo pytanie w sposób ciągły, przy każdym ruchu myszą, naciśnięciu klawisza, przewijaniu i zmianie fokusu, i przekazuje odpowiedź do bieżącego wyniku bota, który podąża za sesją.
To większa zmiana, niż mogłoby się wydawać po informacji prasowej.
Sesja to nowy odcisk palca
Przez lata wykrywanie botów działało w krótkich zrywach. Rozwiąż wyzwanie, pobierz cookie, uruchom swoje requesty. Nawet nowsze sprawdzenia warstwy sieciowej i testy typu header były zdarzeniami typu per-request. Jeśli przeszedłeś pierwszą próbę, miałeś przeważnie spokój aż do następnej.
Behawioralne wykrywanie na poziomie sesji łamie ten schemat. Z wpisu startowego Cloudflare: boty potrafią wykonywać JavaScript, korzystać z pełnych środowisk przeglądarkowych i omijać pojedyncze testy CAPTCHA bez wzbudzania podejrzeń. To co pozostaje trudne do zreplikowania, to spójne ludzkie zachowanie w czasie.
Wskazują na fizykę ludzkiego wejścia jako ścianę, na którą natrafia automatyzacja. Ludzki ruch myszą to łuk, ograniczony przez oś nadgarstka i rotację przedramienia. Istnieje mierzalne opóźnienie między zobaczeniem pola wyboru a kliknięciem go (obciążenie poznawcze). A nawet pewna dłoń oscyluje z częstotliwością fizjologicznego drżenia. Boty rysują proste linie i matematycznie idealne krzywe Beziera. Klikają z precyzją, jakiej żaden człowiek nigdy nie osiąga.
Każdy z tych sygnałów z osobna jest słabo czytelny. Zsumuj je w pięciominutowej sesji, a rozbieżność staje się wyraźna.
Dlaczego odświeżanie już cię nie ratuje
Sztuczka unikania przy wykrywaniu typu per-request była jasna: jeśli twój wynik bota rośnie, odśwież stronę, obróć tożsamość, zacznij od nowa. Precursor zamyka te drzwi.
Cloudflare mówi wprost: "Zakres sesji jest ważny, ponieważ oznacza to, że bot nie może zresetować swojej sygnatury behawioralnej odświeżając stronę lub zaczynając od nowa z nowym wyzwaniem." Podejrzane sesje gromadzą kontekst. Wynik bota podąża za odwiedzającym.
Ale ta zmiana najmocniej uderza w konkretną, średnią warstwę scraperów. W pełni headless model oparty na rotacji per-request przegrywał już ze standardowymi testami. Nic w tym nowego. Prawdziwie świadomi sesji operatorzy, utrzymujący jedną tożsamość przeglądarki przez czas wizyty rzeczywistego użytkownika, są w dużej mierze bezpieczni. Precursor karze to, co znajduje się pośrodku: zespoły uruchamiające Puppeteer lub Playwright z rozsądnymi wartościami domyślnymi, traktujące każdy URL jako niezależne zadanie, odświeżające pomiędzy uruchomieniami, aby wyglądać czysto.
Ten styl scrapowania jest tani, ponieważ jest jednorazowy. Precursor sprawia, że to, co jednorazowe, staje się drogie.
Co to oznacza dla agentowych scraperów
Istnieje druga grupa, do wyłapywania której Precursor został wyraźnie stworzony: oparte na agentach AI scrapery. Cloudflare zwraca na to uwagę w podtytule: wykrywanie zachowań agentowych za pomocą ciągłych sygnałów po stronie klienta.
Autonomiczne agenty przeglądające (te napędzane przez LLM, które planują zadanie i wykonują je krok po kroku) mają tendencję do poruszania się w krótkich, zdecydowanych seriach. Nawigacja, ekstrakcja, nawigacja, ekstrakcja. Indywidualnie każda akcja wygląda jak coś, co mógłby zrobić prawdziwy odwiedzający. Brak w tym jednak zatrzymania, wzorca przewijania w celu czytania, małych korekt czy omijania celu. W skali sesji te braki są równie głośne jak fałszywe drżenie myszy.
Jeśli więc budujesz agenta, który scrape'uje w trakcie myślenia, podatek od fizyki właśnie stał się realny. Blog Cloudflare zauważa, że Precursor "podnosi koszt działania automatyzacji, wymagając od niej symulacji pełnej sesji. Jest to znacznie trudniejsze do zbudowania, droższe w utrzymaniu i znacznie mniej niezawodne w działaniu na dużą skalę."
Taki był całkowity cel projektowy. Nie uczynić automatyzacji niemożliwą, ale nieopłacalną.
Co to oznacza dla zespołów danych
Zmieniają się trzy rzeczy i żadna z nich nie jest tania.
Po pierwsze, budżety sesji zastępują budżety zapytań (request). Jeśli planujesz przepustowość dla celu chronionego przez Cloudflare, przestań myśleć w kategoriach requestów na sekundę i zacznij myśleć w kategoriach sesji na godzinę: ile niezależnych, ciągle wyglądających podróży użytkowników jesteś w stanie utrzymać i jak długa jest każda z nich? Krótkie serie to dokładna sygnatura, na którą Precursor jest dostrojony. To przemyślenie matematyki proxy, o którym pisaliśmy w maju ma tutaj również zastosowanie. Rozmiar puli nie jest sufitem, jest nim realizm sesji.
Po drugie, kalkulacja budować czy kupić (build-vs-buy) przechyla się jeszcze bardziej w stronę kupna. Utrzymanie scrapera przeciwko obrońcy działającemu na poziomie requestów to jednorazowa integracja i okazjonalna łatka. Utrzymanie go przeciwko obrońcy działającemu na poziomie sesji oznacza ciągłe behawioralne R&D: modele tempa, ścieżki kursora, rozkłady czasu przebywania i sposób na utrzymanie pokrycia testami tego wszystkiego. Jeśli wahałeś się nad outsourcingiem zbierania danych z sieci, to sprawia, że liczby są gorsze dla własnych rozwiązań.
Po trzecie, ten, kto jako pierwszy wdroży Precursor na dużą skalę, wyznaczy nową bazę wykrywania dla branży. Cloudflare chroni około 20% sieci. Jeśli klienci z branży e-commerce i finansów agresywnie włączą Precursor w następnym kwartale, odczuje to stos scrapingowy wszystkich innych, w tym na stronach, które nigdy same nie instalują Precursor, ponieważ ekosystem obrońców obserwuje, co działa, i szybko kopiuje.
Przesunięcie skali czasu, którego nikt nie nazywa
Pisaliśmy o przejściu na wykrywanie behawioralne trzy miesiące temu. Precursor to ustrukturyzowana wersja tego trendu i na nowo zakotwicza ona okno pomiarowe.
Wykrywanie botów odbywało się kiedyś w obrębie jednego requestu. Obecnie ma to miejsce w ramach sesji, która trwa kilka minut, a czasem dłużej. Ta jedna zmiana wpływa na każdą taktykę scrapowania napisaną w czasach, gdy jednostką detekcji było pojedyncze wywołanie. Rotacja proxy, fuzzing nagłówków, regulacja tempa requestów w skali sekund, wszystko to traci na znaczeniu, jeśli funkcją straty jest spójność behawioralna w ciągu pięciu minut interakcji.
Pytanie nie brzmi, czy wykrywanie botów będzie nadal ewoluować. To jest pewne. Chodzi o to, czy twój stack do zbierania danych nadal operuje w kategoriach requestów, podczas gdy obrońca myśli w kategoriach sesji.