Strefa czasowa przeglądarki, język i geolokalizacja: trzy pola, po których serwisy wykrywają proxy

Wprowadzenie: dlaczego trzy skromne pola decydują o losie konta

Wyobraź sobie kontrolę paszportową. Podajesz dokument jednego kraju, odpowiadasz w języku drugiego, a zegarek na ręce pokazuje czas trzeciego. Strażnikowi granicznemu nie potrzeba skomplikowanych ekspertyz. Po prostu zada dodatkowe pytania. Mniej więcej tak działa antifraud współczesnych platform. Nie musi analizować wymyślnych odcisków sieciowych ani liczyć hashy podsystemów graficznych. Wystarczy, że porówna trzy proste pola: strefę czasową przeglądarki, język i geolokalizację, a następnie zestawi je z tym, co mówi adres IP.

Z naszych obserwacji projektów multiaccounting wynika, że wśród przyczyn utraty profili w pierwszych 24 godzinach niezgodność środowiska pewnie zajmuje pierwsze miejsce. Wyprzedza zarówno jakość samego proxy, jak i „ciężkie” odciski. Powód jest prosty. Dobre mobilne proxy daje ci czyste IP prawdziwego operatora sieci, ale całe środowisko wokół tego IP konfigurujesz sam. I właśnie tutaj najczęściej pojawia się sprzeczność, którą platforma zauważa w milisekundy.

Z tego poradnika dowiesz się:

• jakimi dokładnie API i nagłówkami serwisy czytają strefę czasową, język i geolokalizację;
• dlaczego przesunięcie względem UTC i nazwa strefy to dwie różne rzeczy i jak na różnicy wychwytuje się podmianę;
• czym Accept-Language różni się od navigator.languages i dlaczego nie mogą się rozchodzić;
• jak postępować z żądaniem geolokalizacji: odmawiać, zezwalać czy uzgadniać współrzędne;
• jak zbudować kompleksowy framework zgodności środowiska pod mobilne IP i protokół autoweryfikacji;
• jakie błędy popełniają nawet doświadczone zespoły i co z tym zrobić.

Świadomie nie poruszamy canvas, WebGL, odcisków audio i sygnatur sieciowych na poziomie transportu. Tym zagadnieniom poświęcone są osobne materiały na blogu. Tutaj skupiamy się na jednym: spójności kontekstu. Trzy pola, które są sprawdzane pierwsze, są najtańsze dla antifradu i dają najwyższy sygnał na jednostkę wysiłku. Zastanówmy się, jak nie podarować platformie tego sygnału.

Podstawy: czym jest zgodność środowiska i dlaczego IP zawsze ma rację

Pojęcie spójności kontekstu

Przez zgodność środowiska rozumiemy sytuację, w której wszystkie sygnały o miejscu i czasie użytkownika, które przeglądarka przekazuje serwisowi, opowiadają jedną historię. Punktem odniesienia jest adres IP. Użytkownik nie może go dowolnie przepisać, więc antifraud uznaje IP za najbardziej uczciwego świadka. Wszystkie pozostałe pola są porównywane właśnie z nim, a nie ze sobą nawzajem.

Stąd pierwsza zasada, którą warto zapamiętać na zawsze: to nie IP dostosowuje się do przeglądarki, lecz przeglądarka do IP. Jeśli podłączyłeś mobilne proxy, którego geografię bazy określają jako Nowosybirsk, to Nowosybirskiem powinien „oddychać” cały profil. Strefa czasowa przeglądarki, język, współrzędne, format dat i liczb — wszystko to są konsekwencje, a IP jest przyczyną.

Trzy pola w zbliżeniu

Strefa czasowa. Przeglądarka wie, w jakiej strefie żyje system operacyjny, i chętnie przekazuje to każdemu skryptowi. Co więcej, przekazuje to na kilka sposobów: jako nazwę strefy w formacie IANA (np. Europe/Warsaw lub Europe/Moscow), jako liczbową różnicę w minutach względem UTC i jako zlokalizowany opis wewnątrz tekstowej reprezentacji daty. Antifraud porównuje te reprezentacje między sobą i ze strefą, której oczekuje się dla IP.

Język. To najbardziej wielowarstwowe pole. Język jest przekazywany jeszcze przed wykonaniem jakiegokolwiek skryptu, w nagłówku HTTP Accept-Language każdego żądania. Następnie jest duplikowany w JavaScripcie przez navigator.language i navigator.languages. Dalej język przenika do ustawień regionalnych formatowania: jak wyglądają daty, separatory tysięcy, przecinek lub kropka dziesiętna, nazwy miesięcy. Wreszcie wpływa na układ klawiatury, który przeglądarka widzi przez zdarzenia wprowadzania.

Geolokalizacja. Tutaj są dwie warstwy. Pasywna — to, co o tobie myślą bazy geolokalizacji IP. Aktywna — Geolocation API, które zwraca współrzędne tylko za zgodą użytkownika. Błędem jest sądzić, że skoro nie kliknąłeś „Zezwól”, pole pozostaje puste. Sam stan zgody, zachowanie przy żądaniu i pośrednie oznaki lokalizacji również są czytane.

Dlaczego sprawdza się właśnie te trzy pola

Odpowiedź kryje się w ekonomii antifradu. Te sygnały:

• są czytane za darmo, bez ciężkich obliczeń i bez specjalnych uprawnień (poza dokładnymi współrzędnymi);
• są deterministyczne: u prawdziwego użytkownika prawie nie zmieniają się z sesji na sesję;
• mają sztywne logiczne powiązanie z IP, które można sprawdzić prostą regułą, bez uczenia maszynowego;
• słabo poddają się „przypadkowej” podmianie: jeśli zmieniać je chaotycznie, sprzeczności tylko się mnożą.

Innymi słowy, to pierwszy filtr. Sam w sobie nie banuje, ale podnosi wewnętrzny wynik ryzyka. A potem włączają się droższe sprawdzenia, a profil ze złym wynikiem startowym dostaje znacznie mniej prawa do błędu.

Jak wygląda normalny użytkownik

Weźmy prawdziwego abonenta z Krakowa, który wchodzi na stronę z telefonu przez internet mobilny. Jego IP należy do operatora sieci, a baza geolokalizacji przypisze adres do Małopolski lub, co nierzadkie, do Warszawy, gdzie zarejestrowana jest pula adresów. Strefa czasowa przeglądarki — Europe/Warsaw, przesunięcie plus 60 minut. Język — pl-PL, za nim możliwy en-US na drugiej pozycji. Geolokalizacja — albo nie była pytana, albo zezwolona i wskazuje Kraków z dokładnością do kilkudziesięciu metrów. Format daty — dzień, miesiąc, rok przez kropkę. Wszystko logiczne, wszystko się składa.

