<b>Клоакинг ломается не на фильтрах, а на грязной логике маршрута</b>

<b>Клоакинг ломается не на фильтрах, а на грязной логике маршрута</b>

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

Что проверяют в первую очередь:
— совпадает ли ответ на первый и повторный запрос;
— не меняется ли поведение при разном user-agent и IP;
— одинаково ли отрабатывают mobile и desktop;
— не течёт ли реферер между ветками;
— не оставляет ли редирект лишний след в цепочке.

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

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