3 техники клоакинга, которые чаще ломаются не в коде, а в логике маршрута

3 техники клоакинга, которые чаще ломаются не в коде, а в логике маршрута

Есть наблюдение которое стоит проверить: большинство фейлов в cloaking stack появляются не на уровне сервера, а на уровне правил. Один и тот же фильтр может пропускать бота в prelander и резать модерацию на переходе в оффер, если цепочка собрана без единого сценария.

— Сначала отделяйте проверку по IP/ASN от проверки по поведению. Если смешать их в одном правиле, потом сложно понять, что именно сработало.
— Не завязывайте решение только на user-agent: его легко имитировать, а в связке с пустыми реферерами он даёт слишком много ложных срабатываний.
— Делайте отдельный маршрут для «сомнительных» визитов: лучше отправить трафик в нейтральный контур, чем сразу в белую или чёрную ветку.

Цифры из последнего отчёта по теме в любой команде обычно сводятся к одному: после ввода промежуточного шага логирование становится полезным только тогда, когда видно, на каком именно фильтре визит изменил путь. Без этого вы тестируете не клоакинг, а догадки команды.

Ещё одна ошибка — пытаться прятать логику только за редиректами. Если слой маршрутизации не синхронизирован с кэшем, гео-фильтром и антибот-проверкой, возникают расхождения между тем, что видит браузер, и тем, что получает обработчик.

Лучше всего работает схема, где каждый фильтр отвечает за один тип сигнала: так проще чинить, масштабировать и не терять конверсию на лишних разворотах.