Teraz ten sam obraz, ale z typowym błędem operatora multiaccountingu: IP to samo, a przeglądarka pokazuje America/New_York, język en-US, a współrzędne — centrum Berlina ze starego szablonu profilu. Każde pole osobno wygląda niewinnie. Razem tworzą użytkownika, który nie istnieje.

Szczególność mobilnych IP, o której się zapomina

Jest tu subtelność ważna właśnie dla odbiorców mobilnych proxy. Bazy geolokalizacji określają nie fizyczne położenie abonenta, lecz region, do którego operator przypisał zakres adresów. Dlatego prawdziwy użytkownik z Gdańska może dostać IP, które bazy przypisują do Gdyni lub nawet do Warszawy. Co z tym zrobić? Kierować się tym, co widzą bazy, a nie tym, gdzie fizycznie stoi modem. Platforma porównuje twój profil nie z rzeczywistością, lecz z zapisami w swoich katalogach. Dlatego pierwszym krokiem każdej konfiguracji jest ustalenie, jak dokładnie twój IP klasyfikuje kilka popularnych baz, i dopiero od tego budować środowisko.

Głębokie zanurzenie: jak serwisy naprawdę czytają trzy pola

Strefa czasowa przeglądarki: trzy źródła jednej prawdy

Większość użytkowników narzędzi antydetekcyjnych wyobraża sobie strefę czasową jako jedną liczbę. W praktyce przeglądarka przekazuje co najmniej trzy niezależne reprezentacje, a antifraud sprawdza ich wzajemną spójność.

Pierwsza — nazwa strefy według standardu IANA, którą zwraca metoda Intl.DateTimeFormat().resolvedOptions().timeZone. To ciąg znaków w rodzaju Europe/Warsaw, Asia/Novosibirsk, Europe/Berlin. Niesie więcej informacji niż przesunięcie, bo jednoznacznie określa reguły przejścia na czas letni i historię zmian strefy.

Druga — liczbowe przesunięcie z new Date().getTimezoneOffset(). Zwraca różnicę między UTC a czasem lokalnym w minutach, przy czym z odwrotnym znakiem: dla Warszawy to minus 60, dla Moskwy minus 180. Kluczowy moment: przesunięcie jest obliczane dla konkretnej daty. Dla strefy z czasem letnim w styczniu i w lipcu wyniki są różne.

Trzecia — reprezentacja tekstowa daty przez Date.prototype.toString(), gdzie w nawiasach podana jest zlokalizowana nazwa strefy, np. „Europa Środkowa, czas standardowy” lub „Central European Summer Time”. Zwróć uwagę: opis jest renderowany w języku interfejsu przeglądarki. To jeden z nielicznych punktów, gdzie strefa czasowa przeglądarki i język przecinają się bezpośrednio, i na tym przecięciu dobrze widać nieudolne podmiany.

Jak to wykorzystują przeciwko tobie? Klasyczna sztuczka — obliczyć przesunięcie dla 1 stycznia i 1 lipca. Jeśli zadeklarowana strefa to Europe/Berlin, przesunięcia powinny różnić się o 60 minut. Jeśli obie wartości są takie same, znaczy to, że ktoś podmienił strefę, nie nauczywszy przeglądarki reguł czasu letniego. Odwrotna sytuacja też jest wymowna: strefa Europe/Moscow, gdzie czasu letniego nie ma od 2014 roku, nagle pokazuje różne przesunięcia. Jeszcze inna sztuczka — porównać zlokalizowany opis w toString z językiem navigator.language. Rosyjski opis przy zadeklarowanym języku angielskim to marker.

Poza samą strefą serwisy interesują się rozsynchronizowaniem zegara systemowego. Skrypt wysyła na serwer wartość Date.now() i porównuje z czasem otrzymania żądania. Rozbieżność w granicach kilku sekund jest normalna. Rozbieżność w minuty, a tym bardziej w godziny, oznacza, że czas systemowy został ustawiony ręcznie i niedokładnie. Sam w sobie to nie wyrok, ale w sumie z innymi sygnałami waga rośnie.

W 2026 roku do tego zestawu dochodzi Temporal API, które stopniowo wypiera stary obiekt Date. Jeszcze ściślej wiąże czas ze strefą IANA i czyni podmianę przez proste przesunięcie praktycznie bezsensowną. Trend jest oczywisty: przeglądarki zmierzają ku temu, by strefa była nazwaną całością, a nie liczbą.

Język: od nagłówka do formatu liczb

Język to jedyne z trzech pól, które serwer widzi przed załadowaniem strony. Nagłówek Accept-Language wychodzi z pierwszym żądaniem i wygląda mniej więcej tak: pl-PL,pl;q=0.9,en-US;q=0.8,en;q=0.7. Wartości q to wagi preferencji, maleją od pierwszego elementu do ostatniego. Format ciągu zależy od przeglądarki i systemu: Chrome buduje go w jeden sposób, Safari — w inny, a antifraud umie odróżniać szablony.

Następnie język jest duplikowany po stronie klienta. navigator.language zwraca główny język, navigator.languages — uporządkowaną tablicę. W poprawnie działającej przeglądarce ta tablica i nagłówek Accept-Language pokrywają się pod względem składu i kolejności. Rozbieżność między nimi to jeden z najczęstszych i najbardziej oczywistych objawów tego, że środowisko złożono z różnych części: nagłówek podmieniono na poziomie klienta proxy, a obiekt JavaScript pozostał z ustawieniami systemu, albo odwrotnie.

Dalej język schodzi głębiej. Metoda Intl.DateTimeFormat().resolvedOptions().locale zwraca ustawienia regionalne formatowania. Wywołanie toLocaleDateString() bez parametrów rysuje datę w formacie tych ustawień: 05.03.2026 dla polskich, 3/5/2026 dla amerykańskich. Intl.NumberFormat decyduje, co oddziela tysiące — spacja, przecinek czy kropka. To wszystko też jest porównywane z zadeklarowanym językiem, a szczególnie uważnie — ze strefą czasową. Użytkownik ze strefą Asia/Tokyo i ustawieniami regionalnymi formatowania pl-PL jest możliwy, ale rzadki, i jego wynik ryzyka będzie wyższy od średniej.

