Dlaczego Automation utrzymuje uruchamianie CAPTCHA: 7- Przewodnik diagnostyczny sygnału

Kiedy twój skrypt automatyzacji nagle zaczyna uruchamiać wyzwania CAPTCHA, pokusa jest, aby sięgnąć do jakiejkolwiek biblioteki ukrytej nie próbowałeś ostatni raz i nadziei. To podejście jest, dlaczego ludzie kończy się jazda przez pięć różnych wtyczek stealth w ciągu sześciu miesięcy i nadal nie wiedząc, co faktycznie się zmieniło.

Lepszym podejściem jest diagnostyka: dowiedzieć się, który z siedmiu sygnałów jest obecnie flagowanie sesji, naprawić ten sygnał, i statek. Ten przewodnik przechodzi przez siedem sygnałów w systemach wykrywania zamówień waży je - najbardziej likely-culprit pierwszy - i pokazuje, jak przetestować każdy z nich w izolacji. Celem jest, aby dać listę kontrolną można uruchomić w 15 minut, gdy produkcja wskaźnik CAPTCHA wzrost.

Dlaczego systemy detekcji Wyzwań CAPTCHA

Wyzwaniem CAPTCHA jest wyjście, a nie przyczyna. Powodem jest to, że system wykrywania (Cloudflare Bot Management, DataDome, Akamai, hCaptcha 's risk engine, reCAPTCHA Enterprise, lub stos swoisty vendor- specific) przeczytał wektor sygnału sesji i zdecydował, że wynik ryzyka przekroczył próg. CAPTCHA są wydawane probabilistycznie w oparciu o pewność siebie, a nie w sposób określony na podstawie jednej reguły.

Dwie implikacje:

1. Ten sam kod może przejść w poniedziałek i zawieść w piątek ponieważ model ewoluował lub inna flota za pomocą sygnatury ukrytego został oznaczony.
2. Ustawienie jednego sygnału nie wystarczy, jeśli dwa są wyłączone. Systemy detekcji ważą sygnały w połączeniu. Czysty odcisk palca z oznakowanym IP nadal uruchamia; czysty IP z oznaczeniem odcisku palca nadal uruchamia.

Podejście diagnostyczne jest sekwencyjne: zidentyfikować, które sygnały są obecnie ważone najwyższy przeciwko Ciebie, naprawić te pierwsze, a następnie ponownie walidacji. Poniższe sygnały są uporządkowane przez typowy wkład w wynik ryzyka, w oparciu o wzorce wagi obserwowalne w publicznych badaniach anty-bot i tryby awarii najczęściej zgłaszane w problemach produkcyjnych.

7 Sygnały do sprawdzenia, w porządku

Sygnał 1: Lokalizacja × strefa czasowa × niedopasowanie geografii IP

Jest to sygnał # 1, ponieważ jest to najczęstsza awaria cicha i najprostsza do zweryfikowania.

• Przeglądarka Accept-Language nagłówka i navigator.languages
• Strefa czasowa przeglądarki (Intl.DateTimeFormat().resolvedOptions().timeZone)
• Geografie IP połączenia (dane wejściowe, mieszkaniowe, krajowe, regionalne)

Prawdziwy użytkownik w Berlinie prezentuje de-DE lub en-DE, Europe/Berlin, i niemiecki IP. Amerykański angielski Chrome przekierowany przez Frankfurt proxy przedstawia en-US, America/New_Yorkoraz niemiecki IP - niepowodzenie w zakresie spójności, którego szczególnie szukają systemy wykrywania.

Jak sprawdzić:

Otwórz automatyczną przeglądarkę i odwiedź stronę weryfikacji, jak browserleaks.com/ip oraz browserleaks.com/javascriptPorównuj trzy wartości: położenie IP, strefę czasową i języki. Powinny one opisać jedną spójną geografię.

Jak naprawić:

Jeśli konfigurujesz proxy i odciski palców oddzielnie, musisz ręcznie wyrównać wszystkie trzy za każdym razem. Strukturalna fix jest związane profilowe proxy routing - czas trwania, w którym proxy jest połączone z odciskiem w czasie tworzenia rezerw, więc geografia pozostaje spójna automatycznie. Zobacz nasz przewodnik runtime przeglądarki dlaczego ta warstwa ma znaczenie.

Sygnał 2: Canvas, WebGL i ponowne użycie odcisków palców

Jest to sygnał # 2, ponieważ jest to awaria, która niszczy flotę wielokontową, nawet gdy poszczególne sesje wyglądają na czyste. Dwie sesje na tej samej maszynie produkują identyczne odczyty płótna, identyczne struny WebGL renderer i identyczne wyjście kontekstowe audio. Do systemu wykrywania, "1000 sesje z identycznymi haszami płótna i rotacyjnymi agentami użytkownika" jest jedną tożsamość, która próbuje wyglądać jak wiele.

Jak sprawdzić:

Biegnij creepjs (lub każdy open- źródłowy inspektor odcisków palców) w dwóch oddzielnych sesjach i porównać płótno, WebGL i hash audio. Jeśli jakiekolwiek dwie sesje produkują identyczne hash, Twoja flota ma problem z odciskami palców-ponowne użycie.

Jak naprawić:

Każda sesja potrzebuje odrębnego, wewnętrznie spójnego profilu odcisków palców generowanego na poziomie silnika. Łaty na poziomie page- (stealth plugins) może dodać hałas do odczytów płótna, ale zazwyczaj nie może wygenerować w pełni odrębne, spójne profile w skali. Pełna inwentaryzacja, które powierzchnie materia jest w naszym przewodnik pobierania odcisków palców w przeglądarce.

Sygnał 3: TLS / JA3 / JA4

Jest to sygnał # 3, ponieważ działa poniżej Twojego kodu aplikacji. TLS Client Hello wysłany na początku każdego połączenia HTTPS ma kształt dający się wydrukować - porządek szyfrowania, lista rozszerzeń, obsługiwane krzywe - który produkuje hasz JA3 lub JA4. Różne wersje Chromium produkują różne hashy; biblioteki automatyzacji, które budują TLS rękopisy siebie (zamiast przez Chromium) produkują hashy, które nie pasują do żadnej prawdziwej przeglądarki.

Jak sprawdzić:

Wizyta tls.peet.ws ze swojej zautomatyzowanej przeglądarki. Strona zwraca hash JA3 i JA4 dla połączenia. Porównaj do JA3 / JA4 waniliowego Chrome na tym samym systemie operacyjnym - powinny pasować. Jeśli Twoja biblioteka automatyki generuje własny hasz, to jest to porażka.

Jak naprawić:

Korzystanie z przeglądarki runtime, który wykorzystuje podstawowy stosu Chromium TLS zamiast oddzielnego klienta HTTP. Jest to najbardziej istotne, jeśli używasz HTTP / biblioteki scrating, które omijają przeglądarkę; pełna automatyzacja przeglądarkowa za pośrednictwem CDP zazwyczaj dziedziczy natywny odcisk palca TLS Chromium prawidłowo.

Sygnał 4: navigator.webdriver i inne flagi automatyki

Jest to sygnał # 4, ponieważ jest to najbardziej podstawowy i najczęściej zaadresowany - ale także ten, w którym same łatki stały się wykrywalne. Domyślne kompilacje Chromium dla Playwright / Puppeteer ustawiają navigator.webdriver = true. Stealth plugins obejmie go false. Wyrafinowane systemy detekcji zaczęły odczytywać sposób nadrabiania (zdefiniowany niekonfigurowalnie, obecny na łańcuchu prototypu, itp.) jako sygnał.

Jak sprawdzić:

W zautomatyzowanej konsoli przeglądarki uruchom:

console.log(navigator.webdriver);
console.log(Object.getOwnPropertyDescriptor(navigator, 'webdriver'));

Pierwsza powinna być false (lub undefined na prawdziwej przeglądarce); druga powinna pasować do prawdziwego wzoru deskryptora przeglądarki.

Jak naprawić:

Plastry poziomu inżyniera (modyfikacje wewnątrz binarnego Chromium) produkują deskryptory właściwości, które nie są odróżnialne od prawdziwych przeglądarek. Plastry poziomu page- za pomocą zastrzyku JavaScript mają charakterystyczne wzory. Jest to jeden z kilku powodów, dla których dwuplaterowy runtime wyrównuje stealth oparty na pluginu.

Sygnał 5: Wzory behawioralne po załadowaniu strony

Jest to sygnał # 5, ponieważ włącza się dopiero po przejściu etapu pobierania odcisków palców. Po załadowaniu strony, rozpoczyna się kontrola behawioralna: entropia ruchu myszy, wzory przewijania, czas pomiędzy akcjami, kadencja klawisza na wejściu formularza. Automatyzacja, która klika na dokładne współrzędne z zerową ścieżką myszy, typy na dokładnie 50ms na znak, i przedstawia formularze 200ms po ich pojawieniu się jest wykrywalny od samego zachowania.

Jak sprawdzić:

Porównaj ślad akcji z automatyzacji do jednej z ręcznej interakcji. Różnica jest zwykle oczywista: prawdziwy ruch ma krzywe, przyspieszanie, krótkie pauzy, sporadyczne pomyłki. Automatyzacja ma proste linie i jednolity czas.

Jak naprawić:

Dodaj wariancję behawioralną: ścieżki myszki bez krzywizny bezierskiej, rozstrojony czas, prędkość przewijania, która rampuje i spowalnia, sporadyczne pauzy na elementach strony przed kliknięciem. Biblioteki playwright-extra i równoważne narzędzia mają pomocników w tym. Realistyczny sufit jest "wygląda na uważny, ale lekko przyspieszony człowiek" - nie "nie można odróżnić od każdego przypadkowego użytkownika".

Sygnał 6: Wyciek IP WebRTC i wycieki DNS

Jest to sygnał # 6, ponieważ jest to cichy zabójca proxy automatyzacji specjalnie. Protokół STUN WebRTC może ujawnić lokalny adres IP nawet, gdy przeglądarka jest za proxy - bez wyraźnej obsługi, Twoja sesja "Frankfurt Residence" przecieka jego prawdziwy San Francisco datacenter IP przez kandydatów ICE. DNS rozdzielczość może zrobić to samo, jeśli DNS przeglądarki przechodzi przez lokalne rozwiązanie podczas HTTP przechodzi przez proxy.

Jak sprawdzić:

Wizyta browserleaks.com/webrtc. Strona informuje lokalne i publiczne IP WebRTC ujawnia. Oba powinny pasować do proxy. Jeśli lokalny IP pokazuje prawdziwą sieć maszyny, masz wyciek WebRTC. Sprawdź browserleaks.com/dns dla odpowiednika DNS.

Jak naprawić:

Standardowym ograniczeniem jest zmuszanie WebRTC do przełączania tylko w tryb - ale to samo jest obserwowalne jako privacy-świadomy lub zautomatyzowany konfiguracja. Czystszy fix jest runtime, który obsługuje WebRTC i DNS routing przez ten sam proxy ruchu HTTP, domyślnie, bez konfiguracji operatora wymagane.

Sygnał 7: Tryb bez głowy mówi

Jest to sygnał # 7, ponieważ jest to istotne tylko w bezgłowych wdrożeniach - ale jest to jeden największy "działa w dev, nie udaje się w produkcji" nieudana. Bezgłowy Chrome ma dodatkowe różnice w odciskach palców od głowy: brakujące wtyczki (zero pluginów jest podejrzane), różne wyjście audio, różne domyślne widoki, pewne ścieżki renderowania, które wytwarzają subtelnie różne wyjście, i (do niedawna) dosłowne HeadlessChrome token w agenta użytkownika.

Jak sprawdzić:

Przeprowadź tę samą inspekcję odcisków palców w trybie głowiastym na miejscu i w środowisku produkcyjnym bez głowy. Porównaj każdą powierzchnię. Różnice, jakie znajdziesz, są tym, co widzą systemy wykrywania produkcji.

Jak naprawić:

Użyj runtime, który wykazuje bezgłowy / głowy parytetu przez projektowanie - wartości odcisków palców są identyczne niezależnie od trybu, listy plugin są zaludnione, a wersja Chrome jest zgodna. Jeśli stosu używa bezgłowy Chromium ze stealth plugins, plan debugowania każdej powierzchni indywidualnie.

15-minutowy przepływ diagnostyczny

Kiedy wskaźnik CAPTCHA wzrasta, przepracuj je w kolejności. Większość awarii rozwiązuje się przy jednym z pierwszych trzech sygnałów.

1. Otwórz automatyczną przeglądarkę, odwiedź browserleaks.com/ip oraz browserleaks.com/javascript. Porównaj geografię IP, strefę czasową i Accept-Language. Jeśli nie opisują jednego spójnego kraju, Twoim problemem jest sygnał # 1. Napraw spójność i rewalidacji przed pójściem dalej.

2. Uruchom tę samą inspekcję odcisków palców w dwóch z twoich "różnych" sesji. Porównaj płótno, WebGL i hashy audio. Jeśli pasują, Twoim problemem jest sygnał # 2 - ponowne użycie odcisków palców w różnych sesjach. Flota jest jedną tożsamością, dopóki tego nie naprawisz.

3. Wizyta tls.peet.ws i porównać JA3 / JA4 do waniliowego Chrome na tym samym systemie operacyjnym. Niezgodność to sygnał # 3.

4. Sprawdź w konsoli navigator.webdriver i deskryptor właściwości. Niestandardowy deskryptor oznacza sygnał #4.

5. Ślad automatycznej interakcji. Ścieżki myszy linii Straight- line i jednolity czas są sygnałem # 5. Dodaj wariancję behawioralną.

6. Wizyta browserleaks.com/webrtc oraz browserleaks.com/dns. Lokalne IP, które nie pasują do twojego proxy są sygnałem # 6.

7. Jeśli bez głowy: porównać wszystkie sześć sygnałów między głowy (lokalne) i głowy (produkcja). Różnice są sygnałem # 7.

Jeśli przepracowałeś wszystkie siedem i stawki CAPTCHA są nadal wysokie, pozostałe przyczyny są zazwyczaj korelacje behawioralne w całej flocie (np., zsynchronizowane działania między sesjami) lub rate- to znaczy, wysyłasz zbyt wiele ruchu z zbyt niewielu IP w zbyt krótkim oknie. Są to problemy operacyjne, a nie stos problemów.

W celu uzyskania głębszego trybu awarii specyficznego dla Cloudflare- zobacz dlaczego skrypty Playwright zostają zablokowane przez Cloudflare. Aby ocenić, które narzędzia przeglądarki obsługują tę warstwę najlepiej, zobacz nasze porównanie 7 najlepszych przeglądarek do automatyzacji agenta AI.

Częste błędy w diagnostyce CAPTCHA

Próba każdego wtyczki stealth w kolei

Jazda rowerem przez wtyczki stealth bez pomiaru, który sygnał każdy z nich naprawia odpady tygodni. Uruchom diagnostykę, zidentyfikować słabe sygnały, a następnie wybrać rozwiązanie, które odnosi się do tych konkretnie. "Spróbuj innej biblioteki stealth" nie jest strategią diagnostyczną.

Zakładając, że scenariusz się zmienił

Jeśli twój kod jest niezmieniony, regresja jest środowiskowa: regresja witryny zaktualizowane zasady wykrywania, Twój basen IP został czarny wykaz, Twoja biblioteka stealth został wzorowo dopasowany, lub twój pojemnik bez głowy budowa dryfował. Bisect środowiska, a nie kod.

Traktowanie każdego CAPTCHA jako niepowodzenia w wykrywaniu

Niektóre strony wydają podstawowy CAPTCHA do każdej nowej sesji jako polityki, niezależnie od sygnałów. Jeśli wskaźnik CAPTCHA jest niezerowy, ale stabilny i skromny, które mogą być uzasadnione - pytanie jest, czy jest to, czy stopa jest zgodna z tym, co widzą prawdziwi użytkownicy, a nie czy jest to zero.

Rozwiązanie CAPTCHA zamiast zapobiegania

Usługi CAPTCHA- Solver istnieją i mają uzasadnione zastosowania. Ale rozwiązywanie CAPTCHA w skali jest powolny i kosztowny. Zapobieganie wyzwalania przez ustalenie spójności tożsamości jest szybszy i tańszy dla większości przepływów pracy. Rozpuszczalniki są odpowiednie dla nieredukowalnej stopy końcowej po diagnostyce, nie jako substytut diagnostyki.

Ignorowanie CPTCHA w ciągu tygodni

Wskaźnik CAPTCHA, który wspina się od 5% do 15% do 30% w ciągu miesiąca jest powolny wyciek - zazwyczaj odcisk palca lub wzór behawioralny coraz coraz bardziej oznakowane jak model wykrywania ewoluuje. Złapać to wcześnie poprzez monitorowanie szybkości jako metryka, nie tylko reagując, gdy sesje przerwy.

Często zadawane pytania

Dlaczego mój skrypt działa lokalnie, ale uruchamia CAPTCHA w produkcji?

Najczęstszą przyczyną jest dryf środowiskowy: rozwój lokalny wykorzystuje twój adres IP, twój prawdziwy czas i twój defeloper- maszyna odcisk palca, podczas gdy produkcja działa w kontenerze Linux za proxy datacenter z potencjalnie inną strefą czasową, locale, i powierzchni odcisków palców. Fix jest runtime, który produkuje identyczną tożsamość w obu środowiskach - Sygnały # 1, # 2 i # 7 są zwykle zaangażowane.

Czy jest sposób, aby obejść CAPTCHA powszechnie?

Nie. Nie ma konfiguracji przeglądarki, plugin, lub runtime, który omija CAPTCHA powszechnie. Realistycznym celem jest zmniejszenie tempa, w którym CAPTCHA są uruchamiane przez ustalanie sygnałów początkowych, które ich powodują. Sesje, które nadal otrzymują CAPTCHA po tym muszą być wycofane lub rozwiązane.

Czy należy korzystać z usługi rozwiązywania CAPTCHA-?

W przypadkach niskiego wolumenu, gdzie CAPTCHA są rzadkie pozostałości i kilka centów na rozwiązanie jest do przyjęcia, tak. W przypadku automatyzacji wysokiej głośności, gdzie CAPTCHA pojawiają się na większości sesji, odpowiedzią jest, aby najpierw naprawić sygnały diagnostyczne - rozwiązywanie CAPTCHA w wysokiej szybkości jest drogie i na tyle wolne, że zwykle łamie ekonomikę przepływu pracy.

Czy tylko proxy mieszkaniowe naprawiają uruchomienie CAPTCHA?

Nie. Proxy mieszkaniowe naprawiają sygnał # 1 częściowo (część geografii IP), ale pozostawiają odciski palców, TLS, behawioralne i headless- tell sygnały nietknięte. Proxy mieszkalne jest niezbędne dla niektórych stron i niewystarczający sam dla większości.

Jak szybko aktualizują się modele wykrywania?

Nieustannie, w praktyce. Duzi sprzedawcy antybotów aktualizują swoje modele co najmniej raz w tygodniu, czasami codziennie. Dlatego "to, co działało sześć miesięcy temu" nie jest wiarygodnym punktem odniesienia - każdy stos wymaga ciągłego pomiaru sygnałów diagnostycznych, a nie jednorazowej konfiguracji.

Wniosek: Diagnostyka Beat Trial i Błąd

Awarie CAPTCHA czują się jak pojedynczy problem, ponieważ objaw jest identyczny niezależnie od przyczyny. Rzeczywistość jest siedem różnych przyczyn, które muszą być zdiagnozowane indywidualnie. Zespoły, które obsługują to dobrze traktować ich stosu jak system inżynieryjny z mierzalnych sygnałów; zespoły, które walczą traktować go jak puzzle, aby rozwiązać przez próby losowe poprawki.

Wzór strukturalny jest taki sam we wszystkich siedmiu sygnałach: highest- level fix jest spójność tożsamości zaprojektowana na poziomie binarnym przeglądarki, z proxy związane z profilami odcisków palców i pamięci wyodrębnionej na sesję. Ten wzór adresuje Signals # 1, # 2, # 4, # 6 i # 7 jednocześnie, pozostawiając tylko # 3 (TLS, zwykle odziedziczony po Chromium) i # 5 (behawioralne, wymagające pracy na warstwie orchestracyjnej).

Clawbrowser jest zbudowany w celu rozwiązania tej warstwy strukturalnej. Engineer- poziom generowania odcisków palców, profile-związane proxy mieszkaniowe, i imiennosesyjne izolacja obsłużyć większość diagnostyki w jednym wyborze projektu. Dokumentacja przeglądarki.