User-Agent и мобильный fingerprint: где палится трафик, а где маскировка ломается

User-Agent и мобильный fingerprint: где палится трафик, а где маскировка ломается

Анализ логов показывает: один только User-Agent почти ничего не решает. Фильтры смотрят на связку признаков — заголовки, порядок их отправки, accept-language, viewport, canvas, WebGL, touch events, time zone. Если UA говорит «Android», а отпечаток тянет на десктопный Chromium без мобильных признаков, запрос выглядит как собранный на коленке.

Проверка цепочки прохождения запроса начинается с простого: совпадают ли UA, разрешение экрана, DPR, список шрифтов и поведение touch/pointer. На мобильном трафике часто палятся несостыковки: слишком «чистый» браузер, одинаковый WebGL vendor у разных сессий, нереалистичный timezone относительно IP, отсутствие характерных мобильных хедеров. Один такой сигнал редко критичен, но в связке это уже fingerprint.

Разберем техническую составляющую реализации. Для верификации используйте не только console-логи страницы, но и сетевой дамп: что ушло в запросе, что вернул backend, какие поля участвуют в скоринге. Если прокси меняет IP, но не меняет язык, часовой пояс и размеры viewport, профиль остается конфликтным. Отдельно проверяйте поведение при первом заходе и после очистки storage: многие антифрод-системы сравнивают не cookie, а устойчивость набора параметров.

Практика простая: держите профиль цельным. UA, экран, гео, язык, touch-модель и сетевой контур должны собираться в один правдоподобный набор, а не в случайный конструктор. Конфиг готов, можно деплоить только после того, как проверка цепочки показывает отсутствие внутренних противоречий.