Są też oznaki pośrednie. Zdarzenia klawiatury zwracają fizyczny kod klawisza i znak, który ona wyprodukowała. Jeśli przy zadeklarowanym języku pl-PL użytkownik wpisuje cyrylicę bez przełączania układu, a układ systemu jest przy tym widoczny jako jedyny, to też sprzeczność. Nie będziemy zagłębiać się w analizę behawioralną, ale warto rozumieć: język to nie ciąg znaków, lecz cała warstwa zachowania przeglądarki.

Geolokalizacja: warstwa pasywna i aktywna

Warstwa pasywna — bazy geolokalizacji IP. Jest kilka dużych, i nie zawsze są ze sobą zgodne. Dla zakresów mobilnych rozbieżności są szczególnie widoczne: jeden katalog wskaże miasto regionalne, drugi — stolicę, trzeci — po prostu kraj bez miasta. Dlatego jedno sprawdzenie w jednej bazie niczego nie gwarantuje. Duże platformy używają kilku źródeł i własnych zgromadzonych danych, gdzie adres jest zestawiony z rzeczywistymi współrzędnymi milionów użytkowników, którzy kiedyś zezwolili na dostęp do lokalizacji.

Warstwa aktywna — Geolocation API. Metoda navigator.geolocation.getCurrentPosition zwraca szerokość, długość, dokładność w metrach, a jeśli są dostępne — wysokość, prędkość i kierunek, plus znacznik czasu. Na smartfonie źródłem jest nawigacja satelitarna i stacje bazowe, dokładność 5–50 metrów. Na komputerze stacjonarnym współrzędne są obliczane na podstawie otaczających sieci bezprzewodowych i IP, dokładność — od setek metrów do kilometrów. Ta różnica jest kluczowa: jeśli profil emuluje przeglądarkę mobilną, a dokładność zwracana jest 5000 metrów z zerową wysokością, obraz wygląda nienaturalnie.

Osobna historia — stan zgody. Przez navigator.permissions.query serwis może dowiedzieć się, czy dostęp do geolokalizacji jest zezwolony, zablokowany, czy jeszcze nie był pytany. Robi się to cicho, bez wyskakującego okna. Prawdziwi użytkownicy rozkładają się na wszystkie trzy stany, ale u typowego nowego gościa zgoda znajduje się w stanie „jeszcze nie pytano”. Jeśli u setki świeżych kont z jednej sieci geolokalizacja jest jednakowo i natychmiast zablokowana, to oznaka automatycznej konfiguracji.

Sprawdzenia krzyżowe: gdzie schodzą się trzy pola

Najciekawsze zaczyna się, gdy antifraud przestaje patrzeć na pola osobno. Kilka powiązań, które spotyka się w praktyce systemów antifraud:

• Współrzędne i strefa. Po szerokości i długości jednoznacznie oblicza się strefę czasową. Współrzędne Krakowa ze strefą Asia/Vladivostok — sprzeczność, która nie wymaga wyjaśnień.
• Kraj IP i język. Dla każdego kraju istnieje oczekiwany rozkład języków. Niemieckie IP z językiem pl-PL nie jest zabronione, ale wypada ze statystyki, a więc dodaje punktów ryzyka.
• Strefa i aktywność. Konto ze strefą Europe/Warsaw, które stale jest aktywne od trzeciej do szóstej rano czasu lokalnego, wygląda jak konto zarządzane z innej strefy.
• Strefa i data rejestracji. Platforma pamięta, w jakiej strefie tworzono konto. Zmiana strefy jest dopuszczalna przy przeprowadzkach, ale częste skoki między niekompatybilnymi strefami to sygnał.
• Dokładność współrzędnych i typ urządzenia. Mobilny User-Agent z dokładnością w kilometry albo przeglądarka stacjonarna z dokładnością w trzy metry — oba warianty są nienaturalne.

Zrozumienie tych powiązań to połowa sukcesu. Druga połowa — dyscyplina konfiguracji, do której przechodzimy.

Metoda 1. Strefa czasowa przeglądarki: konfiguracja pod mobilne IP bez sprzeczności

Teoria: strefa kontra przesunięcie

Główny błąd pojęciowy — myśleć o strefie czasowej jak o liczbie. Poprawnie myśleć o niej jak o nazwanej strefie IANA. Liczba (przesunięcie) to pochodna strefy i daty. Kiedy ustawiasz w konfiguracji profilu właśnie nazwę strefy, przeglądarka sama poprawnie obliczy przesunięcie dla dowolnej daty, właściwie obsłuży czas letni i narysuje zlokalizowany opis. Kiedy ustawiasz tylko przesunięcie, bierzesz na siebie obowiązek ręcznego utrzymywania całej reszty, i niemal na pewno gdzieś się pomylisz.

Dla Polski jest to szczególnie wygodne: czas letni obowiązuje, więc trzeba o nim pamiętać, ale stref jest mniej niż w Rosji. Jeśli pracujesz z proxy z krajów europejskich lub Ameryki Północnej, reguły przejścia na czas letni stają się źródłem sezonowych wpadek. Zespoły, które konfigurowały profile zimą przez stałe przesunięcie, wiosną nagle dostają falę niezgodności, nie rozumiejąc przyczyny.

Konfiguracja krok po kroku

