Почему бот поисковика и живой модератор палятся не по IP, а по цепочке поведения

Почему бот поисковика и живой модератор палятся не по IP, а по цепочке поведения

Анализ логов показывает: блокировка чаще прилетает не за сам факт визита, а за несостыковки в профиле запроса. Робот поисковика приходит с предсказуемым user-agent, короткой сессией и линейной навигацией. Модератор, наоборот, часто грузит страницу как обычный браузер, но выдает характерные паттерны: быстрый скролл, возвраты, выборочные клики, минимум фоновых запросов.

Разберем техническую составляющую реализации. Для детекции смотрят:
— совпадение reverse DNS и ASN с заявленным ботом;
— заголовки Accept-Language, Accept-Encoding, sec-ch-ua;
— частоту переходов и глубину просмотра;
— повторяемость таймингов между запросами;
— наличие headless-фингерпринтов: WebGL, canvas, plugins, permissions.

Проверка цепочки прохождения запроса обычно вскрывает подмену на одном из уровней. Достаточно, чтобы UA говорил «Googlebot», а TLS-профиль, порядок заголовков и поведение DOM были как у обычного браузера — и фильтр начинает задавать неудобные вопросы. То же с модераторами: если с одного IP идут входы в разные кабинеты, одинаковые паттерны кликов и отсутствие нормальной сессии cookie, это уже не человек, а сигнатура.

Нормальная верификация строится на корреляции, а не на одном признаке: сверяем сетевой слой, браузерный отпечаток и поведенческую модель. Если один слой выбивается, трафик отправляют в серую зону или на дополнительную проверку. Конфиг готов, можно деплоить только после прогрева логов и теста на собственном зеркале.