Клоакинг ломается не на фильтрах, а на логике маршрутизации и отчётов

Клоакинг ломается не на фильтрах, а на логике маршрутизации и отчётов

Что бросилось в глаза за неделю: большинство провалов в cloaking stack — это не «плохой антибот», а несостыковка между трекингом, правилами и лендингом. Когда Keitaro, Adspect и внешний прокси-фильтр смотрят на один и тот же трафик по-разному, система начинает отдавать разный контент одному и тому же визиту.

Проверьте базовый каркас:
— единый источник decision point: где именно принимается решение о показе;
— одинаковые сигналы везде: IP, ASN, user-agent, язык, реферер, cookie;
— отсутствие конфликтов между белым списком, geo-фильтром и бот-правилами;
— одинаковую логику для первого визита и повторного захода.

Есть наблюдение которое стоит проверить: если логика «человек/бот» зависит от одного признака, она будет ломаться на пограничных сетях и мобильных операторах. Надёжнее собирать несколько слабых сигналов и не делать резких решений на одном касании. Особенно это заметно, когда трафик идёт через редиректы и промежуточные страницы.

Ещё один частый фейл — разные версии одного и того же ленда для клоаки и для аналитики. В отчёте всё выглядит чисто, а пользователь видит другой DOM, другой тайминг или другой набор запросов. В итоге антифрод начинает совпадать не по правилам, а по артефактам.

Если хотите стабильную схему, тестируйте не «клоаку вообще», а весь путь: вход, решение, редирект, повторный визит, логирование. Когда каждый слой подтверждает следующий, система живёт заметно дольше.