1. Ustal strefę IP, a nie fizycznego modemu. Sprawdź adres mobilnego proxy przynajmniej w dwóch–trzech bazach geolokalizacji. Zapisz region i miasto, które wskazują. Jeśli bazy się rozchodzą, kieruj się tą, która częściej pokrywa się ze zdaniem twoich docelowych platform (empirycznie ustala się to po pierwszych sesjach).
2. Dopasuj region do strefy IANA. Dla Polski działa jedna strefa: Europe/Warsaw (UTC+1, z czasem letnim UTC+2). Dla innych krajów europejskich działają osobne strefy: Europe/Berlin (UTC+1), Europe/Prague (UTC+1), Europe/Kyiv (UTC+2), Europe/London (UTC+0), Europe/Lisbon (UTC+0). Dla rosyjskich regionów działa jedenaście stref: Europe/Kaliningrad (UTC+2), Europe/Moscow (UTC+3), Europe/Samara (UTC+4), Asia/Yekaterinburg (UTC+5), Asia/Omsk (UTC+6), Asia/Krasnoyarsk (UTC+7), Asia/Irkutsk (UTC+8), Asia/Yakutsk (UTC+9), Asia/Vladivostok (UTC+10), Asia/Magadan (UTC+11), Asia/Kamchatka (UTC+12). Zwróć uwagę: niektóre regiony mają własne strefy IANA o tym samym przesunięciu, np. Europe/Volgograd lub Asia/Tomsk. Użycie poprawnej nazwy dla regionu jest lepsze niż najbliższego „dużego” odpowiednika.
3. Ustaw strefę nazwą, a nie przesunięciem. W konfiguracji profilu wybieraj wariant, w którym podaje się ciąg w rodzaju Europe/Warsaw. Jeśli narzędzie oferuje tylko liczbowe przesunięcie, to powód, by zwątpić w jego dojrzałość.
4. Zsynchronizuj zegar systemowy. Upewnij się, że system operacyjny pobiera czas przez protokół synchronizacji sieciowej. Rozbieżność z rzeczywistym czasem powinna mieścić się w sekundach. Dotyczy to też maszyn wirtualnych: ich zegary nierzadko „płyną” po zawieszeniu.
5. Sprawdź trzy reprezentacje. Otwórz konsolę i porównaj wynik Intl.DateTimeFormat().resolvedOptions().timeZone, wartość getTimezoneOffset() i opis w new Date().toString(). Wszystkie trzy powinny opisywać jedną strefę, a opis — być w języku profilu.
6. Sprawdź przesunięcie zimowe i letnie. Oblicz getTimezoneOffset dla dat 15 stycznia i 15 lipca bieżącego roku. Dla polskich stref różnica wynosi 60 minut. Dla stref bez czasu letniego wartości są równe. Każde inne zachowanie oznacza zepsutą emulację.
7. Powiąż strefę z rotacją. Jeśli twoje mobilne proxy przy zmianie IP może przenieść się do innego regionu, strefa powinna zmieniać się razem z nim. Lepiej skonfigurować proxy tak, by rotacja odbywała się w obrębie jednego regionu, i zapisać to w karcie profilu.

Przykład z praktyki

Zespół prowadził konta na platformie ogłoszeniowej z mobilnych proxy regionu śląskiego. Bazy określały adresy jako Katowice. W szablonie profilu pozostała strefa Europe/Moscow z poprzedniego projektu. Pierwsze dni nic się nie działo, a piątego dnia wszystkie konta trafiły pod rozszerzoną weryfikację. Przy analizie okazało się, że na platformie działa dokładnie to powiązanie „strefa kontra współrzędne IP”, które opisaliśmy powyżej: różnica kilku godzin między oczekiwaną a faktyczną strefą przekroczyła wewnętrzny próg. Po zmianie strefy na Europe/Warsaw i odtworzeniu profili powtórne weryfikacje ustały.

Lista kontrolna dotycząca strefy czasowej

• Strefa ustawiona nazwą IANA, odpowiadającą regionowi IP według baz.
• Czas systemowy zsynchronizowany, rozbieżność z serwerem poniżej 5 sekund.
• Trzy reprezentacje strefy są ze sobą zgodne.
• Przesunięcie zimowe i letnie zachowują się poprawnie dla tej strefy.
• Zlokalizowany opis strefy wyświetla się w języku profilu.
• Rotacja IP nie wyprowadza adresu poza strefę albo strefa aktualizuje się razem z nim.
• W karcie profilu zapisano, jaka to strefa i dlaczego.

Metoda 2. Język: zgodność nagłówków, obiektów i formatów

Teoria: język jako wielowarstwowe ciasto

Widzieliśmy już, że język żyje co najmniej na czterech poziomach: nagłówek HTTP, obiekty JavaScript, ustawienia regionalne formatowania i oznaki systemowe w rodzaju układu klawiatury. Każdy poziom tworzy inny komponent. Nagłówek zbiera stos sieciowy przeglądarki z jej ustawień języków. Obiekty navigator biorą się stamtąd, ale podmiana na jednym poziomie nie zawsze automatycznie przenika na drugi. Ustawienia regionalne formatowania często dziedziczą się z systemu operacyjnego, a nie z przeglądarki. Stąd niezgodności.

Druga ważna myśl: język musi odpowiadać nie tylko krajowi IP, ale i prawdopodobnej biografii użytkownika. Całkowicie jednojęzyczne profile zdarzają się rzadziej, niż się wydaje. U prawdziwego człowieka lista języków ma zwykle dwa–trzy punkty: język ojczysty z kodem regionalnym, ten sam język bez regionu i angielski jako zapasowy. Właśnie taką listę domyślnie tworzy typowa przeglądarka.

Konfiguracja krok po kroku

1. Wybierz główne ustawienia regionalne według kraju IP. Dla polskiego mobilnego IP to pl-PL. Dla niemieckiego — de-DE lub de-AT w zależności od legendy profilu. Dla krajów z kilkoma językami urzędowymi sprawdź, który dominuje w regionie IP.
2. Zbuduj listę języków. Realistyczna tablica dla polskojęzycznego profilu: pl-PL, pl, en-US, en. Kolejność jest ważna. Nie zaczynaj od angielskiego, jeśli główne ustawienia regionalne są polskie.
3. Sprawdź nagłówek Accept-Language. Powinien odtwarzać tę samą listę z malejącymi wagami q. Upewnij się, że format odpowiada typowi przeglądarki, który emuluje profil.
4. Porównaj navigator.language i navigator.languages. Pierwsza wartość równa się pierwszemu elementowi tablicy. Tablica pokrywa się z nagłówkiem pod względem składu i kolejności.
5. Sprawdź ustawienia regionalne formatowania. Wywołaj Intl.DateTimeFormat().resolvedOptions().locale, następnie new Date().toLocaleDateString() i (1234567.89).toLocaleString(). Format powinien odpowiadać głównemu językowi: kropka jako separator daty i spacja jako separator tysięcy dla pl-PL.
6. Uzgodnij język interfejsu systemu. Jeśli profil jest polskojęzyczny, a ustawienia regionalne maszyny wirtualnej są angielskie, część ciągów (w tym opis strefy czasowej) okaże się po angielsku. Doprowadź system do porządku albo upewnij się, że narzędzie poprawnie nadpisuje te wartości.
7. Pomyśl o układzie klawiatury. Jeśli operator wpisuje polski tekst, system powinien mieć polski układ, a profil — polski język. Angielski profil z aktywnym polskim wpisywaniem wygląda podejrzanie.

Przykład z praktyki

Zespół arbitrażowy pracował z platformą społecznościową, używając polskich mobilnych proxy, ale szablony profili były odziedziczone z projektu pod angielskojęzyczną publiczność. Nagłówek Accept-Language był zmieniany na pl-PL siłami narzędzia antydetekcyjnego, ale obiekt navigator.languages pozostawał en-US, en. Sesje żyły średnio krócej niż dobę. Po doprowadzeniu tablicy języków i ustawień regionalnych formatowania do zgodności z nagłówkiem średni czas życia profilu wzrósł wielokrotnie, choć same proxy i pozostałe ustawienia się nie zmieniły. Koszt poprawki — jeden wieczór pracy z szablonem.

Lista kontrolna dotycząca języka

• Główne ustawienia regionalne odpowiadają krajowi i regionowi IP.
• Lista języków zawiera dwa–cztery elementy w prawdopodobnej kolejności.
• Accept-Language i navigator.languages pokrywają się pod względem składu i kolejności.
• navigator.language równa się pierwszemu elementowi tablicy.
• Ustawienia regionalne formatowania, data i liczby renderują się w formacie głównego języka.
• Ustawienia regionalne systemu nie przeciekają do angielskich ciągów przy polskim profilu.
• Układ klawiatury i rzeczywiste wpisywanie są zgodne z zadeklarowanym językiem.

Metoda 3. Geolokalizacja: trzy strategie i zasady współrzędnych

Teoria: zgoda ważniejsza od współrzędnych

Wielu koncentruje się na tym, jakie współrzędne oddać serwisowi, i pomija fakt, że większość platform w ogóle nie pyta zwykłego użytkownika o dokładną geolokalizację. O wiele ważniejsze jest, jak profil zachowuje się wobec samego żądania i w jakim stanie jest zgoda. Stąd trzy strategie.

Strategia „nie pytano”. Zgoda pozostaje w stanie początkowym, współrzędne nie są wydawane. To najbardziej naturalny stan dla nowego użytkownika większości serwisów. Pasuje do scenariuszy, w których platforma nie wymaga dokładnej lokalizacji: konta reklamowe, większość platform społecznościowych, markety z ręcznym wyborem regionu.

Strategia „zezwolono i uzgodniono”. Profil wydaje współrzędne, które znajdują się w rozsądnej bliskości miasta IP, z realistyczną dokładnością i niewielkim dryfem między sesjami. Pasuje do usług, w których lokalizacja jest częścią funkcjonalności: mapy, dostawa, ogłoszenia z przypisaniem do dzielnicy, niektóre aplikacje mobilne w otoczce webowej.

Strategia „zablokowano”. Najbardziej ryzykowna przy masowym stosowaniu. Pojedyncza odmowa jest normalna, ale identyczna natychmiastowa odmowa na setkach profili jednej sieci tworzy rozpoznawalny wzorzec. Używaj tylko tam, gdzie to świadoma decyzja pod konkretną legendę.

Konfiguracja krok po kroku dla strategii „zezwolono i uzgodniono”

1. Ustal, jakie miasto bazy przypisują IP. Jak przy strefie czasowej, kieruj się katalogami, a nie fizycznym położeniem modemu.
2. Nie bierz współrzędnych z samej bazy. Katalogi zwracają centroid miasta — jeden punkt dla wszystkich. Tysiące użytkowników narzędzi podszywających się używa go tak samo. Wybierz prawdziwą dzielnicę mieszkalną lub biznesową w odległości od jednego do piętnastu kilometrów od centrum.
3. Ustaw realistyczną dokładność. Dla profilu mobilnego — od 10 do 80 metrów, dla stacjonarnego — od 500 do 5000 metrów. Dokładność 1 metra albo równo 100 metrów wygląda syntetycznie.
4. Dodaj dryf. Między sesjami współrzędne prawdziwego człowieka zmieniają się: dom, praca, droga. Przesunięcie o kilkaset metrów albo przełączanie między dwoma–trzema „domowymi” punktami wygląda naturalniej niż jedna nieruchoma współrzędna przez miesiące.
5. Uzgodnij dodatkowe pola. Na profilu stacjonarnym wysokość, prędkość i kierunek powinny być nieobecne. Na mobilnym wysokość może być obecna, ale musi być prawdopodobna dla terenu.
6. Upewnij się, że strefa wynika ze współrzędnych. Sprawdź, że strefa czasowa przeglądarki odpowiada strefie wybranego punktu. Dla regionów przygranicznych nie zawsze jest to oczywiste.
7. Sprawdź stan zgody. Zapytaj navigator.permissions.query dla geolokalizacji i upewnij się, że odpowiada wybranej strategii.

Przykład z praktyki

Serwis dostaw wymagał potwierdzenia dzielnicy przez geolokalizację. Zespół zarządzający kilkoma kontami partnerskimi używał mobilnych proxy jednego regionu i wydawał wszystkim profilom jeden punkt — centrum miasta z bazy IP. Po dwóch tygodniach konta trafiły na ręczną weryfikację: dziesiątki kont z identycznymi współrzędnymi do szóstego miejsca po przecinku były wyraźną anomalią. Zastąpienie ich indywidualnymi punktami w różnych dzielnicach z dryfem rozwiązało problem dla nowych kont.

Lista kontrolna dotycząca geolokalizacji

• Wybrano świadomą strategię: nie pytano, zezwolono, zablokowano.
• Stan zgody odpowiada strategii i nie jest identycznie natychmiastowy na masie profili.
• Współrzędne znajdują się w granicach 1–30 km od miasta IP według baz.
• Współrzędne nie pokrywają się z centroidem miasta i są unikalne dla każdego profilu.
• Dokładność odpowiada typowi urządzenia profilu.
• Jest dryf między sesjami.
• Strefa czasowa pokrywa się ze strefą wybranych współrzędnych.

Metoda 4. Kompleksowy framework „Paszport profilu” i protokół autoweryfikacji

Idea: jedna karta — jedna historia

Rozproszone listy kontrolne działają, dopóki profili jest kilkanaście. Kiedy są ich setki, potrzebny jest system. Nazywamy go „Paszportem profilu”: dokument lub wpis w tabeli, w którym dla każdego profilu zapisane jest źródło prawdy i wszystkie pochodne od niego pola. Zasada: każde pole powinno wynikać z poprzedniego, i żadne nie powinno przeczyć IP.

Struktura paszportu

• IP i operator. Zakres mobilnego proxy, operator, region według dwóch–trzech baz, data sprawdzenia.
• Strefa IANA. Wyprowadzona z regionu IP. Podane przesunięcie i informacja o obecności czasu letniego.
• Języki. Główne ustawienia regionalne, pełna lista, ciąg Accept-Language.
• Ustawienia regionalne formatowania. Format daty i liczb, oczekiwany wynik toLocaleDateString.
• Strategia geo. Jedna z trzech strategii; jeśli „zezwolono” — bazowe współrzędne, dokładność, reguły dryfu.
• Kontekst systemowy. Język systemu, status synchronizacji czasu, układy klawiatury.
• Typ urządzenia. Profil mobilny lub stacjonarny, bo od tego zależą oczekiwania co do dokładności geolokalizacji i formatu nagłówków.
• Historia zmian. Kiedy i dlaczego zmieniano strefę lub języki, żeby nie robić gwałtownych skoków.

Protokół autoweryfikacji przed uruchomieniem

1. Sprawdź IP w kilku bazach. Zapisz kraj, region, miasto. Jeśli choć jedna baza podaje inny region, oznacz to jako ryzyko i w miarę możliwości poproś dostawcę proxy o adres o bardziej jednoznacznej geografii.
2. Otwórz stronę sprawdzającą środowisko. Porównaj wyświetlaną strefę czasową, język i geolokalizację z paszportem. Zrób to w dwóch różnych serwisach: używają różnych baz i różnych metod.
3. Uruchom własny skrypt. Powinien zbierać te same pola co antifraud i od razu podświetlać rozbieżności. Poniżej — minimalny przykład, który można wkleić do konsoli.
4. Sprawdź powiązania krzyżowe. Strefa ze współrzędnych równa się strefie przeglądarki. Język odpowiada krajowi. Opis strefy — w języku profilu.
5. Zasymuluj rotację. Zmień IP proxy i powtórz kroki 1–4. Upewnij się, że region się nie zmienił albo profil przebudował.
6. Zapisz wynik. Wpisz datę sprawdzenia do paszportu. Powtarzaj procedurę po aktualizacji przeglądarki, narzędzia lub systemu operacyjnego.

Skrypt autoweryfikacji

Ten fragment zbiera podstawowe pola i drukuje je w jednym wierszu. Niczego nie podmienia, tylko czyta — dokładnie to samo, co antifraud robi w pierwszych milisekundach.

(function(){ var tz = Intl.DateTimeFormat().resolvedOptions().timeZone; var loc = Intl.DateTimeFormat().resolvedOptions().locale; var jan = new Date(new Date().getFullYear(), 0, 15).getTimezoneOffset(); var jul = new Date(new Date().getFullYear(), 6, 15).getTimezoneOffset(); var out = { zone: tz, offsetNow: new Date().getTimezoneOffset(), offsetJan: jan, offsetJul: jul, dst: jan !== jul, dateString: new Date().toString(), language: navigator.language, languages: navigator.languages.join(','), locale: loc, dateFormat: new Date().toLocaleDateString(), numberFormat: (1234567.89).toLocaleString() }; if (navigator.permissions) { navigator.permissions.query({ name: 'geolocation' }).then(function(p){ out.geoPermission = p.state; console.table(out); }); } else { console.table(out); } })();

Czego szukać w wyniku? Strefa powinna pokrywać się z paszportem. Wskaźnik dst powinien odpowiadać regułom strefy. Ciąg dateString powinien zawierać opis w języku profilu. Tablica languages — pokrywać się z nagłówkiem. Format daty i liczb — odpowiadać ustawieniom regionalnym. Stan geolokalizacji — odpowiadać strategii. Pięć minut na sprawdzenie oszczędza dni na odzyskiwaniu kont.

Jak wdrożyć framework w zespole

Wyznacz osobę odpowiedzialną za szablony profili. Każda zmiana szablonu przechodzi przez protokół autoweryfikacji. Raz na kwartał przeglądaj regiony proxy: operatorzy redystrybuują zakresy, i baza może się „przenieść”. Ustanów krótki regulamin na wypadek, gdy dostawca proxy dodaje nowe regiony: najpierw paszport, potem uruchomienie. To nudne, ale właśnie nudne procesy odróżniają zespoły, które się skalują, od tych, które co miesiąc zaczynają od zera.

Typowe błędy: co robi nawet doświadczony zespół

Błąd 1. Konfigurowanie środowiska pod fizyczne miejsce modemu

Modem stoi w jednym mieście, bazy przypisują IP do innego, a profil skonfigurowano pod pierwsze. Platforma widzi drugie. Zawsze kieruj się katalogami, a nie geografią sprzętu.

Błąd 2. Ustawianie przesunięcia zamiast strefy

Stała liczba łamie czas letni i zlokalizowany opis. Dla stref bez czasu letniego jest to mniej widoczne, dla europejskich i północnoamerykańskich — prowadzi do sezonowych fal niezgodności.

Błąd 3. Podmiana tylko nagłówka albo tylko obiektu

Accept-Language mówi jedno, navigator.languages — drugie. To najczęstszy i najłatwiej wykrywalny błąd. Sprawdzaj oba poziomy po każdej zmianie.

Błąd 4. Zapominanie o ustawieniach regionalnych formatowania

Język polski, a data renderuje się jako 3/5/2026, bo ustawienia regionalne formatowania odziedziczono z angielskiego systemu. Drobiazg, ale trafia do tej samej analizy krzyżowej.

Błąd 5. Jeden punkt geolokalizacji na wszystkie profile

Centroid miasta z bazy IP — wspólny punkt dla tysięcy użytkowników narzędzi podszywających się. Unikalne współrzędne z dryfem rozwiązują problem.

Błąd 6. Masowa natychmiastowa odmowa geolokalizacji

Odmowa sama w sobie jest normalna. Identyczna odmowa na wszystkich kontach sieci — nie. Urozmaicaj strategie albo zostawiaj stan „nie pytano”.

Błąd 7. Ignorowanie zegara systemowego

Maszyny wirtualne i stare urządzenia tracą czas. Rozsynchronizowanie w minuty widać na serwerze od pierwszego żądania. Włącz synchronizację sieciową i sprawdzaj ją.

Błąd 8. Nieśledzenie rotacji regionów

Rotacja IP przeniosła adres do sąsiedniego regionu z inną strefą, a profil pozostał bez zmian. Ograniczaj rotację do regionu albo aktualizuj paszport przy każdej zmianie.

Błąd 9. Gwałtowna zmiana strefy u żywego konta

Konto zarejestrowane w strefie Europe/Warsaw, a nazajutrz działa z strefy Asia/Vladivostok. Jeśli zmiana regionu jest konieczna, rób ją stopniowo i z logicznym wyjaśnieniem przez zachowanie: pauzy, regiony pośrednie, odpowiedni czas aktywności.

Błąd 10. Sprawdzić raz i zapomnieć

Aktualizacja przeglądarki, narzędzia lub systemu operacyjnego może zresetować ustawienia regionalne i strefę. Powtarzaj protokół autoweryfikacji po każdej aktualizacji.

Narzędzia i zasoby

Bazy geolokalizacji IP

Używaj co najmniej dwóch–trzech niezależnych baz: komercyjnych katalogów dużych dostawców danych geolokalizacyjnych oraz serwisów, które agregują kilka źródeł i pokazują rozbieżności. Dla zakresów mobilnych szczególnie cenna jest możliwość zobaczenia nie tylko miasta, ale i operatora oraz typu połączenia. Dostawcy mobilnych proxy, którym zależy na jakości, zwykle podają region według baz bezpośrednio w interfejsie wydania adresu — korzystaj z tej informacji i weryfikuj ją samodzielnie.

Strony sprawdzające środowisko przeglądarki

Publiczne serwisy sprawdzające pokazują strefę czasową przeglądarki, języki, ustawienia regionalne, stan geolokalizacji i zestawiają je z IP. Ich wartość — w przejrzystości i w tym, że używają różnych baz. Ograniczenie — nie znają twojej legendy i nie sprawdzają powiązań krzyżowych tak, jak robi to konkretna platforma. Dlatego uzupełniaj je własnym skryptem.

Narzędzia antydetekcyjne i ich ustawienia

Dojrzałe rozwiązania pozwalają ustawiać strefę IANA po nazwie, automatycznie wyprowadzać ją z IP, synchronizować listę języków z nagłówkiem i konfigurować geolokalizację z dokładnością i dryfem. Przy wyborze narzędzia zadaj cztery pytania: czy strefę ustawia się nazwą, czy nagłówek i obiekt języków pokrywają się po podmianie, czy można ustawić unikalne współrzędne na profil, czy środowisko aktualizuje się przy zmianie IP. Negatywna odpowiedź na którekolwiek z nich — powód, by szukać alternatywy albo kompensować lukę ręczną kontrolą.

Własne skrypty i automatyzacja

Podany wyżej fragment to punkt wyjścia. Programiści w zespole mogą rozwinąć go do automatycznego sprawdzania: skrypt uruchamia się przy starcie profilu, porównuje wynik z paszportem i blokuje pracę przy rozbieżności. Dla scenariuszy API tę samą logikę warto zrealizować po stronie serwisu zarządzającego: przed wydaniem profilu operatorowi środowisko jest sprawdzane automatycznie.

Katalogi stref i narzędzia

Baza stref IANA jest publiczna i regularnie aktualizowana. Trzymaj pod ręką tabelę przyporządkowania regionów do stref, zwłaszcza dla krajów z kilkoma strefami. Do wyprowadzania strefy ze współrzędnych istnieją gotowe biblioteki, które wbudowuje się w automatyzację. Do synchronizacji czasu używaj standardowych środków systemu operacyjnego lub dedykowanego klienta czasu sieciowego.

Dokumentacja wewnętrzna

Tabela „Paszport profilu”, regulamin zmian szablonów i dziennik sprawdzeń — nie mniej ważne narzędzia niż jakikolwiek serwis. Bez nich wiedza żyje w głowie jednej osoby i odchodzi razem z nią.

Studia przypadków i wyniki

Przypadek 1. Konta reklamowe i odziedziczony szablon

Zespół sześciu operatorów prowadził konta reklamowe na dużej platformie społecznościowej z polskimi mobilnymi proxy. Szablon profilu tworzono pod projekt angielskojęzyczny i zawierał strefę America/New_York oraz języki en-US, en. Udział kont dożywających pierwszego doładowania utrzymywał się na poziomie około jednej trzeciej. Po wdrożeniu paszportu profilu ze strefą Europe/Warsaw, językami pl-PL, pl, en-US, en i strategią geolokalizacji „nie pytano” udział wzrósł do około czterech piątych w ciągu miesiąca. Proxy, urządzenia i pozostałe ustawienia się nie zmieniły. Jedyna zmienna — zgodność trzech pól.

Przypadek 2. Sezonowa wpadka u zespołu z europejskimi proxy

Zespół pracował z proxy kilku krajów europejskich i ustawiał strefę czasową przez liczbowe przesunięcie, ustalone zimą. Pod koniec marca zaczęła się fala dodatkowych weryfikacji na trzech platformach jednocześnie. Analiza pokazała: zadeklarowana strefa zakładała przejście na czas letni, a przesunięcie pozostało zimowe. Przejście na nazwane strefy IANA rozwiązało problem w jeden dzień, a jesienią wpadka się nie powtórzyła. Lekcja: przesunięcie to nie strefa.

Przypadek 3. Marketplace i identyczne współrzędne

Sprzedawca z kilkoma kontami na marketplace używał mobilnych proxy jednego regionu i zezwalał na geolokalizację, wydając wszystkim kontom współrzędne centrum miasta. Po dwóch tygodniach konta trafiły na ręczną weryfikację z żądaniem dokumentów. Nowe konta skonfigurowano z unikalnymi współrzędnymi w różnych dzielnicach, dokładnością 20–60 metrów i dryfem między sesjami. W następnym kwartale żadne z nowych kont nie otrzymało prośby o dodatkową weryfikację. Stare trzeba było odzyskiwać przez wsparcie.

Przypadek 4. Scraping treści regionalnych

Programista zbierał ceny regionalne ze strony, która pokazuje oferty według geolokalizacji i języka. Z mobilnymi proxy z Syberii, ale strefą i językiem domyślnymi z kontenera (UTC i en-US) strona okresowo zwracała uśrednione ceny, a czasem — stronę potwierdzenia regionu. Po powiązaniu strefy Asia/Novosibirsk, języka ru-RU i poprawnego nagłówka Accept-Language z każdą pulą regionalną udział poprawnych odpowiedzi wzrósł z około dwóch trzecich do niemal pełnego, a liczba stron potwierdzenia spadła do jednostek dziennie. Tu nie chodzi o blokady, lecz o jakość danych: niespójne środowisko po prostu psuło próbkę.

Przypadek 5. Rotacja prowadząca do sąsiedniej strefy

Agencja pracowała z proxy, u których rotacja IP czasem przenosiła adres z jednego województwa do drugiego, w innej strefie czasowej. Profile ze stałą strefą raz na kilka dni znajdowały się „o godzinę w bok” od IP. Po tym, jak dostawca ograniczył rotację do jednego regionu, a paszport profilu zaczął być sprawdzany przy każdym starcie, odchylenia zniknęły. Wymowne jest to, że problem zauważono tylko dzięki dziennikowi autoweryfikacji — wizualnie wszystko wyglądało normalnie.

FAQ: trudne pytania o strefę czasową, język i geolokalizację

Czy wystarczy, żeby strefa czasowa przeglądarki zgadzała się przesunięciem, jeśli nazwa strefy jest inna?

Nie. Strefa Europe/Warsaw i strefa Europe/Berlin mają to samo przesunięcie, ale różne historie zmian i różne zlokalizowane opisy. Poza tym antifraud porównuje nazwę strefy z miastem IP bezpośrednio, a nie przez przesunięcie. Zawsze ustawiaj strefę nazwą odpowiadającą regionowi.

Mobilne IP jest określane przez bazy jako Warszawa, choć modem jest w innym regionie. Pod co konfigurować profil?

Pod to, co widzą bazy. Platforma porównuje twój profil ze swoimi katalogami, a nie z rzeczywistością. Jeśli dwie–trzy bazy zgadzają się na Warszawie, użyj Europe/Warsaw i warszawskiej legendy. Jeśli bazy się rozchodzą, poproś dostawcę o adres o jednoznacznej geografii albo wybierz wariant, który pokrywa się ze zdaniem twoich docelowych platform po pierwszych sesjach.

Czy trzeba włączać angielski do listy języków polskojęzycznego profilu?

Nie trzeba, ale warto. Większość przeglądarek domyślnie dodaje angielski jako język zapasowy, i lista pl-PL, pl, en-US, en wygląda naturalniej niż jedyny pl-PL. Najważniejsze, żeby angielski nie stał pierwszy i żeby lista pokrywała się w nagłówku i w obiekcie navigator.languages.

Co jest bezpieczniejsze: zablokować geolokalizację czy zezwolić ze uzgodnionymi współrzędnymi?

Dla większości platform najbezpieczniejszy jest trzeci wariant — zostawić zgodę w stanie „nie pytano”. Zezwalać ze uzgodnionymi współrzędnymi warto tam, gdzie lokalizacja jest częścią funkcjonalności. Masowa identyczna blokada to najmniej udany wybór, bo tworzy rozpoznawalny wzorzec.

Jak często trzeba sprawdzać środowisko już działających profili?

Co najmniej po każdej aktualizacji przeglądarki, narzędzia antydetekcyjnego lub systemu operacyjnego, a także przy każdej zmianie regionu proxy. Planowe sprawdzenie rozsądnie robić raz w miesiącu. Zautomatyzowane sprawdzanie przy każdym starcie profilu zdejmuje pytanie całkowicie.

Czy rozsynchronizowanie zegara systemowego samo w sobie może prowadzić do problemów?

Samo w sobie — rzadko. Ale dodaje punktów ryzyka i łamie część logiki platform opartej na znacznikach czasu. Rozsynchronizowanie w godziny niemal zawsze oznacza, że czas ustawiano ręcznie, i to słabo współgra z legendą zwykłego użytkownika. Utrzymuj odchylenie w granicach sekund.

Czy trzeba zmieniać strefę czasową przeglądarki, jeśli konto „przeprowadza się” do innego regionu razem z proxy?

Tak, ale płynnie i z logiką. Gwałtowny skok z jednej strefy do niekompatybilnej wzbudza pytania. Jeśli przeprowadzka jest konieczna, zrób pauzę w aktywności, zmień strefę razem z IP i dopasuj czas aktywności do nowej strefy. Częste skoki tam i z powrotem — najgorszy scenariusz.

Jak język wpływa na wyświetlanie strefy czasowej w przeglądarce?

Bezpośrednio. Zlokalizowany opis strefy w tekstowej reprezentacji daty jest wyświetlany w języku interfejsu przeglądarki. Jeśli język profilu jest polski, a opis angielski, to oznaka, że ustawienia regionalne systemu różnią się od zadeklarowanego języka. Sprawdzaj new Date().toString() jako wskaźnik takiego przeciekania.

Czy jeden publiczny serwis sprawdzający wystarczy, żeby upewnić się o spójności?

Nie. Różne serwisy używają różnych baz IP i różnie interpretują pola. Używaj dwóch–trzech serwisów plus własnego skryptu, który sprawdza powiązania krzyżowe pod twoją konkretną legendę.

Zakończenie: jedna historia zamiast trzech sprzeczności

Strefa czasowa przeglądarki, język i geolokalizacja — najtańsze w sprawdzeniu i najbardziej wymowne pola ze wszystkich, które przeglądarka przekazuje serwisowi. Nie wymagają od platformy ani ciężkich obliczeń, ani uczenia maszynowego. Wystarczy prosta reguła: wszystko musi się zgadzać z IP. Właśnie dlatego niezgodność środowiska tak drogo kosztuje tych, którzy pracują z mobilnymi proxy: czyste IP prawdziwego operatora traci wartość, jeśli wokół niego zbudowano użytkownika, który nie istnieje.

Podsumujmy najważniejsze:

• IP to źródło prawdy. Kieruj się tym, co mówią o nim bazy, a nie fizycznym położeniem modemu.
• Strefę czasową ustawiaj nazwą strefy IANA, a nie przesunięciem, i sprawdzaj jej trzy reprezentacje oraz zachowanie zimą i latem.
• Język uzgadniaj na wszystkich poziomach: nagłówek, obiekty navigator, ustawienia regionalne formatowania, ustawienia regionalne systemu i układ klawiatury.
• Geolokalizację wybieraj jako strategię, a nie jako współrzędne. Jeśli zezwalasz na dostęp — unikalne punkty, realistyczna dokładność, dryf.
• Prowadź paszport profilu i przepuszczaj protokół autoweryfikacji przy każdym uruchomieniu i po każdej aktualizacji.

Co dalej? Dziś — przepuść skrypt autoweryfikacji na jednym z działających profili i porównaj wynik z tym, co bazy mówią o twoim IP. Najprawdopodobniej znajdzie się choć jedna rozbieżność. W tym tygodniu — załóż tabelę paszportów dla wszystkich aktywnych profili. W tym miesiącu — wbuduj sprawdzanie w proces uruchamiania i wyznacz osobę odpowiedzialną za szablony. To nie wymaga nowych budżetów, za to zwraca inwestycje w jakościowe mobilne proxy, które do tej pory mogły pracować na pół gwizdka z powodu trzech niespójnych pól.

Spójne środowisko nie gwarantuje nieśmiertelności kont — tego nie gwarantuje nic. Ale usuwa najgłośniejszy i najbardziej oczywisty sygnał, od którego zaczyna się każde sprawdzenie. A więc daje całej reszcie, którą robisz dobrze, szansę zadziałać.